VISA Limitations : Number of Instruments / Type of GPIB Talker

[Just_Amber]

Hey Y'all,

I figured I'd bug the community to get some additional input. I am also going to apologize in advance, because this is going to be a jumbled rambling with no code attached.

Background:

I'm a test engineer in a lab that mostly plays with network analyzers and switches. Occasionally we have our DAQ's, DMM's, MUX's, and other goodies but our bread and butter are those network analyzers. We speak mostly GPIB (VISA) to them.

I've also inherited quite a bit of legacy code. Some started development in LV6. Most of the executables that we have to modify are coming from LV2014 though. When a program crashes and requires the exe to be modified, we're upgrading them to LV2017 in the process.

In the past, the lab mostly used Agilent Technologies 82357B USB/GPIB Interface. We started noticing that when upgrading to LV2017 for the exe's, the network analyzers would no longer communicate with them. It was a squirrely timeout issue where in the end we just decided "white = bad, blue = good" and swapped to NI GPIB-USB-HS on all of our "critical stations."

Then for kicks and giggles, I got my managers to purchase me a new toy of the GPIB-ENET/1000 for the places where we had a really long separation between equipment and computer. I also have a few GPIB-ENET/100 that we plan on re-purposing for a few test stations as well.

Oh, I should also mention half of our computers are Windows 7, the other half are Windows 10.

tl;dr: Our lab is hodgepodge'd together with whatever I can scavenge in order to speak GPIB.

Current Frustration: 

On a Windows 7 computer, I keep having my VISA instruments drop out unexpectedly. Ideally, I would like to have all eight of my GOM-804s and my single GOM-802 on a single GPIB bus.

(Sidenote: I'm using NI Max to sleuth my GPIB instruments. This is code independent, but it is verified by when I run my code and it tells me the instruments don't exist)

Here are the rules I've found: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8slSAC

And I feel like I'm following them:

• I am under the requirement for 15 instruments (9 + 1 board < 15)
• I am under the requirement for total cable length ( 10 m cables < 20 m)
• I have tried multiple GPIB interfaces
  • The Agilent crapped out on me with any more than four devices
  • The NI GPIB-USB-HS seemed to work with 6 devices, but upping it to 9 caused all instruments to not work.
  • The GPIB/ENET 1000 appeared most stable. But then during a power cycle, all instruments dropped out. They have yet to return.

My current solution is to just have the single GOM-802 running on what I've dubbed "evil PC" and I plan on bringing up an entirely different computer for my eight other GOM-804's.

Question for Y'all:

Have any of y'all ever run into these limitations?

What's the max number of GPIB instruments that you've been reliably able to keep on a single bus?

I seem to remember at my previous job I was able to link up 12 DMM's on a single bus with no issue. I don't know if this is an issue with "evil PC," my GOM's, or how I'm hooking them up.

[Albert.Geven]

What is the communication speed on gpib. I mostly make it slower than the default because the slowest instrument determines the handshake anyway and noticrd less ringing on the lines. Try 1 micro second. And for older instruments I mostly disable paralleel polling. Also helps.

[Just_Amber]

And no matter how many times I click "edit" and change settings for the thing through Keysight, it reverts back to the default value of 500 ns.

Can you please explain more about the parallel poll duration?

[Just_Amber]

Apparently my pictures didn't post... and half of my message got cut off... Trying again...

That's a really good point about the BUS speed. I'll slow it down and see if that helps. I can see where I can change it for NI hardware, but I can't seem to modify it for my Agilent talker.

[Albert.Geven]

Hi

Check the settings of he Interface.

In your case GPIB1::INTFC

There you can enable all parallel polling. and set speeds.

[cstorey · Accepted solution]

Sounds a lot like my lab, where I can have up to 16 instruments connected to one pc via GPIB.  I use mainly SMUs, switches, PSUs, Power Meters, but that's not really important. 

Its important to remember 2 other GPIB rules;

1) most of the instruments on the bus need to be on to repeat the GPIB commands over long distances

2) you should limit the inter instrument cable distance to 2m or less.

I feel your pain with random GPIB instruments dropping out, since I've been there over the past few years.  On several setups I had problems with USB-GPIB-HS instruments loosing contact after switching to Windows 7.  Same PC, winXP, same instruments, same USB-GPIB-HS had no issues.  (I was forced to migrate to Win7 or be off the network.) 

After a lot of frustration I traced the problems to mainly how Windows 7 handles USB selective suspend ("sleep mode") to save power.  Windows 7 will power off USB ports if they aren't used frequently enough.  (To make it worse some motherboards reduce power to certain USB hubs when load gets hight..but there's not much you can do about that one!)

To prevent the USB ports for going to sleep or low power, which cause VISA sessions all kinds of problems,  use "Always ON" Power mode settings and also follow this guide to disable USB selective suspend

Win7 - https://helpdeskgeek.com/how-to/prevent-windows-from-powering-off-usb-device/

Win10 - https://www.windowscentral.com/how-prevent-windows-10-turning-usb-devices

Around the time I was having all the USB-GPIB Win7 issues, I also had some old Win2K and WinXP machines with PCI-GPIB cards that were  being surplussed since they couldn't be migrate to win7.   I had dismissed the PCI-GPIB cards in them since I had had no issues with WinXP and the USB-GPIB-HS.  But I installed a few of PCI-GPIB in my Win7 machines (replacing USB-GPIB-HS) and have had none of issues I experience with  software randomly dropping instruments and failing on me.

Not sure this will solve your problems, but it gives you something to look into at least.  Maybe you have some old PCI-GPIB cards you could try.  You can actually still buy them too.

Craig

PS- I have no experience with the GPI-ENET, but it might be a good alternative too since its probably immune to windows power settings.

[Just_Amber]

---

 (To make it worse some motherboards reduce power to certain USB hubs when load gets hight..but there's not much you can do about that one!).

---

I bet that might have been one of my many issues. We did stumble upon the USB sleep setting (DUMB!) and turned it off, but that didn't fix the problem. The "evil PC" became more irate when we had multiple USBs plugged into it.

We do have one computer that has the PCI-GPIB slot in it, and you know what? Now that you mention it, we have had zero issues with that PC. I'll scavenge and see if we have any additional cards floating around, but I doubt it.

I think I'm going to try the GPIB-ENET route first because that involves the least expensive purchase (+1 for a lab full of scavenging!). And as we continue to replace older equipment, I am going to push for us to move away from USB talkers.

[cstorey]

Post a follow up and let us know how the PCI and ENET options work out!

Craig

[Minions · Accepted solution]

When setting up multiple instrument on GPIB, avoid Daisy-chaining them (end to end).  The ideal way to communicate is via a star pattern.  We designated two star centers for our instruments using the same length cable from the controller to the two star points.  From those star points, each instrument is connected to those points from a single cable of no more than 2 meters.  This helps to reduce the reflection and overall travel of any command/response.

[Just_Amber]

I'll also switch my network to more star like than daisy chain like. I'm currently fighting the installation of an GPIB-ENET / 100 on a completely different (Windows 10) laptop so at the moment, I can't even see any of the GPIB devices. *sigh*

I can't wait until I'm able to do my actual engineering work...