VISA: overrun error during serial commn

[Vijit]

All,

I am using a LV program to receive a comma delimited string (approx. 16KB) from an embedded board. I have been using the "Advanced Serial Read Write VI" to read the data after proper handshaking. And XON/XOFF flow control is in place.

This program was running fine for a few weeks now. But it has suddenly started to develop this error.
>> 1073807252 VISA:  (Hex 0xBFFF006C) An overrun error occurred during transfer. A character was not read from the hardware before the next character arrived.
Nothing on the LV or embedded side has changed AFAIK.

This problem is intermittent. So the program works fine for an arbit amount of time before it breaks down (making it a pain to debug). When it does break down, it receives a truncated string which is sometimes 1KB and sometimes upto 12KB (so I seriously doubt if it is a buffer issue). I am also using the "VISA Set I/O Buffer size" to set the receive buffer size. Is there a maximum value I can set this to? If I set it to a number above the maximum value, does it revert to default (4096)?

The intermittent nature of the problem suggests that it is more of a timing issue than anything else. But here, I am attempting to read the entire chunk of data at once and there is no processing time involved between reading succesive characters. Hope somebody can bail me out.

TIA
Vijit

[Michael_Munroe]

There are two levels of buffering on serial ports.  The one in hardware is usually 16 bytes and is internal to the UART chip.  At the lowest level, the UART generates an IRQ for every byte and the VISA software reads the byte and adds it to the software's buffer.  This type of error might be caused by the computer being tied up when the IRQ occurs.  This might be caused by too much disk IO, ethernet IO, mouse movements, any USB device or a PCI card that is generating activity.  Try to free up some RAM, check what programs are running and defrag the hard disk.  Look for a program that kicks in at certain intervals like Windows Update or Symantec LiveUpdate.

[Vijit]

Thanks Michael.
The desktop is currently dedicated to running this program.  I will try  these suggestions and let you know how it works out.

But the lack of a tangible solution does bother me though. Is it possible to overcome this issue using flow control methods? How about decreasing the baud rate? (Slower data transfer might be easier to synchronize). Considering that this data transfer occurs within a 1-2s window, is it possible to prioritize LabView processes (and give lower priority to Windoze requests) during this time?

TIA
Vijit