GPIB-USB-HS occasionally loses instrument comms, how to recover in software?

[lkraft]

Hi all,

We are using the NI GPIB-USB-HS for production fixtures. Our machines are running an in-house C# application on Win10/64 using NI VISA and NI 488.2 v21.5. To the best of my knowledge, we are using recommended practices for device communications (based on reference manuals and provided examples).

The problem is that our production process requires electrical arcing, which generates EMI and causes either the GPIB cable or the instrument to lose comms. After an incident, the GPIB controller is often visible in NI-MAX but the instrument is not. Sometimes I must manually unplug the GPIB cable to restore functionality, and other times I must Scan For Instruments in NI-MAX to recover. Occasionally the GPIB reports status -37052.

I'm working on a way to use a powered USB hub to cycle GPIB power after an event occurs, but I cannot "Scan For Instruments" through the NI-VISA / NI-488.2 .NET libraries. Any ideas on how I can get around this?

[lkraft]

I also want to emphasize that while the EMI is likely contributing to the problem, we have similar stations that are apparently much more resilient. As in, this problem may happen once a week versus once every five minutes. My electrical resource is double-checking the hardware but I'm under the assumption that they are practically identical.

We've also seen this happen occasionally on fixtures that do not generate EMI and are not "at risk" for this kind of fault. A TekVISA "Scan For Instruments" call would be helpful regardless.

I have seen TekVISA.FindResources(string FindString, out System.Collections.ArrayList FindList) and also TekVISA.GPIBResources but both of these return empty sets. After going into NI-MAX and "Scan For Instruments", the GPIB resource shows up immediately.

[rntaboada]

Hello
Reading your post, I want to comment that I have a similar problem, maybe someone else had the same.
I developed a control application for testing with an Electrical Safety (ES) tester, specifically the CHROMA 19052 (Hi-Pot Tester). As is known this instrument during testing can develop output test voltages from 1.25kV up to 2.5kV, depending on the insulation class of the product under test (Class I or Class II). The control is done through the NI USB GPIB HS (or HS+) interface. Testing without connecting anything to the Hi-Pot instrument (no load) works fine. But under load, somehow, and for some reason, the GPIB interface disconnects from the host PC, LabVIEW throws error -1073807265 (this is a gross oversimplification of the dynamics of the situation, there are more details). After this I have to, possibly, disconnect the USB cable, shut down the CHROMA unit and start again. The failure is recurring.
There is an article that mentions this error (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9v2SAC&l=es-AR), but it does not help me in the resolution.
What I am thinking now is that it may be EMI that is causing this interface disconnection.
I ask you, were you able to solve your problem?
Thank you very much.

[Iwa6]

This may be improved by electrically isolating the GPIB I/F and the measuring instrument.
However, NI's GPIB Isolator is already EOL, so you will need to look for second-hand or third-party products.

Example

NI Products : GPIB-120A , GPIB-120B

ICS Electronics Product

Zenisu Product : Optical Isolator

[rntaboada]

Iwa6

Thanks for the reply. I was working hard on this problem today. I investigated if the problem was not in the Unit Under Test (a production line LCD TV). Testing this TV with the covers off, I didn't see anything unusual until I took the main board out and left it isolated on the table for HiPot testing. And there the suspect's face appeared. An electrical ARC on one of the spark gap (discharger).

Apparently, this ARC noise produces so much electrical noise that it leads to a malfunction of the instrument's internal GPIB interface.
Testing with a normal load, which does not present this ARC phenomenon, the instrument works fine, and the interface does not lose connection at any time. So I have already identified the problem, and also that the instrument has a problem because if the ARC setting parameter is OFF, and if a UUT presents normal dielectric current (during HiPot testing), combined with noise due to ARC, the GPIB interface will eventually fail.

[JÞB]

So, I have to ask.

Did you change the default Windows Power Management option for the USB hub using Windows Device Manager?

Windows will shut off the USB hub Power after it detects no use for a set period of time.   Your device is NOT a HID (human input device) like your mouse so, you can't shake it to turn the port back on.

[rntaboada]

Hello JÞB

It is a bit long to explain in a few lines the disconnection problem. The last week I have been working hard to understand the problem. I discovered that during the Hi-Pot test at 2500 VAC (on a TV), a strong arcing phenomenon occurred that exceeded the detection scale of the instrument, and thus, put this instrument beyond the limits of its design to be able to handle high energy arcing phenomena. The arc produced such an amount of electrical noise that it caused the SERIAL and GPIB boards to disconnect. I was able to see on the oscilloscope the electrical noise generated in the power (DC) path of the communication boards. The communication fails in the face of high energy arcing phenomena.

I am still talking to the instrument manufacturer's support to see if there is a solution.

[JÞB]

---

@rntaboada wrote:

Hello JÞB

It is a bit long to explain in a few lines the disconnection problem. The last week I have been working hard to understand the problem. I discovered that during the Hi-Pot test at 2500 VAC (on a TV), a strong arcing phenomenon occurred that exceeded the detection scale of the instrument, and thus, put this instrument beyond the limits of its design to be able to handle high energy arcing phenomena. The arc produced such an amount of electrical noise that it caused the SERIAL and GPIB boards to disconnect. I was able to see on the oscilloscope the electrical noise generated in the power (DC) path of the communication boards. The communication fails in the face of high energy arcing phenomena.

I am still talking to the instrument manufacturer's support to see if there is a solution.

---

You need to also look at the entire USB subsystem components.  Do use an externally powered USB Hub. I usually recommend Belkin because they actually publish Hub power and surge withstand specifications. Do not use cheap USB cables! Those are poorly shielded. Use the expensive ones that have integrated Ferrites.  Your USB to GPIB adapter probably shipped with a detached split Ferrite ring, follow the instructions in the user's guide to install it correctly. 

You most likely damaged every transient suppressor in your entire system.  That is an expensive mistake since you cannot actually test each component.   And, since you can't test them, you can find no evidence to disprove the "NULL Hypnosis" that they are unsuitable for use.  Therefore: the only sane action is to discard everything and rebuild the system with new tested components.   OUCH!

That is an unfortunately common oversight problem for test engineers.  They forget that sometimes the test system ACTUALLY DOES ITS JOB and finds a unit that fails dramatically.   Your Test System should not destroy itself just because the DUT is bad.

[rolfk]

Hi Voltage and Arc Testing should be always done with fully electrically isolated devices. And yes that means that GPIB is not a good communication interface, and in fact not even Ethernet is, despite its isolation transformers. What has worked for me in the past was to actually use fiber optic coupled RS-232 interfaces and according communication channels on the instrument and computer side. It allows you to place the actual instrument close to the test and the computer several meters away, possibly even in a (partial) faraday cage. Anything else is playing Russian roulette in my experience. Either the communication is randomly interrupted and often hard to restore, or actual hardware damage can even happen over time.

Those electronics are all tested to withstand a certain ESD but! Not 100ds of times a day, every day again.

[3TMQ]

Hi Ikraft,

Indeed, transient voltages and currents will stress each isolation barrier, which can cause damage making a device unreliable.  You have suggested that one test station appears to fault more often.  This could be because test station components have become stressed and less/unreliable (even at the transistor level within ICs) - as Rolf suggests can happen.  Also, why one test station appears more prone to this problem, may simply be in the power wiring layout between the instrument, GPIB-USB-HS, HUB (and other USB items), and the computer.

Ground connections between the instrument and the computer are critical, and should be tightly connected so that a transient voltage cannot be developed between the two.  Worse, I guess the hub may be powered from a mains adaptor, and transient voltage differential may easily capacitively couple across this, into your USB network.  Look at ways to eliminate this, e.g. grounding the HUB DC supply with the instrument/computer, and transient suppressing the mains to the adapter, etc.  You have to keep it out, and keep everything on the computer side of the instrument at the same level.

Once a bit is flipped by a transient, all bets with software are off, and a power cycle is the only fix (along with a hope no silicon has suffered degradation).

The suggested fibre optic isolation is a good option, but again, you will need to keep the isolator on the instrument side, tightly tied to the instrument.

Oh, and one other thing, if you are doing a discharge test, high fast currents will induce voltages in nearby cables,. So consider carefully, the (potential) discharge current path, and the magnetic field it will produce.  Keep all your cables on the network side close together so you don't have a loop that will couple with that field.  If the field is too big, then a Faraday cage and/or distance to the UUT is needed.

I hope these ideas are of some help.

Regards

Michael