LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial FIFO overrun errors

I have an built an application that communicates with a device via RS232.  I am using LabVIEW 2011 and VISA 5.1.   I am continually getting 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

 

After carefully reading this page, I see that the error is happening on the hardware level and appears to have nothing to do with my LabVIEW code nor how quickly I read from the serial buffer.

 

It appears that the FIFO buffer on the UART chip is overflowing because the CPU is not responding to interrupts quickly enough (at least that is my understanding of it).  This would make sense because the error appears to happen when I open other applications (eg, if I open MSIE while the application is running).

 

Do you have any additional suggestions (other than what is listed on this page)?  I am wondering if I should get a better RS232 card?  Would getting a card with a large FIFO help?  128 B?  Any reccomendations?

http://www.medicollector.com
0 Kudos
Message 1 of 6
(5,496 Views)

Hi,

 

A possible software solution may be to raise the 'Priority' of the VI that reads the serial port buffer in 'VI Properties>Execution>Priority'. The 'normal priority' setting can allow the OS to interupt the VI for a (relatively) long time and with 'time critical priority' the OS *seems* to service the VI at sub-millisecond intervals.

 

Thanks,

Jim

0 Kudos
Message 2 of 6
(5,475 Views)

The first thing that comes to my mind is to make sure that Windows is using the full buffer (usually settable in the Device Manager).

 

On the software side, I have been known to have a single loop simply read the port and put the whole string into a queue.  Another loop can then process the strings however it needs to.  This might allow the CPU to clear the hardware buffer before more data comes in.

 

The simplest thing to try though would be TSJim's suggestion of increasing the priority of your VI.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 6
(5,466 Views)

Thanks for all your tips!

 

I am using a produce-consumer architecture.  And yes, I have tried changing the size of the UART buffer via Device Manager.  I tried maximizing it and also minimizing it.  Didn't seem to make any difference.

 

But I have to doubt that changing the priority of my VI will have any effect at all.  In fact, I almost wonder if giving it a higher priortiy will interefere even further with the CPU and prevent it from emptying the UART buffer ... thereby making the problem worse.  The problem is on the hardware level which gets the data from UART buffer (which is only 64 bytes) and places it into memory. Read this page closely.  I don't see how making my software run faster will have any effect?  Could you explain?

 

Here are the suggestions from NI for hardware overrun errors.  Note the comment about LabVIEW-related software:

 

1. Try hardware handshaking.

2.  See if the UART is an older unbuffered version or a new buffered UART (such as a 16550A or 16750). You should use a buffered UART for the reasons discussed above.

3.  Change the Receive (Rx Trigger) buffer to 8, 4, or 1 (1 is a last resort).

 

Note: LabVIEW or related software usually is irrelevant to the Hardware Overrun Error.

 

http://www.medicollector.com
0 Kudos
Message 4 of 6
(5,458 Views)

How fast are you suppposed to be receiving data?  I've had serial ports get hammered and never ran into this error.

 

Can you also post some of your code.  Maybe there's something stupid in there one of us will see (fresh eyes).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 6
(5,445 Views)

Hi josborne,

 

This KB also suggests a couple of things. One idea here is to lower the buffer size. The UART will use full buffer that it has built-in to buffer the samples, but it will send an IRQ signal to the processor sooner if you specify a lower buffer. This, combined with hardware handshaking (which you have already mentioned) should enable you to communicate with the instrument.

 

As crossrulz said, you could also try to lower the baud rate so that the buffer won't get filled as fast, in case this old UART can buffer low amount of bytes.

 

You can also try to send commands using the VISA Test Panel or HyperTerminal.

So basically all of the suggestions you have should work. Have you tried them all and still get this error? If this doesn't work, I'd seriously begin to wonder what the performance of your computer is and try out another UART (a USB to serial converter, maybe?)

 

Also, what is the device you are talking to?

Regards,
Daniel REDS
RF Systems Engineer

Help us grow.
If a post solves your question, mark it as The Solution.
If a post helps, give Kudos to it.
0 Kudos
Message 6 of 6
(5,439 Views)