✉ Contact & Support

Use gpib0 instead of inst0 in the resource string. So TCPIP::192.168.3.2::gpib0,23::INSTR rather than TCPIP::192.168.3.2::inst0,23::INSTR. hpib0 works too. That is the whole fix.

Here is what is going on. Given a resource string of the form inst0,<address>, Keysight IO Libraries drops the ,<address> part and opens plain inst0. On GPIBEE, bare inst0 is the adapter's own internal SCPI device. So the connection never carries the GPIB address, and you end up talking to the adapter rather than through it to your instrument.

That explains all three symptoms at once. The session opens successfully, so there is no error telling you the address went missing. The adapter does not implement your instrument's command set, so replies are wrong or absent. And service requests never arrive, because the instrument that would raise them is not the one you are connected to. With gpib0,<address> or hpib0,<address> the full name is passed through, the adapter sees the address, and everything including SRQ behaves.

This is specific to Keysight IO Libraries, in both the 2023 and 2025 releases. NI-VISA handles inst0,<address> correctly, which is why the same code can work on one machine and not on another.

This is a known interaction between Keysight VISA and USBTMC-mode instruments.

Keysight VISA — like NI-VISA — runs a background service that automatically detects new instruments and sends each one an *IDN? query to identify it. USBTMC devices can report, via their USB descriptor, whether they are IEEE 488.2 compliant and whether they support SCPI. When both are set to "not supported," a detection service is expected to skip the automatic query — but Keysight VISA currently queries these instruments anyway.

On instruments that don't support *IDN?, this triggers exactly the behaviour you're seeing: a BEEP and/or a queued error on the instrument, and it may also switch it into remote mode — even though you never sent that command yourself. We've reported this behaviour to Keysight; understandably, their priority is Keysight-branded instruments, so a broader fix may take a while.

Workaround: GPIBEE has a setting to suppress *IDN? writes to instruments — only enable it if you're actually affected by this. Keysight VISA does offer its own GUI option to disable automatic *IDN? queries during instrument detection, but that option is only available for VXI-11 instruments — it's simply not offered for USBTMC instruments, so for the USBTMC case described here, GPIBEE's setting is the workaround.

This is almost always a property of the instrument itself, not of GPIBEE — GPIBEE simply sends the query and waits for a reply, so if the instrument never answers, the transaction times out.

More recent GPIB instruments generally implement the SCPI/IEEE 488.2 command set, which makes *IDN? a mandatory, standardized identification query. Older, pre-SCPI instruments often don't follow this convention — many early HP-IB devices only support a bare ID? query instead, and some have no identification query at all.

There are also instruments that are "listen-only" on the bus — they can receive commands but have no ability to talk back, so no query, including *IDN?, will ever get a response from them.

You can check whether an instrument is capable of talking at all from its capability codes, often printed on a small label on the back or bottom of the case. Each short code describes one IEEE 488.1 interface function; the T code specifically covers talker capability. T0 means the instrument has no talker capability at all — it can never respond to any query. Any other T value means it can talk — but that only confirms it's physically capable of sending a response, not that it understands *IDN? specifically; whether it supports that particular query still has to be checked separately in the instrument's manual.

Example capability code label. This instrument shows T6, meaning it is capable of TALK.

If the label shows T0, the instrument simply cannot answer any query — that's not a fault, just how it was built, and no configuration change will fix it. If it shows another T value, try a bare ID? instead of *IDN?, or check the instrument's manual for its specific identification command, especially on older, pre-SCPI instruments.

Yes. GPIBEE is a good replacement for a GPIB PCI or PCIe controller card, especially if the original card is no longer available, isn't supported on current operating systems, or the PC it was installed in has been retired.

GPIBEE connects over USB or Ethernet instead of a PCI slot, so it works with any modern PC or laptop without an internal card, while still presenting itself to your software as a standard VISA GPIB interface — so existing scripts and drivers generally keep working unchanged.

Likely yes, and you're not alone in running into this. NI hasn't shipped an updated NI-VISA/NI-488.2 driver for GPIB-USB-HS(+) on macOS since the 2023 Q3 release, which only supports up to macOS 12 — the GPIB kernel extension it relies on can't load on macOS 13 and newer, so the adapter stops being recognized after an OS update. This isn't an isolated report either; it's a recurring topic on NI's own community forum.

GPIBEE doesn't run into this because it doesn't need a proprietary NI driver or kernel extension in the first place. It connects over USB or Ethernet and speaks VXI-11 and USBTMC — open protocols that NI-VISA, R&S VISA, and PyVISA already understand natively on macOS — so it keeps working across macOS updates without waiting on NI to ship a fix.