✉ Contact & Support
Have a question, found a bug, or need help getting started? Just send an email — no web forms, no ticket systems, no chatbots.
📌 Just curious or figuring out a detail before buying? Send a message — pre-sales questions are very welcome.
Why email, not a web form?
Forms and ticket systems create friction, lose formatting, and strip out attachments. Email works everywhere, lets you attach log files and screenshots, and gives you a proper thread in your own inbox to refer back to.
We read every message and reply as soon as possible. If your question might help others, we'll add it to the documentation.
A good first message helps us help you faster. Please try to include:
Many questions are already answered in the documentation. Worth checking before sending an email:
| Resource | What it covers |
|---|---|
| Quick Start Guide | First-time setup, cable connections, LED states, first GPIB command |
| User Manual | Complete reference — all operating modes, settings, API, troubleshooting appendix |
192.168.3.2 has a built-in GPIB console. If you can send *IDN? there and get a response, the hardware is working — the issue is on the software side.
A running FAQ of known quirks and interoperability details. Click a question to expand it.
I use Keysight IO libraries and use GPIBee in USBTMC mode. My instrument BEEPS whenever I turn it on or connect GPIBee.
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.
My instrument doesn't reply to *IDN? — I get a timeout error
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.
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.
My PC has (or had) a GPIB PCI/PCIe card — can GPIBee replace it?
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.
I have a GPIB-USB-HS and NI-VISA stopped working on my Mac — can GPIBee replace it?
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.