USB Plug-n-Play Devices (Windows)

[Blokk]

Hello,

I have got a problem which rises randomly, after several days of continuous running of my application (from the dev. environment, not exe).

My interfaces are the following (PC Win7 x64, LabVIEW 2012 Full + PID toolkit):

• 10 GPIB devices connected to PC via a single direct USB connection using NI GPIB-USB-HS interface
•   1 calibration current source with a USB-RS232 interface connection
•   1 Sorensen PSU with with direct USB connection (virtual RS232)
•   1 NI USB-TC01 thermocouple device with direct USB connection
•   3 NI USB-TC01 thermocouple devices via an externally powered USB hub

I get the following error code:

DAQ.vi
Task Name: cabinet Error -201003 occurred at DAQ.vi

Possible reason(s):

Device cannot be accessed. Possible causes:

Device is no longer present in the system.
Device is not powered.
Device is powered, but was temporarily without power.
Device is damaged.

Ensure the device is properly connected and powered. Turn the computer off and on again. If you suspect that the device is damaged, contact National Instruments at ni.com/support.

Task Name: cabinet 

 The location of the error is the "cabinet", which refers to one of the USB TC-01 device hooked up via the USB hub. After I get this error and log it, I can restart the whole application without any problem, and it runs properly. I remember Windows can do some nasty things with connected devices in order to save energy (energy save mode), but I thought it can only happen with inactive device. I read data out from all the temperature sensors with a slow rate of 1Hz.

Any suggestion what should I try to avoid this problem? I could program around the error, lets say to automatically restart the whole system, but it would require lots of work because of its complexity (TDMS file logging and 4 PID control loop in parallel).

[Sam_Sharp]

I am always slightly dubious about the reliability of USB-connected devices...I would check in device manager for any settings relating to power management in case it's putting the device to sleep. You have quite a lot of devices connected via USB so it could be related to loading/glitching on the USB bus or perhaps with the USB controller on the motherboard of the PC. You could perhaps try adding a USB controller card (e.g. PCI/PCI-E) to see if that alleviates the issue?

What sort of error handling/checking do you have in your application - maybe you could try to re-establish the task if the error occurs to avoid having to restart the software/PC and regain data acquisition from the device? This might make things more robust if something like this is happening.

[Blokk]

Thanks for the suggestions! I will wait and see if I get again the same error code. If so, I will put a section into the data read subVI to try to reinitialize the USB DAQmx tasks (but i will limit the number of tries to avoid the danger of infinite loop). Beside I will check the device manager for energy saving options. Hmm, a high speed PCI usb card is not a bad idea...Recently i just have so many usb device on the motherboard + the keyboard and mouse...

[Sam_Sharp]

Yes - in some applications, if an error occurs during data acquisition I go into a reinitialise state and stay there until the device has started working again with some timing - when the device initialises correctly then I go to my read state and continue the acquisition. You'll obviously want to notify the user that this has happened as if it happens frequently then it might mean a genuine device error.

Some higher-end motherboards have multiple USB controllers (normally the one on the southbridge / chipset) and maybe a third party one for additional ports. If that's the case then you could try plugging into a port on the other USB controller or try adding another USB controller via PCI/PCI-E. 

With quite a few devices you could be having problems with the USB controller - either to do with arbitration or it could even be a power problem (drawing too much load) - but you are using externally powered ports for some stuff so that would help against that. Some of the USB to Serial converters can be a bit flaky too, sometimes.

[JÞB]

I'll dust it off again

USB Plug-n-Play Devices (Windows)

Options

‎01-22-2012 02:20 PM

In this topic we will discuss some of the common problems that have been observed using USB devices with LabVIEW on Windows operating systems.  Many of these points are also applicable to other environments but the examples will be use the Windows 7 OS.

FAQ 1 : My USB device stops working unexpectedly.

The first thing to look at is the OS power saving options.  There is a global trend towards developing "Green" electronics and energy star ratings are getting fairly common.  "If its not being used shut it off" is nothing new.  Cavemen learned how to bank a fire to preserve energy that would otherwise be wasted.  Likewise, the Windows OS has a power saving feature to shut down power to the USB hubs when no user activity is present.  In Automated systems this feature can cause problems since removing USB hub power will shut down the USB device.   Solution: Use the device manager to change the USB hub Power Options.

FAQ2: I set the power options and my device connection is still unreliable: Remember, those computer USB ports are often the cheapest that can be mounted on the chassis and share the PC system power supply to supply USB Power. Most uses of USB are temporary connections like a thumb drive or a camera.  These connections do not require high reliability since the user is right there interacting with it.  Power surges and fault tolerance at worst cause the operator to retry the data transfer.  Automated systems require a bit more robustness.  Solutions:

1) ALWAYS use an external self powered hub.  Perform your engineering due diligence and inspect the devices specifications too- If you can't find them for that device that should clue you to seek an product from a vendor that WILL publish their specs.

2) High noise environments require the use of ferrites on the USB cable- and don't buy the cheapest cable either! The cheap ones are poorly shielded.  

3) PROTECT the HUB connections-  If you have a USB2.0 device and Joe User plugs in a 1.0 device in a open slot managed by the same hub- Bingo every port on the hub may back convert to USB1.0.  WORSE there are a lot of damaged or marginally engineered USB devices out there.  Joe User's device may cause power fluctuations when it is inserted or removed from the hub just don't let it happen!

FAQ3: I am testing USB devices and the OS can't find them anymore.

This is a Plug-n-Play feature that deserves some exposure.  When you connect a P-n-P device the OS remembers its serial number in a HKEY (Hive-Key) registry entry.  This is helpful when (for example) you want a specific instrument, Say an NI-USB-6008, to show up as a DAQmx Device with VISA Alias "MyDAQ1" every time it is plugged it.  On the other hand, If you want to test a line of USB-Serial converters this can be problematic since the P-n-P driver will mount the first serial number as "COM3" and the next as "COM4" add infinitum until the enumerator controller in the registry and VISA recognized aliases get used up.  Solution: Use the Windows registry API and the Hardware Configuration API in LabVIEW to clear unused VISA Aliases and HKEY entries.   Speak with your staff IT professional about HKEY structure and possible side effects before developing a plan to edit registry entries.

---

Pay close attention to FAQ2:  

[JÞB]

In this topic we will discuss some of the common problems that have been observed using USB devices with LabVIEW on Windows operating systems.  Many of these points are also applicable to other environments but the examples will be use the Windows 7 OS.

FAQ 1 : My USB device stops working unexpectedly.

The first thing to look at is the OS power saving options.  There is a global trend towards developing "Green" electronics and energy star ratings are getting fairly common.  "If its not being used shut it off" is nothing new.  Cavemen learned how to bank a fire to preserve energy that would otherwise be wasted.  Likewise, the Windows OS has a power saving feature to shut down power to the USB hubs when no user activity is present.  In Automated systems this feature can cause problems since removing USB hub power will shut down the USB device.   Solution: Use the device manager to change the USB hub Power Options.

FAQ2: I set the power options and my device connection is still unreliable: Remember, those computer USB ports are often the cheapest that can be mounted on the chassis and share the PC system power supply to supply USB Power. Most uses of USB are temporary connections like a thumb drive or a camera.  These connections do not require high reliability since the user is right there interacting with it.  Power surges and fault tolerance at worst cause the operator to retry the data transfer.  Automated systems require a bit more robustness.  Solutions:

1) ALWAYS use an external self powered hub.  Perform your engineering due diligence and inspect the devices specifications too- If you can't find them for that device that should clue you to seek an product from a vendor that WILL publish their specs.

2) High noise environments require the use of ferrites on the USB cable- and don't buy the cheapest cable either! The cheap ones are poorly shielded.  

3) PROTECT the HUB connections-  If you have a USB2.0 device and Joe User plugs in a 1.0 device in a open slot managed by the same hub- Bingo every port on the hub may back convert to USB1.0.  WORSE there are a lot of damaged or marginally engineered USB devices out there.  Joe User's device may cause power fluctuations when it is inserted or removed from the hub just don't let it happen!

FAQ3: I am testing USB devices and the OS can't find them anymore.

This is a Plug-n-Play feature that deserves some exposure.  When you connect a P-n-P device the OS remembers its serial number in a HKEY (Hive-Key) registry entry.  This is helpful when (for example) you want a specific instrument, Say an NI-USB-6008, to show up as a DAQmx Device with VISA Alias "MyDAQ1" every time it is plugged it.  On the other hand, If you want to test a line of USB-Serial converters this can be problematic since the P-n-P driver will mount the first serial number as "COM3" and the next as "COM4" add infinitum until the enumerator controller in the registry and VISA recognized aliases get used up.  Solution: Use the Windows registry API and the Hardware Configuration API in LabVIEW to clear unused VISA Aliases and HKEY entries.   Speak with your staff IT professional about HKEY structure and possible side effects before developing a plan to edit registry entries.

---

Pay close attention to FAQ2:  

[Blokk]

Thanks for the detailed and valuable information! I have checked the power options, and none of them were set as the Windows can turn-them off. So this point cannot be the problem. I will keep in mind the "FAQ2" part however, and I will see what I can do if I get error again.

FAQ2, point 1: the error was actually produced by a device hooked up via a hub. But I guess, if there are still too many devices connected directly to the mobo, they can make the hub also unreliable?

point2: the hub (with external PSU) is connected to the PC via a 3 meter long USB extender cable, it looks quality made, but of course this is only a guess (but no ferrite noise damper integrated). I do not know if this environment can be described as noisy, but I have a turbopump, a high capacity rotational forepump, and an electromagnetic water pump, beside the devices and the several PSUs...

[JÞB]

That 3 meter cable --- any way to relocate that? 3 meters is a bit long for high speed serial data.  And you have that hub located where nobody can stick another device in while the experiment is running right!  Ditto the PC running the experiment?  No banging on keybords web-surfing- solitare playing file accessing virus scanning etc while the machine is supposed to run your important experiment right?

Pumps pumps and pumps-  rotating magnetic fields.  You have a high noise enviornment you do not need to wonder at all.

Eye diagrams will close.  Definately check the Hub Specs.  The dandiest one of these problems I ever ran across was some time back where we used a hub with a metalic case and mounted it with velcro(tm)   wound up frying some stuff when the hub was moved (its amazing the voltage you can produce in the static discharge from velcro).

[Blokk]

"That 3 meter cable --- any way to relocate that? 3 meters is a bit long for high speed serial data."

I have a rather large distance between 3 TC01 sensors and the PC, so I had to use a HUB and a USB extender. I will try to get some quality shielded USB cable, and I may try to shield the hub. Or purchase a special shielded one, if any exists...

[JÞB]

Thermocouple wire is cheap and has a near DC frequency of information.  Extend that not the high speed USB

[Blokk]

hmm...now I feel stupid 😄

Obvious solution, even we have ready made insulated thermocouple cables in the workshop... 🙂