Problem with USB 9233 - 50405

[phonoX]

Hello,

the USB 9233 is the only device connected to the system. Maybe the mouse or the keyboard are also connected via USB.

We changed from the onboard USB to a PCI USB Card. I will be checking the system at our customer on monday again.

The device is used in our test software. There you can specify different products for testing. The software gets a signal from the plc via profibus and starts the test procedure of the product. Then our "NIServer" starts its tasks and reads the data continously from the chosen device (Onlinemode). If another type of product is coming into the test cabin, the plc sends the new product ID, our System is stopping, the tasks were ended (offline). The new product will be loaded and the NIServer starts again its corresponding tasks (maybe now with different channels) and continous with the test.  

[Tiptop]

Thanks for the reply,

Please let us know about any issues you find out about on Monday.  Also, it would be great to know, even if the system is working, what the configuration of the system is.  Specifically, are the mouse and keyboard plugged into the computer's USB ports and the USB-9233 plugged into the PCI-USB port?  Everything plugged into the PCI-USB port?

My suggestion is that the mouse and keyboard should be plugged into the computer's USB ports and the USB-9233 into the PCI-USB port on its own.  If our theory is correct, isolating the USB-9233 from other USB devices should solve the problem.

Thanks,

Justin

[phonoX]

Hello,

it seems that isolating the USB Device solved the problem. The 9233 is connected to the PCI USB Device for a few weeks now and works apparently without errors.

Nevertheless we will not use NI USB devices for further customer projects until this Problem is solved. I cannot insert a PCI Card in my IPC for each USB Device - that's a little bit illogical...

greetings

[Tiptop]

I can completely understand that this issue makes creating a USB based system difficult.  I'm sorry for the inconvenience, and want to assure you that we are working hard on a solution.  Thanks to your input and feedback, we are now quite certain what the issue is and will continue working on a software solution. 

I will post back on this thread when we have a fix, or determine that a fix is too difficult.

Thanks!

Justin

[res]

We are seeing the identical problem with an NI USB-9211A thermocouple. We are submitting details here because we see the problem using NI's own software when there are no other USB devices plugged in.

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.

Please advise an estimated fix date. We are all (still) waiting.

[Hillman]

Hi All,

Res has started a new thread for his issue here.

A former UK AE has noted that the issue may have been fixed in DAQmx 8.8 - has this been tested?

Regards,

[Tiptop]

I'm sorry to report that DAQmx 8.8 does not contain a software fix for the issue discussed in this forum.  However, as a reminder there are hardware fixes.  I have personally seen the root cause of this issue being a software error generated by certain chipsets.  As we can see, our software is currently unable to recover from this error, and I'm not entirely sure that we can fix the software so that it can recover.  I will post more information as it become available.

Also, I am glad Res has started a new thread, because I have not experienced the issue that he/she is seeing with out other USB devices interacting with the hub, even on chipsets that see this issue.

As soon as I have more information, I will post back to this forum.

Thanks,

Justin 

[Tiptop]

Hey All,

For those interested in a software workaround for chipsets that see this issue, I have one that I have experimented with that will hopefully help you out while we continue to try and change the DAQmx driver so that it can recover from hardware errors. Please note that it is my workaround and not supported by NI.

The workaround is simply to disable the device in device manager and then enable the device.  I've been able to recover my device to a workable state by doing this.

Now, I understand that it is not much of an automated system if you have to manually go into device manager, so after some digging, I found devcon.exe (http://support.microsoft.com/kb/311272).  Using devcon, you can enable and disable devices in device manager programmatically.  I would strongly recommend that all DAQmx Devices are stopped before disabling all of them.  Also, I bet devcon.exe takes in a PID parameter if you want to disable a specific NI product type instead of all of them.

Then with the following two line batch file,

call devcon.exe disable *VEN_1093* *VID_3923* 

call devcon.exe enable *VEN_1093* *VID_3923*

I was able to recover the device and start using it again.

Hopefully this software workaround will help you out.  If there is anyone interested in using this fix in LabVIEW and is unfamiliar with using the "System Exec.vi", just let me
know and I'll post VI's that let you disable and enable NI devices from LabVIEW.

As always, I'll post back when I have more information for you all.

Thanks,

Justin

[Tiptop]

Hey All,

Let me first confirm that DAQmx 9.0 has a work around for this issue.

Here are some points that I have about the -50405 issue.

1.)  This issue only occurs because Microsoft Windows tells us that there has been a hardware error.

2.)  The number one cause I have seen of this issue is unplugging or plugging in a USB device and the machine's chipset yielding an error, which propagates up to our driver.  There have been reports of this error happening randomly when running for multiple days, but we have been unable to duplicate that type of failure.

3.)  We take hardware errors seriously.  We have chosen the listed work around because we do not feel comfortable ignoring hardware errors.

4.)  Up until DAQmx 9.0, the driver is unable to recover from a hardware failure with Device Reset.  In DAQmx 9.0, we invested significant effort into tearing down and rebuilding our USB communication during a device reset.  This new functionality provided in Device Reset allows you to reset the software after a hardware error.  I have include some VI Snippets of how to use "DAQmx Reset Device.vi" to recover after the -50405 error.

5.)  The NI 9172 chassis must be reset immediately upon receiving the -50405 error.  If self-test is called first, the chassis will have to be unplugged and replugged, this is a software bug on our part that has already been identified.
6.)  Since hardware is the issue, common solutions include
   a.)  Replace poor quality USB cables with high quality USB cables.  (USB 1.0 spec cables do exist and should not be used)
   b.)  Try using a PCI USB card
   c.)  Try using a powered USB hub

   d.)  Do not unplugged or plug in USB devices while the computer is up and running

Here are some VI Snippets of how to use "DAQmx Reset Device.vi" to recover from a -50405 error.

 

 

Lastly, I'm sorry about the performance of this work around on a cDAQ chassis.  I know even a down time of five seconds can be critical for some applications.  If you have this issue, want to use the software work around, and have a cDAQ chassis, you can experiment on your system and find out how long it takes the chassis to re-detect your modules after a Reset Device call.

-Justin

[JÞB]

post to keep in my pocket- I keep loosing the good referances