Overrun error (-1073807252) occurs after several minutes

[Martin Fierz]

I have no solution either, but I have the same problem on a Dell Latitude D800 running LV7.1, transmitting on a serial port at 115'200 baud. I realize this post is not helpful, but since it's yet another Dell, it might be another confirmation that the problem is with the computer rather than with the program.

cheers

  Martin

[DarylE]

Hello,

Along with your serial communication's specific parameters (amount of data and the baud rate, for example), overrun errors can depend on the speed and memory of the computer system.  If the computer's speed and memory are not able to keep up with the higher baud rate, some possible fixes to consider include:

1) Read more data from the port at a time

2) Read from the port more often (this could be affected by any other time-consuming operations/code that run between reads)

3) You can experiment with increasing the buffer size by using the "VISA Set I/O Buffer Size.vi". However, this may only delay the time it takes for the buffer overrun to occur. Please refer to the following KnowledgeBase or the VI's help file (where there is a link to a shipping example that uses the VI) for more information:
Setting the Serial Port Buffer Size for Receiving or Transmitting Data with VISA

4) You can monitor the data on the port using the "VISA Bytes at Serial Port" VI/property node on the Serial function palette. This might help you highlight the difference between two different systems and how they are handling the same amount of data on their serial ports. Another very useful VISA troubleshooting tool that might help in the same way is the NI-SPY utility. NI-SPY can "track the calls your application makes to National Instruments test and measurement drivers (NI-VISA). It highlights functions that return errors so you can spot functions that failed quickly. NI-Spy can also log these functions to disk so you can check them after the capture of data.

Daryl E
National Instruments
Applications Engineer

[Dave_Thomson]

Daryl,
   It's good to see more input on this subject.  However, I would like to stress that in my case, at least, the "overrun error" was quite likely NOT due to an overrun.  I do not currently have access to the client's computer that was exhibiting this behaviour, and I did not run the specific tests you suggest using the VISA Bytes at the Serial Port to view the build-up of characters in the buffer.  However, I think the evidence is pretty good that there is no actual overrun.  Specifically, the program worked fine on several different computers when talking to the same hardware.  Several of these computers were slower (CPU speed) than the offending laptop, and one was faster.  We also did play with buffer sizes and some of the other tricks, with no obvious difference in behaviour.
   My best guess is that there is a very subtle problem in the serial port hardware on a small subset of Dell laptops.

Regards,
    Dave

[JoshuaP]

I think you are correct Dave. As I mentioned in my previous post the Dell laptop that I was using was fairly new and the problem went away when I switched to an external NI USB-232. We tried several different work arounds with FIFO trigger levels and async versus sync reads and the outcome was always the same.

-Josh

[Martin Fierz]

I would also like to stress (like others in this thread) that this does not seem to be a problem of reading the buffer too infrequently. My labview program is essentially doing nothing else than reading the data, and it's doing this on a centrino 1.5GHz system (or something very close to this, i'd have to look up the actual frequency). at any rate, the computer is by far fast enough to read the data.

To really make sure that this is the case, I displayed the number of bytes at the serial port on my VI's front panel, so I can see whether the buffer fills up or not, and I can see how large the number is when the program crashes. It turns out that the number of bytes at serial port is always very little (a few 100 at most), and when it finally crashed, there were about 700 bytes there. I did this with the standard 4K buffer, and also with an enlarged 64K buffer - same result.

I finally "solved" my problem by simply disabling automatic error handling in the VI - so now the error might occur once every few minutes, but all that might happen is that I lose some data points - which in my application is uncritical.

best regards

 Martin

[Markman]

For what it's worth to anyone reading this thread...

We've seen a similar problem with intermittent buffer overrun errors when the buffers clearly weren't full.  We found that the VISA flush vi wasn't always clearing the buffer full status.  Using two flushes in sequence seemed to fix the problem.

[Blueprint]

Hi all, 

To add to the frustration and confusion; I have this problem on my 4-NI-USB/232 box, but not on my Dell computer port. However, we have this problem on another DELL com-port though. 

I can provoke this error using the erroraneous box anywhere, and using a "good" box will make it work anywhere... So could this be something related to the actual RS232/UART chips that has gotten some kind of hickup?

I am using LV8.6.1 and NI-serial 3.5

Message Edited by Blueprint on 09-02-2009 01:27 AM

[jonathanupr]

So are we saying that this can or will occur with Dell laptops with an EXE?

[jonathanupr]

I get this overrun error when runing LV 2009 SP1, where as I do not get it when running 8.5... is there a reason for this?

[Dave_Thomson]

   Six years later, several operating systems later, as well as many versions of LabVIEW, and we came up with this same problem on another Dell laptop!  To recap:  We have a program that loops around once a second.  It first clears the serial input buffer, then sends a command to the instrument requesting data, then reads a fixed number of characters back from the instrument.  We randomly get an "overrun" error  (-1073807252), though everything I know about LabVIEW would indicate that we shouldn't be able to get an overrun error.  The receive buffer is cleared before requesting data.  The buffer size set when the serial port is opened is larger than the expected data return, and we're sitting there waiting on the Visa Read command.  How could the buffer overrun?  My previous thought was that this error was erroneous and something else was failing.  In 2006, we blamed it on the Dell serial port hardware.

   My current understanding of the serial port system follows.  Please correct me if anyone sees any errors in this description.

   The UART has a smallish FIFO buffer on it, often 16 bytes.  The port we were using most recently is a USB-serial adapter with 380 bytes.  Data coming over the serial port are read into this FIFO.  Filling the FIFO at some point triggers OS interupts.  The OS then transfers bytes out of the FIFO into a memory buffer, which is the one refered to when setting the buffer size for the serial port explicitly in LabVIEW.  This is set to 4096 by default, at least in LV 2010.  LabVIEW then reads this memory buffer when you use the Visa Read function.  Thus there are two places where overruns can occur, in the UART FIFO and in the OS memory buffer.  I was assuming (5 years ago) that the overrun error refered to the memory buffer, which should not have been able to overflow under our conditions.  My new assumption is that the same error is being used to report UART FIFO overruns.

   My current theory is that some service or program running on the OS runs at random-seeming intervals and is an interupt pig. If this unknown service launches and saturates the CPU's ability to respond to interrupts, the UART FIFO buffer can overrun even though LabVIEW is sitting there in the Visa Read, waiting for characters to appear.

   We verified this theory by stopping two dozen seemingly-unnecessary services and start-up programs on our new Dell W7 laptop.  The overrun error went away!

   This is further verified by the fact that we ran the same software on a server class computer also running Windows 7.  Even without killing off unnecessary processes, we never saw the error.  This is consistent since the servier class computer had a more powerful CPU, including 16 cores, compared to the 2 cores on the laptop.

   This is also probably consistent with our 2006 experience with the old Dell laptop, compared to other computers that didn't exhibit the problem.  The problem likely only occurs when a relatively limited processor is combined with a relatively ill-behaved service running in the background.  We blamed the Dell hardware before, but likely this was due to Dell installing some arcane service.

    We did not have time yet to identify the exact service that was causing the problem, but for possible benefit to anyone else fighting this issue, here is the list of things we turned off, after which the problem vanished:

   Diabled Services
Andrea ST Filters Service
Audio Service
AuthenTec Fingerprint
Base Filtering Engine
Diagnostic Polling Service
FF Install Filter Service
NTRU TSS
Offline Files
Parental Controls
Problem Reports and Solutions
Secure Accounts Manager
Security Center
Tdm Service
Windows Audio
Windows Audio ENdpoint Builder
Windows Defender
Windows Firewall
Windows LIve ID Sign-In
Windows Media Player Network
Windows Search
WIndows Update
Win HTTP Web Proxy Auto-DLL
   Disabled Auto-Start Programs
NI Update Service
Power DVD Language Application
Power DVD RC Service
Java
Trusted Drwe Manager

Regards,

   DaveT