USB 6009 overflow error on continuous mode after restart of VI

[bmkessler]

Hi,

Ok, I just wasn't sure if the firmware update was something that should happen automatically.  Anywhere from 1 KHz to 10 Khz failed for me.  I didn't have a chance to test any lower, because we needed to use the 6008 continuously so I just swapped computers.  However, we will need to use the Dell to acquire data in approximately 2 weeks, so this is a pretty important issue for us.

I'm not sure what you mean by the "shipping example" in labview.  I first noticed the problem with a simple VI I wrote that acquires analog inputs using NI DAQ express VIs and have been attempting to debug the problem using test panels. as per your recomendations  Also, it doesn't take an extended period of time to cause the problem, a few seconds is all that is needed.  Please let me know what you come up with.

Regards,

Brian

[John_P1]

There are at quite a few different issues being reported on this same thread--I'll try my best to address all of them.  If I've left anybody out please be sure to let me know. 

Moving forward, let's keep the discussion on this thread specifically to Error -200361 (the first reported issue).  For people with other issues, please start a new thread so we can better investigate your individual issues and keep everybody's details separate and in one place.

Error -200361

This is a legitimate error message that indicates that data is not being transferred off of the device quickly enough to prevent a buffer overflow.  The error is more prevalent on the 6008/6009 since these devices only have a 256 sample onboard FIFO.  At 48 kHz, it would only take 5¹/₃ ms to fill the on-board FIFO.  For comparison, the 621x bus-powered M Series boards have a 4095 sample FIFO (16x larger than the 6009).

USB is a serially polled bus.  That is, every device that is detected by the same host controller must be polled sequentially for new data (whether it is active or not).  It is normal for many computers to have a single host controller which is divided across multiple ports through a USB Root Hub.

For many other USB applications (e.g. mouse, keyboard, hard drive), latency is not a very big concern.  However, for high-rate data acquisition it is crucial that the latency is low enough to prevent the on-board FIFO from overflowing.  As low-cost DAQ devices, the 6008 and 6009 do not have a very large on-board FIFO (256 samples).  This FIFO is adequate on most systems, but the latency of various host controllers is out of NI's hands so the ability to hit the maximum rate can be somewhat system dependant.

If you haven't already, I suggest to try the following if possible:

    1.  Make sure the 6008/6009 is on its own dedicated Host Controller.  Having additional endpoints detected (even if not actively streaming data) will create additional latency.

    2.  Check to see if there are any updated drivers for your USB controller and root hub.

    3.  Minimize processor use on other tasks.

If the above suggestions don't help, you can try using a PCI to USB controller card.  However, I don't have any specific ones to recommend.

Error -200474

This error normally indicates that DAQmx Read has timed out.  However, the way frozen has described the error in his post would be unexpected to say the least.  It almost seems as if the device has stopped reporting back data altogether. What error do you get when trying to interact with the device after the error occurs?  Have you tried performing a device reset?  What is the behavior when doing so?

It would be very helpful if you could start a new thread so we can keep everybody's details separate for their separate issues.

Driver becomes unresponsive after sampling close to max rate on 6009

Which hardware revision (Part Number) are you using?  Do you have multiple units that display the same behavior?  We may need to take this offline to investigate further.

Device becomes unusable after plugging in a new USB device

NI has actually seen this problem with Intel-based controllers (haven't had any problems with AMD) so we think it's a chipset issue.  A workaround for Windows XP was introduced in DAQmx 9.0 that should allow you to recover from this state by resetting the device.  Windows Vista and 7 still don't have a workaround at the moment, but we are currently investigating what we can do on these OSes (CAR 181229). 

For now the recommendation is to not add or remove any new USB hardware while you are in the process of acquiring data.

Best Regards,

[Sampler]

John P,

I need to know how to revert the firmware to a previous version, for a USB 6009 board.

It was able to sample at 48000 on Windows XP (with NIDAQ 8, I think) until it was hooked up to my Windows 7 laptop. Now it refuses to run at 48000Hz on either machines (it can only run at around 46000~Hz or lower). Infact, it won't even run at 48000Hz on an XP machine that has the latest NIDAQ software).

On the Windows XP machine (with NIDAQ 8), I've tried manually selecting the USB driver (the device then came up as NI VISA) and then unplugging and replugging it, I've tried doing that again but instead of unplugging and plugging it back in I'd select the 'USB 6009' driver for it, and even a few other attempts (like compleltely uninstalling the driver and then unplugging and plugging it back in). Yet still the device seems to be using the newer firmware.

Any recommendations?

[John_P1]

Hi Sampler,

DAQmx should automatically update the firmware.

I'd be happy to provide some more troubleshooting advice if you start a new thread.  This one has become confusing for everybody involved since there are so many different issues being discussed at once.

EDIT:  I'll send you a private message with a link to a utility that you can use to determine which version of DAQmx is installed on your hardware.

Best Regards,

[bmkessler]

Hi John,

Thanks for the clarification about the original issue: Error -200361.  As I try to followup with the USB latency on the Dell Vostro laptop, I am wondering there is any way to recover in software?  After the FIFO buffer overflows, the only way any of us have been able to recover the DAQ is by physically unplugging and replugging in the device (anyone else can correct me if I am mistaken about this).  Just being able to catch this error and handle it appropriately would be a big help.

Thanks,

Brian

[John_P1]

You should be able to restart the task in software if the error occurs.  Does the driver hang when you receive this error?  Try running the attached code.

Best Regards,

[Frozen]

I can confirm that the only way to recover from the error is physically unplugging the USB.

[John_P1]

Hi frozen,

Does the device hang when you connecting other USB devices, or is it seemingly random?  What error do you get when trying to reset or self-test the 6009?  Which hardware revision are you on?

Best Regards,

[Frozen]

Hi John,

There is a high potential of other USB devices being attached during data catpure.

The problem with the reset is it does NOT return an error. After the device throws an error, I have tried using the test panel to do the following:

Reset  --> No error

Self test --> PASS

Data capture (default settings) --> error

Self test --> PASS

Power cycle

Data capture (default settings) --> works

This is using a recently purchased 6009 so I assume it would be the latest HW. I have experenced this behaviour on at least two 6009 DAQ units. I am very concerned about this behaviour since we are about to start ramping to production quantities. Pulling the USB cable every 10 to 15 units is not very productive.

[bmkessler]

Hi John,

I can confirm the exact same behaviour and failure of software resets as seen by frozen when I am using the 6008 on a Dell Vostro.  We are looking at an upcoming high priority data logging operation that will need to run continuously for 72 hrs and pulling the USB cable is not an acceptable solution for us either.  Let me know what you find.

Regards,

Brian