Onboard device memory overflow. Error -200361

[Dave-L]

Hi there,

I am running a usb 6009 and keep on getting the same error when trying to acquire a voltage.

Error -200361 occurred at Acq&Graph Voltage-Int Clk.vi

Possible reason(s): Onboard device memory overflow. Because of system and/or bus-bandwidth limitations, the driver could not read data from the device fast enough to keep up with the device throughput. Reduce the sample rate, or reduce the number of programs your computer is executing concurrently.

I am running windows 7 on an i3 core processor with 3GB RAM which I believe should be fast enough to handle this fine as the same application works fine on the old computers in the lab. I have tried to reduce the sample rate etc but I still get the error. Seems like the buffer is not emptying fast enough.

Can anyone suggest anything to get this working?

Many thanks

Dave

[JÞB]

This is usually not a OS limitation. Often this results from in-effecient DAQmx configurations for example creating a continuous accquisition task and then reading from it only occasionally. (or waiting for users to respond to promts inside the ACQ loop.) 

Without seeing your vi (go ahead and attach the vi to your post so we can help debug it) I can only offer some general remarks.

When you have a DAQmx task continuously acquiring it is important to retrieve the data from the device at a reasonable rate.  A Producer - Consumer design pattern allows you to get the data back to the PC for processing and your app can use some logic to pace the data processing independantly of the data acquisition.  A simple example of this is shown below

[Dave-L]

Hi Jeff,

Thanks for the reply. I am just using a generic voltage aquisition VI from the examples which I plan to change a little.

Do you suggest I run a Producer - Consumer design pattern for something this straight forward? Could it be computer settings that are throwing it?

Thanks

Dave

[JÞB]

---

@Dave-L wrote:

Hi Jeff,

Thanks for the reply. I am just using a generic voltage aquisition VI from the examples which I plan to change a little.

Do you suggest I run a Producer - Consumer design pattern for something this straight forward? Could it be computer settings that are throwing it?

---

For something this straight forward you are correct- there is no need to use advanced techniques for acquiring a finite N samp 1 ch on demand for a 6009.  There are two things I could think of (or research) to try.

1) try resetting the device- I'm not sure if the onboard buffer is resizable on the 6009 (and the documentation on it does not make it easy to find out)  If someone whet and resized the onboard buffer (like to 0) that could be the cause  Except: the buffer properties on the 6009 are not supported..... OK scratch that but try a HARD reset anyway.  And see if the test panels run before and after reset.

2) USB bus.  Use the control panel to check the USB root hub settings.  Is it 2.0? is it RUNNING 2.0? (a bus may slow down if a USB1.1 device is also on the same HUB.  Is the Power to the device sufficient? the 6009 needs a 500mA port to work reliably.  And check the power options too- you won't want Windows shutting off the hub to conserve power.

I hope this helps-

[Dave-L]

Thanks again,

Have tried to reset and change usb settings but still no luck. Tried it on another laptop and works no issues so just going to use that one. Think mine just needs a good re-install... Usually the cure to most issues...

Cheers

Dave

[BrianALLCAPS]

Hi, I've had the same issue running a USB 6009.  Even in the MAX test panels, I can get it to run continuously three or four times and then I get the error message.  Any further thoughts on a cause?  I've ruled out the possible USB 1.1/2.0 issue - and the problem happens even at low data rates (50 or 100 samples/second - which just about any PC combination can manage)

I've used the DaqMX vi's and this hardware dozens of times (these 6009's are a workhorse around here)  and the only difference is running on a new computer - a blazing fast Win7 one compared to the XP system I usually develop on.  Never seen this issue before - at these low data rates I have a hard time believing it's software related. 

It acts like a buffer UNDERrun issue (being mis-diagnosed as an overrun by MAX/LabView) - that would seem to be more likely on my new PC. 

[Dave-L]

Hey Brian,

I still havent managed to resolve the issue on my personal laptop, however as previously mentioned the USB 6009 ran perfectly on a friends laptop which was not as powerful. I even got it to run perfectly on an old desktop I found in the lab. So it must be something installed, or the settings of my PC that its not liking. I found a troubleshoot on the NI website which attributed the issues to the PC running too many processes simultaneously, I stopped ever process I could but it still wouldnt run.

If you have any luck sorting it out please let us know!

Cheers

Dave 

[JÞB]

Quoting myself

I have seen similar issues and resolved found some potential sources for this behavior related to USB disconnects.  First, since, the 6008 is powered from the USB hub, a hardware problem in the 6008 could require more power than the hub manager can supply.  If the Windows power manager detects an overload it shuts of the port, disconnecting the devices attached to it for good reason.  (Just wait till the first time you find a solidly shorted USB cable- As Windows boots it turns on the hub power and the CPU sees its 5V supply driven to ground- The uP reboots over and over until the offending cable is disconnected).

Second the HUB may be poor quality.  PC manufactures assume that you are connecting a camera, memory device, or something you aren't using often to the USB ports.  So in 95% of all cases if your USB connection hangs its no big deal and you never even complain.  A USB Data Acquisition application is a different paradigm, for this type of use, you need a high reliability USB connectio.  This may not be built in to the convienience ports on the machine.  

Lastly, its that darn U in USB, Universal.  This means you never know what devices have been stuck in that port before - or what problems they had that damaged the port or its hub.  A very close analog is a social disease.  One broken flash drive can degrade the performance of any number of USB hubs.

The solution- Always use a high quality externally powered USB hub and protect it from being used for temporary device connections.

[BrianALLCAPS]

Hi Jeff, thanks for the diagnostic ideas to try out...good info particularly on what other USB devices on the bus can do to the bus.  I have tried most of them to little avail, but I want to try the dedicated self-powered USB port option. 

There seems to be no way to programmatically 'reset' the USB-6008/6009 devices.   Once the device throws a 'buffer overrun' error (-200361) the only way to clear the error is to physically unplug the cable   That and the lack of control over the buffer are the tradeoffs you get with for using the inexpensive NI hardware 😞 

I still suspect that it's actually a buffer underrun error - on my older, slower XP/dual core development machine, I never get this condition - but on my new, faster, development machine, I can reproduce the error consistently in a test VI, and even in NI MAX.  I expect the only way to truly diagnose is to stick a USB analyzer in between

Anyone have similar experience with the USB-6008/6009 series?  Further ideas?  I do like the USB hardware, because it is cost-effective and easy to deploy to customers - but the tradeoff seems to be limited diagnostics and revovery from errors.

[BrianALLCAPS]

Much to my surprise, adding a powered USB hub appears to fix the problem. 

I suspect Jeff was right - the power draw of the DAQ module was enough to cause the USB hub to drop out momentarily.  I added a powered USB hub and stress-tested the connection at the full data rate for this device.  MAX and my VI both work, and the DAQ stream can be stopped and restarted at will, just as it should.  On my development laptop, looks like the built-in USB ports are marginal when a device needs near the full 500mA or so. 

Have to unplug my USB coffee-warmer too.