Correct serial communication receive routine?

[eeironman]

I am absolutely newbie and actually do not know how to write the Labview program. However I can wrtie program in other language and firmware for the microcontroller, so I know the normal software routine to send and receive data through a serial communication.

Recently I am working with another engineer who is responsible to write a Labview program which will be run on a computer to test a product. However we found problem on the communication between the computer and the product. I feel that his software routine for receiving data is not correct. His routine is like:

1. other testing procedures.

2. start to receive data and wait there.

3. Set a fixed delay waiting time (for example 5s, no matter the computer received data or not, it will wait for 5s)  

4. Check the receive buffer for the data

5. other testing procedures.

6. then repeat 2-4 when need to receive another chunk of data.

I feel that he use a fixed time to receive data will cause problem, because the product may send the data at different time in each test step. It may be acceptable for receiving only one packet of data , however when the testing procedure get very long and it need to receive from the product for many time, it is not reliable that the timing of the product can synchronize with the computer.

From my previous programming experience, there should be an interrupt/callback to receive the first byte, then the program can check whether there is another byte received before a timeout (depends on the protocol, for example 0.5s), if no other byte received after the timeout, it can assume the packet of data has finished. (In this method I assume there is no end character in the protocol so we cannot check the end byte, such as the Modbus RTU protocol).

Is there a similar method in Labview to receive serial data? Or what is the correct way to receive the data?

Thank you very much.

[RavensFan]

Have you looked at the VISA serial examples in LabVIEW found by way of the example finder?  Look there first.  They aren't the best.  They use the "Bytes at Port" method which isn't the best way to work with serial data with most protocols.  Search the forums for questions about how to communicate using serial.  The questions come up fairly often.

Five seconds sounds like a long time to intentionally wait for data before doing something.

Why isn't the device using a termination character?  When there is one, that is a better way of determining when a message ends.  Another alternative is to prepend the message with one or two bytes that tells how many more bytes will follow in the message.

[billko]

The general rule is: "If you need a hardcoded wait, you probably don't truly understand how to communicate with the equipment."  There are exceptions, but I find this to be the case most of the time.

[crossrulz]

In general, it sounds like the setup is flawed.  5 second waits is an eternity.  Should not need that.  An alternative would be to use the Byte At Port to see if any data is available.  If not, wait 100ms and try again.  Repeat for up to 5 seconds or data is recieved.

Without knowing more about the message protocol, I can't give any better advice.  But if data "randomly" comes in, then it is definately best to have the serial read done in a seperate loop than everything else and then use a queue or user event to send the recieved message to whoever needs it.