NI USB driver loses device over long period (1 week) - error -50405

[res]

The NI USB driver cannot be relied upon long-term. This is nothing new - there are many other complaints throughout the fora about this problem, citing various modules and PC configurations but they all rely on the USB carrier and exhibit the same problem: after running for a long time the device returns error code -50405, and cannot be used any more. It cannot even be reset by NI's own software - the only solution to recover the module is to unplug the USB device then plug it back in.

This problem should be fixed, National Instruments! Your USB range is fundamentally flawed!

Details from our set-up are given below. A screenshot of the NI MAX program is provided to show how to reproduce the problem.

We are seeing the USB problem with an NI USB-9211A thermocouple. We see the problem using NI's own software when there are no other USB devices plugged in. Other discussions in the fora use different modules in USB carriers with the same effect.

System details:

• Windows XP Pro SP2
• NIDAQmx 8.6.0f6
• NI Measurement and Automation Explorer 4.3.0.49152
• Hardware is an NI USB-9211A thermocouple cartridge in an NI USB-9162 carrier
• NI USB module is plugged into an Intel 82801DB/DBM hub. It is the only device plugged in.
• Power saving is disabled.

Problem reproduction:

• Run NI Measurement and Automation Explorer.
• Create a temperature task as shown in the attached picture.
• Click 'Run' and data acquisition should start, with temperatures coming in OK.
• After no more than 1 week, the display halts with the error shown in the attached picture. The thermocouple cannot be recovered or reset. The USB cable must be pulled out and replaced for it to work again.

This process depends on NI software and hardware only.

We need to know: is this problem going to be fixed, or just ignored?

[AdnanZ]

I remember them having a problem with that version of the driver. I hear DAQmx 8.8 has fixed the issue. Try to download that and see if you still get any issues.

[Hillman]

Hi Res,

Thanks for your post and I hope your well today.

I have to say your in good hands with Adnan, are you planning to try the newer version of DAQmx?

I am sorry that you've experienced this clearly frustrating problem. So I am offering my support, if the newest driver hasn't fixed the problem.

Let me know, 

[res]

Thank you for the replies so far.

There will be a minimum 1 week delay while v8.8 is tried. This issue is still pending and there will be a response.

[Hillman]

Hi Res,

Thanks for the reply.

I have received a service request for your issue - and I will monitor this post. If you could please update us (me) next week, then I can continue to support you if necessary.

Best Wishes, 

[Hillman]

Hi Res,

Good Morning and I hope your well today.

I have been doing some research into possible issues - had I have some questions and some sources you could maybe look into.

So you have mentioned (but I want to confirm) that you have a few options to restore communication - if we can't stop this error occuring. These would be:

1. Reset Device from the Driver (DAQmx Reset Device) - you said this doesnt work - what happens?

2. Use MAX - you said it doesnt work - what happens?

3. I have seen customers in the past place a relay in the power line to 'prgrammatically' reset the device - rather than unplugging it. Option? Annoying I know. 

So advice for avoiding communication loss:

The southbridge or I/O controller hub (ICH) is responsible for USB communication for your PC. Making or breaking another USB connection while your data acquisition device is connected may cause one of the above communication errors. This has been observed on chipsets with ICH versions 2, 4 and 6, but may affect others as well.

#.Can I confirm that your not plugging or removing devices?

Are you using a HUB?

Have you seen this forum:

USB-6501 static problems

http://forums.ni.com/ni/board/message?board.id=70&thread.id=7166&view=by_date_ascending&page=1

Is seems the device this customer was using wasnt a true 2.0 device - and thus was causing communcation loss. 

 I have found a very similar case of extend use on a USB device which caused the same error. It seems the suggestion was the customer needed to source a more reliable computer.. and R&D tested 390 and no problems were found...The customer computer was a DELL and using DAQmx 8.3.

Finaly, I had read that this error had been caused on a number of occassions by having noise on the power line. This caused the USB device to turn off.. have you monitored this line at all?

Please let me know,

[Hillman]

Hi Res,

I also wanted to check say,

1. This error has been resolved by using a different port/cable

2. USB Root Hub Properties and turn of 'Allow the computer to turn off this device to save power' on the power management - confirm this is unchecked?

[res]

Hello again everyone.

[Note: Because of attachment limit this post has been split into multiple posts]

The first cycle of testing has completed, so here are the results, and answers to the questions posed during the test. I will not write comments to avoid confusing fact with opinion.

(1) Version 8.8 of NIDAQmx does not fix the problem. See attached screenshot 'USB Error.png'.

> So you have mentioned (but I want to confirm) that you have a few options to restore communication - if we can't stop this error occuring. These would be:

> 1. Reset Device from the Driver (DAQmx Reset Device) - you said this doesnt work - what happens?

(2) Immediately after the error, a 'Reset Device' produces "Error -50405 occurred at Device Reset". See 'Reset Device 1.png'.

If another 'Reset Device' is then attempted (without changing anything) "Error -50004 occurred at Device Reset". See 'Reset Device 2.png'.

[res]

> 2. Use MAX - you said it doesnt work - what happens?

(3) MAX is incapable of doing anything with the device - you just get errors. To be specific, and for completeness, here are all the things you can do:

(3a) If you press 'Reset Device' - see answer (2).

(3b) If you press 'Test Panel' you get a failed Self Test (see 'Test Panel 1 Self Test.png') followed by the panel. If you press 'Start' then you get an error ('Test Panel 2 Start.png'). If you press 'Show Details' then you get error -88708 ('Test Panel 3 Details.png').

(3c) If you press 'Self Test' you get error -88708. See 'Self Test.png' screenshot.

[res]

> 3. I have seen customers in the past place a relay in the power line to 'prgrammatically' reset the device - rather than unplugging it. Option? Annoying I know. 

(4) No. This cannot be done in a continuous test that lasts days.

> Can I confirm that your not plugging or removing devices?

(5) Yes. The PC has no other USB devices plugged in. See 'Device Manager - By Connection.png'. We are not unplugging the NI USB thermocouple. The PC is kept in a restricted area.

Further, the PC is not used for any other purpose (in this test) other than reading a thermocouple continuously for days.

> Are you using a HUB?

(6) No. Only a USB Root Hub on the motherboard. There are no other devices connected to this hub. There are 3 other motherboard Root Hubs. Nothing is connected to them. See 'Device Manager - By Connection.png'.

> Have you seen this forum:
> USB-6501 static problems
> Is seems the device this customer was using wasnt a true 2.0 device - and thus was causing communcation loss. 

(7) The only device we have connected is the NI USB thermocouple. See 'Device Manager - By Connection.png'.

> I have found a very similar case of extend use on a USB device which caused the same error.
> It seems the suggestion was the customer needed to source a more reliable computer.. and R&D tested 390 and no problems were found...The customer computer was a DELL and using DAQmx 8.3.

(8) We are using an Amplicon industrial rack mounted PC - see 'More Reliable Computer.png'.

The recommendation to buy a '... more reliable computer ...' is neither quantifiable nor guaranteed to work. I'm afraid we cannot consider this as a viable solution.

Has R&D run a USB device [thermocouple] continuously for at least a week?

> Finaly, I had read that this error had been caused on a number of occassions by having noise on the power line. This caused the USB device to turn off.. have you monitored this line at all?

(9) Do you mean the two (power) lines in the USB cable or the mains power to the PC? Assuming the former, no, we have not set up test equipment to monitor these lines.

> I also wanted to check say,
> 1. This error has been resolved by using a different port/cable

(10) The USB cable in use is that supplied by NI. Around it is printed:

National Instruments 192256A-01 2207 13760 PRODUCT OF CHINA

> 2. USB Root Hub Properties and turn of 'Allow the computer to turn off this device to save power' on the power management - confirm this is unchecked?

(11) No, this was not unchecked. Because of this, a new test has been started with this box unchecked.

Again, I will report back.

Thank you for your thoughts.

RES.