Serial Port Overrun

[Chris46]

Hello All,

I am developing Teststand sequences which run Labview code. I use 1 labview vi to configure and drive the serial port, the first call configures the serial port. The second call writes a message and reads the response, the last call releases the resource. When running the call write&read I intermittently receive the error shown in the attached jpg, this causes my whole sequence to lockup till I return to restart the test. I need to run this repeatedly overnight so its a problem. I have a feeling this isnt so much a serial port overrun problem as a hardware clash ( i also configure and run a camera ).

I have spotted a number of posts a on this same topic but I havent yet found a soultion only advice, which I have already tried.

Help greatly appreciated

Regards Chris

[RTSLVU]

I am guessing you need to adjust your serial buffer but without seeing your code we'll never know.

[tbob]

Are you familiar with handshaking?  There were several posts on this subject recently.  The end device is sending data faster than your computer and Labview program can handle.  You need to implement handshaking.  There are two types of handshaking, software and hardware:

Software, also called XON/XOFF.  With this setup, when the computer serial port incoming buffer gets nearly full, it automatically sends an XOFF command (don't worry about what it is since it is automatic).  The XOFF command tells the endpoint device to stop sending data.  When the buffer gets near empty, the computer sends an XON command.  The endpoint device then starts sending data again.  For this protocol, the endpoint device must be able to support this, and must be configured to use this type of handshaking.  You would have to read the manual to find out how to set it up.  For the computer end, you can set it up with an option for the configure serial port function on the input labeled "Flow Control".  Right click on this terminal and select Create - Constant.  A text ring will be created.  Select XON/XOFF in the text ring.

Hardware, also called RTS/CTS.  Same principle in that the computer signals the endpoint when to stop sending data and when to start again.  However, instead of sending a command, the computer drops the CTS line (Clear To Send).  Actually, the endpoint device raises the RTS (Request To Send) when it wants to send data, and the computer responds with raising CTS if it is ready to receive data.  When the buffers get full, the computer drops CTS which tells the endpoint to stop sending data.  When the computer is ready to start receiving again, it raises CTS.  Again, both sides must be configured for this.  The text ring has an RTS/CTS selection.

You will have to read the manual on your endpoint device to see what it supports and how to configure it.  Warning:  If sending binary data, DO NOT use XON/XOFF.  The binary data may just happen to form a pattern that looks like XOFF, and everything will lock up because XON will never be sent.  So if binary data is being transferred, use RTS/CTS.  If normal ASCII characters are being sent, you can use either protocol.