Response of serial connection is messed up sometimes

[ChriKo]

Hello,

I have a simple serial connection (ModBus) to read out 2 kinds of data each second (see attachment "VI.jpg"). This works fine but sometimes the response Hex strings are messed up (to less bytes or to much bytes) which results in "ugly" peaks as shown in the attachment "Chart.jpg". 

Maybe its just a timing issue. There are a lot of LabView examples about serial connections out there and some of them has a "wait" function before R/W operations and some doesn't... Maybe you can help me to get rid of the messed responses.

Thanks in advance

ChriKo

[GerdW]

Hi ChriKo,

sometimes the response Hex strings are messed up (to less bytes or to much bytes)

With Modbus you should know how many bytes you expect to read, so you can get rid of BytesAtPort and the waits…

How are you converting the strings you received to the chart?

Is there some error handling implement? (Probably not…)

[JensG69 · Accepted solution]

Modbus:

There are several freeware APIs availabe for that protocol. I strongly recommend to use one of these!

Regards, Jens

[WNM]

Reading based purely on the "Bytes at Port" (BaP) value can (& usually does) fool you if (when) the BaP function call is made at the same time that a new response is arriving at the serial port. BaP will report how many bytes have actually been received but will not report the number of bytes that are still trickling in (baud rates are very slow compared to BaP checks). You do a subsequent READ based on the preliminary BaP value and you end up reading just that many bytes and it looks to you like too few bytes were read.  Later, when the process is repeated, the BaP check finds the leftover bytes that you did not read on the preceding cycle, as well as any new bytes that have arrived during your wait time, so when you then read based on the new inflated BaP value, you find more bytes than you were expecting.

If, as other have suggested, you can use a proven library to do this reading, then that's the easiest path to success.

If you want to write your own code anyway, then strongly consider always making a call to flush the receive buffer of any leftover bytes immediately before sending any command that will cause your remote device to transmit more bytes into the buffer. 

If the remote device can be setup to send a unique end-of-transmission character, then configure it to do so and setup the LabVIEW READ function to terminate the read when the termination character is received. This is a very reliable technique.

If a unique termination character is not possible (and sometimes it is not because in some cases real data can share the same value as any possible termination character) but you do know how many bytes make up each response, then setup a reasonable read timeout and call the READ function with the exact number of bytes expected. When that expected number of bytes arrive, the READ will terminate and you should have a complete response.

[rolfk]

Basically using Bytes at Serial Port is ALWAYS the wrong thing to do if you write a driver to implement some protocol. While it’s not impossible, it does make creating a reliable driver extremely difficult.

You have two types of protocols nowadays:

1) Fixed size or variable sized but with fixed size header binary protocols with or without end of message byte.

2) ASCII based protocols with some kind of termination character.

The first you have to treat like that by first reading the fixed size part or header and determining from there how much more you need to read.

For the second VISA supports termination character mode with programmable character and then you can make a read with more than the maximum expected message length and VISA Read will return when:

- The requested number of bytes have been received

- When the termination character arrives

- When an error occures

-When the timout expires and none of the above happened

MODBUS falls mostly under the first category though

And no, blindly flushing the buffer before every read is not a good solution. This can just as much flush partial data as Bytes at Serial Port can make you read partial data.

Flushing should in a real driver only be done immediately before attempting to start the first command response sequence. After that if the driver is written properly it should not be necessary to flush at all. It may be helpful to try to flush the port if your protocol handler determines that the incoming messages make absolutely no sense anymore as an attempt to resynchronize but that may not always work well.

[ikaiser]

Hello ChriKo,

You might also find some more information on this article: VISA Read on a Serial Instrument Doesn't Return the Requested Number of Bytes.

[WNM]

---

@rolfk wrote:

And no, blindly flushing the buffer before every read is not a good solution. This can just as much flush partial data as Bytes at Serial Port can make you read partial data.

Flushing should in a real driver only be done immediately before attempting to start the first command response sequence. After that if the driver is written properly it should not be necessary to flush at all. It may be helpful to try to flush the port if your protocol handler determines that the incoming messages make absolutely no sense anymore as an attempt to resynchronize but that may not always work well.

---

I will agree with this if there is the possibility of asynchronous messages being received but if the device at the other end of the link only sends messages in response to prompts from the computer/LabVIEW then I maintain that flushing does not hurt before sending a request to the device.

[ChriKo]

Hello again,

thank you all for the answers and the explanations about the "Bytes at Port".

I replaced the standard VISA serial VIs with the ModBus VIs from here:

http://www.ni.com/example/29756/en/

It works fine now!

Thanks

ChriKo