Sometimes bytes lost, when reading from serial port

[JK78]

Hello!

I'm reading data from serial port (baud rate 57600) which works very reliable as long as I do not open any other window

or minimize/restore my application window during program is running. Then one byte from incoming data will be lost.

I receive a string of 30 bytes every 50 ms. In most cases the first byte is lost, sometimes one in the middle.

This problem does not only occur on one PC.

Is this a problem of LabVIEW or Windows?

Are there any settings which can solve the problem?

Best regards,

JK78

[muks]

Do you read all the data if the baud rate is reduced?

[smercurio_fc]

Your problem is not a LabVIEW problem but a Windows problem. Windows can take over at any time, starving other processes. Welcome to the world of the "modern" operating system that rules the world. If you're getting a lot of data that fast then you should increase your serial port buffer to minimize the potential of data loss. You can do this using a VISA function.

[LV_Pro]

If you can attach the part of your code doing the serial comm there may be other things that can be done to improve the comm reliability. As the previous poster said, increasing your serial buffer is a good first start. Is the serial port an actual motherboard hardware serial interface or a USB-serial converter? With the former most of the comm "stuff" is done in hardware, but with the later you are more at the O/S's mercy.

[yenknip]

I had a buffer problem when reading back a large data stream (well, ~500 bytes) I tried a number of things, and ended up using the below solution. I had to force VISA to wait until the buffer had data in.

It isn't really the same buffer problem as yours, but may offer some relief to the VISA buffer?

[tbob]

Are you familiar with handshaking?  This will prevent loss of data due to the OS going off and doing other things while the data continues to pour in.  There is hardware handshaking (RTS/CTS) and software handshaking (XON/XOFF).  Read your device's manual to see if it supports one of these protocols.

What happens is that when the PC buffers come near to being full, it tells the device that is sending data to stop sending, either by sending an XOFF command (software), or by lowering the CTS line (hardware).  Then when the CPU catches up and the buffers become close to being empty, the PC singals the device to start sending again (sends XON command or raises CTS line).  This prevents data loss no matter what the computer is doing.

[LV_Pro]

And I will agree with his suggestion regarding handshaking, with another caveat, not all serial devices have either. Some have only three wire connections, Send, Receive and Gnd, so that precludes harware (CTS/RTS, etc.) others don't have the XON/XOFF (always made me think of the Human Torch, Flame ON/ Flame Off). This is particularly the case with some of the USB serial adapters (the hardware part). Just wanted to throw that into the pot. I have run into a bunch of screwy and not so screwy problems with serial over the years. Used to support 40 systems that used serial comms from the user terminals, all three wire connections, was really good at unsoldering and replacing the RS232 driver chips at each end after a thunderstorm would come through.

If you can post code it might help.

[JK78 · Accepted solution]

I fixed the problem.  

There was a bug in my program which become noticeable only if a window was minimized or restored.

When there were two or more messages in the VISA buffer, the separation of the messages was incorrect.

The array index was calculated false so that the first byte of the second message was at the end of the first

and so the second message in the buffer seemed to be incomplete.

At normal operation the reading while loop runs so fast, that never two messages are in the buffer. 

Thank you for all replies.

JK78

By the way I'm working with LabVIEW 2009 and motherboard hardware serial interface. Flow control with XON/XOFF

is not possible in my application because all hex values from 00h to FFh can occur in a message.

[tbob]

I've run into the same problem with binary data and XON/XOFF.  Switching to hardware flow control solved my problem.

[Engr.Imran]

hi

i am facing the same problem as you were facing,When there are two or more messages in the VISA buffer(i am reading 4 messages), the separation of the messages is incorrect.the first byte of the second message is at the end of the first and so the second message in the buffer seemed to be incomplete

how can i fix it i am attaching a screenshot of my schematic kindly have a look at it and suggest me how to seperate the messages read from the visa buffer..

thanks

imran iqbal