USB Communication Failure (App Note)
Failure modes: What is required to recover?
First, please try the following steps and note which (if any) recover your device connection.
Waiting resolves the issue.
Likely failure mode:
Temporary communication disruption.
If you continue to have communication issues, try the other steps below.
Close and restart software. Or close your software and run the test panel in LJControlPanel(UD devices) or open the device in Kipling (T-series devices).
Likely failure modes:
Improper device connection or device claimed in another process.
Temporary communication disruption.
Close all software, go to Windows Device Manager, find the USB entry for the device, right-click and "Disable", and then right-click and "Enable".
Likely failure modes:
Temporary communication disruption.
Close all software and power-cycle device.
Likely failure modes:
Improper device connection or device claimed in another process.
Temporary communication disruption.
Reboot the host.
Likely failure modes:
Software installer issue.
USB enumeration issue.
The steps above do not recover the device connection
Likely failure mode:
USB enumeration issue.
Solutions and troubleshooting ideas
Troubleshooting for any failure mode
Configure Windows Updates to not happen automatically. Depending on the type of testing you are doing, you might want to disable other automatic Windows features and other programs that run automatically (such as virus scanners). For example, if you are setting up a test designed to stream and process high-speed data continuously for a long time, uninstall (or at least turn off) everything on the computer that is not needed for the test itself.
Try disabling various operating system power-saving features. Particularly on a laptop, but this can help on desktops also.
On Windows XP, disable Selective Suspend. XP had bugs related to selective suspend, but we have not seen any problems since.
For the U12 only, with newer versions of Windows (as of March 2021) we have found that disabling Selective Suspend can cause communication disruption after some hours.
Check for current driver/library and firmware versions and upgrade if necessary.
Use a different USB host. We have found that some computers are more susceptible to transients than others.
Improper device connection or device claimed in another process.
Device USB connections can only be claimed in one process at a time. You must ensure the connection is released before opening the device somewhere else. For example, you must close out of LJControlPanel/Kipling before you can use a device in LJLogM/LJLogUD.
If you are using one of our programming APIs, check that your input parameters to the device open call are correct and match what is given from a search in LJControlPanel (UD devices) or Kipling (T-series devices).
Temporary communication disruption troubleshooting
The most likely issue is an electrical transient hitting the USB host, causing it to "forget" that a device is connected. Some hosts seem to be more susceptible to this problem than others. The transient could be radiated or conducted. It could be entering at any point (I/O cable, device, USB cable, host port). One common source of such transients is a motor (or other inductive load) that is turning on/off, particularly with a mechanical relay.
Set up the watchdog on the device to reset it if there is no communication for some time. For example, if your program constantly talks to the device once per second, you might set up the watchdog to reset after a 10 second timeout. This reset will likely be enough to signal the host that a device is connected. You can enable the watchdog using "Config Defaults" in LJControlPanel, but if there is no applicable software running the U6 will continuously reset (not a problem for the LabJack, but not sure if the computer will like that). The best method is to enable and disable the watchdog in your actual software (U12, U3, U6, UE9, T-series) so it is not active when the LabJack is sitting idle.
This problem is usually caused by a transient (e.g. EMI or ESD) getting on some wire connected to the LabJack (could be an I/O line or VS/GND), and then conducting through the LabJack through USB to the host. Remove all connections from the device, except for USB, and see if the problem goes away. If the problem does not go away, try a different location, computer, and USB cable. If the problem does go away, start adding back connections and see if you can isolate a particular connection that causes the problem, and then you can consider adding extra protection (chokes/ferrites/inductors, series resistors, parallel capacitors & TVS diodes) to problem lines. We found that a 1mH inductor in series with each line can be useful, but you have to do this on all lines including those to GND.
If you have any relays switching loads, look at adding snubbers to those relays.
Look at replacing any mechanical relays with solid-state relays specifically rated for inductive loads.
If using a USB hub, make sure it has its own power supply. Hubs that take power from the upstream USB connection are generally inferior.
We have found that 5 meter cables (max length per USB spec) seem to provide more protection for the USB host, and in particular found this cable from Amazon and this cable from Digikey to be the best. If you have a weak host and/or particularly tough environment, these cables can provide dramatic improvement.
Try a different host. We have found that some hosts are noticeably inferior to others in terms of resistance to EMI.
Consider switching to Ethernet using the UE9 or T-series. By spec, Ethernet is a more industrial interface than USB, and thus you can avoid the issue of running into a USB host that is not particularly robust.
Software installer and USB enumeration troubleshooting
For troubleshooting enumeration problems remove all connections except USB to confirm a user connection is not causing a problem.
Try different cables, ports and computers. Try a USB 3.x port, if possible. USB 3.x is more reliable. They are often distinguished by a blue insert and the initials SS.
On Windows go to Windows Device Manager (WDM) and look for any entries that appear/disappear when you connect/disconnect the LabJack. Continue to watch WDM as you try different things to see if there is any activity.
Go to the LED section of your device's datasheet (U3, U6, UE9, T-series). Compare your power-up LED behavior to what is described there.
If a device will enumerate on some computers but not others, a driver install issue is likely. On Windows go to the Windows Device Manager and look for any entries that appear/disappear when you connect/disconnect the LabJack. While the LabJack is connected go to the entry, right-click, and choose Remove or Uninstall. When Windows is done uninstalling the device, disconnect it and reconnect it to go through the add-new-hardware process again. For more information, see Windows Installer Troubleshooting (App Note).
If there is no WDM activity or strange LED activity, try the various SPC jumpers (U3, U6, UE9, T-series) installed (securely!) at power-up.
If at any point you see a WDM entry (e.g. "LabJack USB Device => LabJack T7"), remove the SPC jumper (if one is installed) and try reprogramming the firmware using Kipling or LJSelfUpgrade.
If it appears the device is constantly resetting (the LED behavior will typically indicate this), it could be the watchdog. Look at the watchdog section of your device's datasheet and a power-up jumper will be mentioned to disable the watchdog.
On T-series devices, a script can interfere with normal device operation severely enough to prevent enumeration. To forcefully disable scripts, see the SPC section of the T-series datasheet.
If you see no LED activity at all, even at power-up: