LabVIEW
missing data with rs232
Solved!
Dear expert,
I suffer missing data for RS 232 problem for 3 years. I do not know what I did wrong.
Our company develop a product called EVC. All the LabVIEW code I wrote need to communicate with EVC. I need monitor EVC performance for long time which usually longer than 8 hours. Every once a while I lost some data. The code I have is very large. In order to focus on my problem. I made this simple code to show my problem. This program asking EVC reading. I plot this first reading in the chart. I should read 437 all the time(fig1).
Every once a while I have 0 reading(fig2) :
I dig into my subVI. Here is what I found.
Here is normal screen shot(fig3):
Every once a while, I have 0 reading. When I have 0 reading, EVC still provide data, but slower. It break into something like below(fig4&5) :
How do I prevent this happen? If I can not, how do I deal with this? Any suggestion will be great appreciate.
Best regards,
Victor Huang
I'll make a quick guess and say that because you use bytes at port and you do a one-time read, sometimes not all the data is there and you move on.
Hi Victor,
- using BytesAtPort combined with wait functions is almost always wrong and leads to FAIL…
- using a while loop with a stop condition like "i>1" makes me ask "Why not use a FOR loop?"
- there is NO error handling in case something got wrong with serial communication: you plot new values regardless of the error state…
- you switched off the TermChar, but your device seems to answer with readable ASCII data: does your device REALLY don't use any TermChars? In your images there is a ">" char marking new lines…
- you are using ArrayToCluster followed by Unbundle for 3 years now? Instead of a simple IndexArray function?
- you don't use shift registers for the "Counts" value? Why?
Hi Victor,
What's your suggestion?
- check the manual of your device
- use a TermChar when possible
- read as many bytes as your messages contain - or more, when you use a TermChar
- implement some error handling
BYTES AT PORT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
My friend, you have a race condition. If the device is slightly slow, you could have nothing at your port and read nothing. So the stupid simple, non-ideal, solution is to increase your delay. However, from what I can gather from the screenshots and code, the EVC is ending all of its transmissions with a Carriage Return (0x0D). So the PROPER solution is to use the termination character.
1. In your configureSerialEVC.vi, set the Enable Termination to TRUE and the termination character to 0xD (default is 0xA, or Line Feed). I would also add a property node and set theMessage Based Settings->Send End Enable to TRUE for the VISA reference. This will have VISA automatically add your Carriage Return to the write data, eliminating the need for you to concatinate it yourself.
2. Now where you do the Write and Read, remove the waits and the Bytes At Port. Instead, have the VISA Read to read more bytes than you ever expect in a message (I typically use 100). The VISA Read will stop reading when a) the termination character is read (assuming you enabled the termination character), b) the number of bytes you specified are read, or c) it times out (which will give you an error). So by setting the bytes to read really high, you will depend on the termination character to end the read. What this does is a) ensure you got a complete line and b) give you the data faster and c) be a lot more reliable.
I don't think this loop is working in the manner which you expect.
When the loop is initially entered, two things happen pretty much simultaneously. The 250ms timer is started and the number of bytes available at the serial port is obtained. The next thing that happens quickly is that a read of the serial port occurs and only the number of available bytes (including zero bytes) is done. The loop then waits until the 250ms timer times out and repeats. When the second (final) loop cycle starts, the same thing happens again. The timer starts along with a serial-port read of any available bytes (including zero) and then the loop waits for the timer to finish.
If your EVC device always terminates its responses with a unique termination character, then it would make most sense to configure the serial communications to use that termination character, set the serial timeouts sufficiently long and dump the use of the serial-bytes-available property. Otherwise, you might want to consider reworking your VI to wait until one or more bytes are seen at the port and then wait long enough for all bytes to be received before again getting the bytes at port followed by the read.
