Communication dropout with GPIB-USB-B

[Kevin@SRS]

I'm operating a system with multiple devices using the GPIB-USB-B adapter. Every couple of weeks the program looses communication with a random device. If you run the NI Measurment & Automation Explorer program it also won't find the instrument at that ID.

However if you unplug & re-plug the GPIB-USB-B USB cable from the computer and run the NI Measurment & Automation Explorer program it will find all of the devices correctly. And then work for another couple of weeks before it dies again, normally on a different device.

[Albert.Geven]

Do you plug or unplug other USB devices?

[Kevin@SRS]

No.

Sometimes the program has run unattended for many hours or even a few days before it looses the device. Other times  it happens in under an hour.

[JÞB]

Since you don't have access to the FAQ area (Its not live yet) I'll just copy this write-up  FAQ 1 & 2 have some pretty good tips to stop this behavior

---

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

[Kevin@SRS]

This all seems like a good idea & I'll try it.

But how come the program looses just 1 or 2 devices sometimes with the rest still operating correctly?

[JÞB]

---

Kevin@SRS wrote:

This all seems like a good idea & I'll try it.

But how come the program looses just 1 or 2 devices sometimes with the rest still operating correctly?

---

Without digging deeply into your hardware that is difficult to answer.  1 marginal port?  one hub suseptable to external noise? bad regulator supplying the port??  very unpredictable.

[Kevin@SRS]

No I mean I have one GPIB-USB converter connected to ~6 GPIB instruments (all connected together w/ GPIB cables) of various manufacturers. Occasionally communication is lost with ONE of the GPIB instruments. The others keep working. If I run the NI Measurment & Automation Explorer program it also won't find the GPIB instrument that communication is lost with. But I will find all of the rest of the instruments.

This occurs on two different systems at random intervals (days to weeks apart), so it isn't dependent on a single instrument, cable or computer.

[JÞB]

AHhhh THAT is different than what I thought I read.

Now we have some digging to do,  somethings flakey here

Do the two systems have identical equipment?

What are the equipments?  (You wouldn't believe how much fun I've had finding out how to work around "GPIB" instruments that were non-compliant to IEEE-488)

You are within spec on total cable length, total number of devices, 2/3 of devices powered on, no conflicting addresses etc..... right?

Any special device that seems the most Flakey? Any %100 never have this problem?

This can get frolicsome but bear through it!

[Kevin@SRS]

We've checked all the normal GPIBy things (6 devices, about 8m cabl, all dif addr). As I mentioned, everythings works, sometimes for days at a time. Both systems have identical instruments in them.

The devices are a mix: Agilent, Tek, SRS. I *think* there is no pattern as to which device looses communication. Since it happens infrequently it's kind of hard to tell. I'll do some more research into this.

But my real confusion is why is communication (& device ID) lost between the computer and a particular instrument. It isn't that the instrument misses some commands. The National Instruments driver completely looses it from the attached devices list. If you run NI Measurment & Automation Explorer, the lost instrument isn't in the list until you disconnect & reconnect the GPIB-USB pod.

Does the NI driver remove a device from its list if it can't communicate with it?

[JÞB]

You wouldn't think VISA or the NI488 driver would forget a device. (But I have corresponded with people that have sworn that it happens)  the Agilent and Tek instruments can be dismissed (they have a good history with me)  What Standford Research Systems devices are on the bus?  Do you power the USB to GPIB adapter through a external powered hub that does state in its specifications that each port has a 500mA regulated supply?  

Darn- even that's not really enough if you have a GPIB device that is "not pulling the load" on a handshaking line and is, on rare occasions, contending handshaking with too much load on the 5V......

Model numbers! esp the power source for the USB-GBIP hub supply and the SRS devices.

----Getting fun now isn't it?