From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, Nov 8 - 2:30 PM CDT Saturday, Nov 9, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
11-30-2010 11:49 AM
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.
11-30-2010 01:16 PM
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,
02-09-2011 08:56 AM
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
02-09-2011 09:17 AM
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.
02-09-2011 10:02 AM
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
02-09-2011 10:07 AM
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.
02-09-2011 10:07 AM
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.
02-09-2011 11:25 AM
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!
02-09-2011 02:43 PM - edited 02-09-2011 02:45 PM
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.
02-09-2011 03:23 PM
Test failed; error after about 30 minutes.
At least that was quick.