combination of devices messes up GPIB

[instrumento]

I can't seem to mix certain instruments on the same GPIB, in this case through a USB/HS GPIB adapter, yet to try it on PCI card based bus.

As soon as plug in a Newport ESP300 motor controller and a ILX LDX3220 current source on the same bus, the ESP300s stop being found by MAX, with a device didn't reply to *IDN?.  Getting an interactive window and issuing that command I eventually get the ID string back, after a much longer wait.

Our code will immediately become unreliable, with lots of timeouts from ESP300. If I move the ILX to a second bus, things work fine.

I also have problems with the same ESP300 controllers and old HP/Agilent A6624 power supply. However the same ESP300s work fine with a variety of other instruments, on some machines we have two buses with up to 16 devices in it (I know it's over the limit...) and everything works.

Not sure what to try, besides putting them on a separate bus ...

[xdaf]

Maybe there's some turned-off instrument connected to the bus? It may cause interferences sometimes. Try turning on every instrument connected to the bus (setting, of course, a different address for every instrument).

Regards

[instrumento]

All instruments are up and at different addresses.  I even tried unplugging everything and trying from my laptop.  I can talk to either either type of instrument separately.  I can talk to either type of instrument with everything else in the bus except each other.  As soon as I have one of each in the same bus, communication with the ESP300 times out, and MAX randomly fails to IDN them. 

It's a timing thing, as in the general case I have 4 ESP300s and 2 ILX LDX 3220 on the bus and which of the ESP300s fails to show is random, sometimes none, most times none. I've played with bus settings to no avail.

Curiously, with the ESP300s on a separate bus, the REMOTE light on the LDX boxes keeps flashing through the test, even though we only talk to the boxes at initialization, i.e. they're not being addressed but the REMOTE light still flickers.

[JÞB]

It happens.

Back in the day not all GPIB interfaces met the IEEE-488 standard. Even today many do not meet IEEE-488.2.

For instance:

• A certain Power supply will become unresposive if issued a *IDN? (the *IDN? command is "optional" in IEEE-488.2 but "Must not affect operation if not implemented" so, the device fails to meet IEEE-488.2. 
• An old version of an oven controller on OLD Firmware interperated *IFC (interface clear) as a "Quit Controlling" Command (VISA open in 6.1 used to issue a *IFC so, I was late to adopt VISA since my oven kept shutting off)

The solution is two-part.

A) Chose equipment manufactures that can demonstrate IEEE-488 COMPLIANCE

B) Work WITH the engineering teams of the equipment manufacturer's that make your "Trouble" instrument.  These tend to be smaller houses that can make custom changes to their FW if you can express to them WHY you need a IEEE-488 solution and not just a GPIB style interface.  Tell them your application and how their instrumentation is effecting your system.  

[instrumento]

I have one of those power supplies.  It doesn't recognize *IDN?, generates an error, and shuts the supplies off.  Can't do a scan for instruments on that one as sometimes that burns the RF receiver it is driving up.

The Newport ESP300 has just been obsoleted (replaced by the 301), but we have a ton of those (used to run them on RS232 because of poor GPIB behavior).  ILX hasn't changed their instruments in such a long time and they're not going to do it because of this.  Their GPIB interface always sucked, and that's the only interface they provide.

Solution is to put more GPIB interfaces on the system, which I guess it's good for NI 🙂 This was hard with PCI based systems as we kept running out of slots, just additional cost with USB adapters.