Serial Communication - Process received string

[Forsaken Angel]

Hello

I am building a LabView Aplication to post-process and to show data received from sensors via RS-232.

The sensors send data periodically via serial port, and then the program should read the resulting string and parse it to get the sample values.

However, I cannot process each string at a time, the program does not answer!

I managed to build an alternate solution by concatenating each received string (with a shift register) and the program shows the received data correctly. However, concatenating the string causes unnecessary processing time, since the program is always processing the data that it already received.

Attached to this message are both situations, with string concatenation and without.

Can somebody help me or tell me what am I doing wrong?

Thanks

Message Edited by Forsaken Angel on 05-31-2007 10:54 AM

[Brian_Beal]

Please give us more information.  What do you mean by the program does not answer?  What does the string from your sensor look like?  Please attach the "Samples" vi.

[smercurio_fc]

A few notes:

• You do not need to set the timeout at each iteration. Once is enough. In fact, you've already set it as part of the "VISA Configure Serial Port". It has a "timout input.
  
• You need to pass around the error in a shift register. The way you have it now the case structure is only looking at the error out from the VISA Clear from the very first iteration. Each iteration thereafter it's always reading the same error cluster value.
  
• You probably want to end the loop when you have an error.

Now, as to your specific issue: The fundamental problem with the non-concatenated version is that you have no way of knowing how many bytes are actually going to be at the serial port. Could be one, could be 50. Thus, you cannot be sure that you're going to get the entire measurement at once, but your non-concatenated version assumes you do. That's why the concatenated version "works". Since the sensor is periodically sending out measurements it must terminate the measurement with something, and this is probably a CR or CR/LF. Keep reading until you see this. In fact, the VISA Read should read until it sees the termination character, so you can configure the termination character to match what the sensor spits out. That way, each time you do a read you'll likely get the complete string that is the measurement.

[Forsaken Angel]

I will try to post my Samples.vi file when I get access to the computer where it is stored.

About the number of bytes, the problem is that I do not know the number of bytes that I will receive on each serial port transfer, because the frame uses an "escape character" method (for the 7E and 7D characters), that causes the frame to have an unpredictable length.

Each frame begins and ends with the hexadecimal character 7E. The received bytes should look something like this.

7E ..... 7E7E ..... 7E7E ....

And as I said, the number of bytes between 2 7E characters is unknown.

My real problem is how can I process each frame without storing all the information I received, but without knowing how many bytes will I receive each time.

Thanks for all your help

[Forsaken Angel]

Here are my frame processing routines.

The goal of this routines is to parse the received frame, removing all 7D escape characters (XOR the next character with 0x20), and to extract all relevant sensor information.

Best regards

[kdmcmullan]

How fast are the characters coming to your serial port? If they're nto terribly fast, my approach would be to read them one at a time, wait for an escape character, discard it, then concatenate all the received characters until the next escape character is received.

Be careful, then to check the first character in the resultant string is not escape (it might be if you started your receiver inthe middle of a "packet").

The output from this look would be a complete, variable-length packet.

[smercurio_fc]

Forsaken Angel said:

---

My real problem is how can I process each frame without storing all the information I received, but without knowing how many bytes will I receive each time.

---

As I've already indicated, since you do not know how many bytes you're going to get you have to accumulate the bytes you read into a shift register and then look for your start/end markers. Once you find your frame (you may have more than one), snip it out, and only pass whatever is left into the next iteration, since you could have bytes from a new frame. You do not need to carry around everything you've read. Only enough so that you can get a complete frame out. Your "concat" version essentially does this, except you're just carrying around everything you've read so far. Modify this so that you look at your concatenated string, find frames, remove them from the string, and pass out whatever characters are left into the next frame. If in a particular iteration you do not yet have a full frame, then don't do any frame processing or graph updates.