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.
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.
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.
This process depends on NI software and hardware only.
Please advise an estimated fix date. We are all (still) waiting.
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?
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.
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.
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.