Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

USB 6009 overflow error on continuous mode after restart of VI

I don't mean to derail this thread, but it appears that a new error is popping up that I had not seen before. The dreaded 50405 error. I have read through at least 10 other forum threads about the error, with no clear resolutions.

---------------------------------------------
Certified LabVIEW Developer (CLD)
0 Kudos
Message 41 of 69
(1,999 Views)

If this behavior occurs when you plug in another USB device, then this has been observed behavior (mentioned earlier).  What host controller are you using?  Also, please be more descriptive when describing the error behavior and the exact steps to reproduce.

 

In the case of -50405 after plugging in another USB device, a device reset should recover from this state on Windows XP (more of a workaround than a fix), but not necessarily on Vista or 7.  We are currently working with Intel to try to find a resolution, but in the meantime the recommendation is to not plug in other USB devices while an acquisition is taking place.  You could also try using a different host controller--PCI USB controllers are relatively inexpensive.

 

 

Like I mentioned before, although many of you seem to have similar issues, the root causes could be completely different.  As it is becoming very difficult to track the information from each specific user on this thread, I'm going to have to ask everybody to post to their own individual threads so we can address specific issues.  Thanks!

 

 

Best Regards,

John Passiak
0 Kudos
Message 42 of 69
(1,987 Views)

Dear participants,

 

Has this issue been resolved yet?

 

I have a Dell Precision M65 desktop with Windows7 64bit installed, and I keep getting the error -200361 after restart of continuous mode even at low AI sampling rates (100Hz, 1 sample for each AI). The first continuous run works OK, but usually the second/third run fails with this error.

 

Reading AI channels with Measurement and Automation explorer also causes this error, however not as often often. Resetting the device in Measurement and Automation Explorer does not help, despite that the self test indicates that everything is OK. Digital outputs however work OK all the time.

 

My tedious workaround is to disable, and re-enable the driver. Then, the first AI run is OK.

 

The only USB devices I have plugged in the desktop are mouse and keyboard. No other applications are running.

 

- Is there a way to programatically (in vb.net) disable and re-enable the USB-6009 driver?

- The continuous AI read is an asynchronous read i presume? Could the issue be caused by some kind of threading problem, causing the task not to be fully disposed after the read?

 

Any help is appreciated,

 

Best Regards,

Kristian


0 Kudos
Message 43 of 69
(1,888 Views)

Hasn't been resolved for me, but I'm caring less and less now; I'm trying to persuade the company I work for to seek alternative data acquistion hardware.

 

You're using an Intel USB chipset right? ICH4/5/6/7? I think perhaps the USB 6009 fairs better on AMD chipsets than on Intel. I have yet to test this though; it's on my TODO list.

 

If you can, try and get NI to post a listing of "Known Compatible Systems" for the USB 6009.-- I'm sure it's a remarkably short list.

 

 

0 Kudos
Message 44 of 69
(1,883 Views)

Hello "Sampler"

 

thank's for your feedback,

 

Intel, you're correct, however I'm not quite sure about the specifics of the chipset. I have an old ASUS at home (WinXP), and at first glance the problem seems more remote here, although not perfect. The only workaround is also here to either unplug the USB or disable/enable the driver. I'll post my experiences on this later.

 

A lot of time is lost troubleshooting these issues, which is somewhat frustrating. One should believe that simple analog differential read operations should run seamlessly, even for relatively low cost hardware. My first "date" with NI-hardware has been somewhat of an ambivalent experience so far.

 

Best Regards,

Kristian

Norway

0 Kudos
Message 45 of 69
(1,876 Views)

No, this has not been resolved for me.  Currently my only workaround (if you can even call it that) is to just unplug and replug in the USB cable.  It has been a frustrating experience to say the least.

 

Interestingly enough, when running the same program built as an executable on an Asus netbook, everything works great.

0 Kudos
Message 46 of 69
(1,874 Views)

If you pull "-1" samples instead of some positive number, it should prevent you from having to physically unplug the device. Pulling "-1" pulls the available samples that the driver has. This is different than pulling just the  'AvailableSamples' qauntity.

 

However, this is not a fix-all. You'll still get the internal buffer error, but you'll be able to recover from it more frequently.

0 Kudos
Message 47 of 69
(1,873 Views)

Has not been solved for me either.

I will have to resolve it soon (one way or another) since the CM is complaining about having to pull the USB cable. And rightfully so!

---------------------------------------------
Certified LabVIEW Developer (CLD)
0 Kudos
Message 48 of 69
(1,858 Views)

After reading this:

http://forums.ni.com/t5/Multifunction-DAQ/Hyperthreading-and-error-200016/m-p/283914

 

I'm going to run a test right now with 'Intel Hyperthreading Technology' disabled. It's a different issue with a different board, but I think it's worth a shot.

0 Kudos
Message 49 of 69
(1,843 Views)

Test failed; error after about 30 minutes.

 

At least that was quick. Smiley Happy

0 Kudos
Message 50 of 69
(1,836 Views)