GPIB Primer

If you have never plugged in a GPIB cable, this page covers what you need to know. GPIB is a 50-year-old bus standard that remains the primary remote control interface for a vast installed base of precision test equipment. Understanding the basics helps when things do not work as expected.

What is GPIB

GPIB stands for General Purpose Interface Bus. It was originally developed by Hewlett-Packard in the late 1960s as HP-IB (Hewlett-Packard Interface Bus) for connecting their instruments to computers. IEEE standardized it in 1975 as IEEE 488, and it was revised in 1987 as IEEE 488.2, which added the common command set (*IDN?, *RST, *CLS, etc.) and the status reporting model.

The physical connector is a 24-pin Centronics-style plug with a distinctive stackable design — you can plug multiple connectors onto the same instrument port, which makes daisy-chaining straightforward.

Key specifications:

Property	Value
Data width	8 bits parallel
Max devices	15 (including the controller)
Max cable length	20 meters total, 4 meters per segment
Max data rate	~1 MB/s (theoretical), ~300 KB/s typical
Address range	0—30 primary, 0—30 secondary
Signal levels	TTL (active low, open-collector)

Bus topology

GPIB uses a bus topology: all devices share the same set of 24 signal lines. Connections can be made in a daisy-chain (instrument A to instrument B to instrument C) or in a star pattern using a GPIB cable hub. Electrically, both are equivalent — every device sees every signal.

graph LR
    CTRL["Controller<br/>address 0"]
    IA["Instrument A<br/>address 1"]
    IB["Instrument B<br/>address 5"]
    IC["Instrument C<br/>address 22"]

    CTRL --- IA --- IB --- IC

    style CTRL fill:#78350f,stroke:#d97706,color:#fde68a
    style IA fill:#334155,stroke:#94a3b8,color:#e2e8f0
    style IB fill:#334155,stroke:#94a3b8,color:#e2e8f0
    style IC fill:#334155,stroke:#94a3b8,color:#e2e8f0

One device on the bus must be the Controller-In-Charge (CIC). The controller manages bus traffic: it decides which device talks, which devices listen, and when data transfers happen. In mcgpib, the AR488 bridge is always the controller.

Devices play three roles:

• Controller — Manages bus state, addresses devices, sends interface commands
• Talker — Sends data onto the bus (one at a time)
• Listener — Receives data from the bus (multiple devices can listen simultaneously)

At any moment, there is at most one talker. The controller assigns the talker and listener roles by sending address commands while the ATN line is asserted.

stateDiagram-v2
    [*] --> Idle
    Idle --> Talker : Controller sends<br/>Talk Address (MTA)
    Idle --> Listener : Controller sends<br/>Listen Address (MLA)
    Talker --> Idle : Controller sends<br/>Untalk (UNT)
    Listener --> Idle : Controller sends<br/>Unlisten (UNL)
    Talker --> Idle : ATN asserted
    Listener --> Idle : ATN asserted

    note right of Talker : Only one talker<br/>at a time
    note right of Listener : Multiple listeners<br/>allowed

Addressing

Every device on the GPIB bus has a primary address from 0 to 30. Address 0 is conventionally used by the controller. Instruments typically ship with a factory default address (often printed on the rear panel) and let you change it through the front panel menu or DIP switches.

Common factory defaults:

Instrument	Typical default address
HP/Agilent/Keysight multimeters	22
Keithley multimeters	16
HP/Agilent power supplies	5
Tektronix oscilloscopes	1
Stanford Research instruments	Varies (often 2)

Note

Address conflicts cause mysterious failures. If two instruments share the same address, bus scans may find only one (or neither), and commands intended for one may be received by both. When setting up a bench, verify that each instrument has a unique address.

IEEE 488 also defines secondary addresses (0—30) for devices that need multiple logical channels on a single primary address. Most instruments do not use secondary addressing, and mcgpib’s bus_scan only operates on primary addresses.

Signal lines

The GPIB connector carries 24 lines: 8 data, 3 handshake, 5 bus management, and 8 ground.

Data lines (DIO1—DIO8)

Eight parallel data lines carry one byte at a time. All bus communication — commands and instrument data — travels over these same lines. The ATN signal distinguishes between command bytes (ATN asserted) and data bytes (ATN released).

Handshake lines (DAV, NRFD, NDAC)

These three lines implement a reliable asynchronous data transfer that works regardless of device speed. Every single byte on the bus goes through this handshake:

Line	Name	Driven by	Purpose
DAV	Data Valid	Talker	”The data on DIO1-8 is valid, you can read it”
NRFD	Not Ready For Data	Listener(s)	“I am not ready to accept the next byte yet”
NDAC	Not Data Accepted	Listener(s)	“I have not finished reading the current byte”

The handshake sequence for one byte:

sequenceDiagram
    participant T as Talker
    participant BUS as Bus Lines<br/>(DAV / NRFD / NDAC)
    participant L as Listener(s)

    Note over L: NRFD=asserted, NDAC=asserted
    T->>BUS: Place data on DIO1–DIO8
    L-->>BUS: Release NRFD (ready)
    T->>BUS: Assert DAV (data valid)
    L->>BUS: Read byte from DIO1–DIO8
    L-->>BUS: Release NDAC (accepted)
    T-->>BUS: Release DAV
    L->>BUS: Assert NRFD + NDAC (ready for next)

Because NRFD and NDAC are open-collector (active-low, wired-AND), the bus automatically waits for the slowest device. A fast instrument cannot be overwhelmed — it simply holds NRFD or NDAC until it is ready.

Tip

This three-wire handshake is why GPIB is reliable even with a mix of fast and slow instruments. Unlike RS-232 or USB, there is no need for flow control negotiation or buffer management. The hardware handles it.

Bus management lines

Line	Name	Purpose
ATN	Attention	When asserted: data lines carry bus commands. When released: data lines carry instrument data. Only the controller drives ATN.
IFC	Interface Clear	Asserted by the controller for at least 100 microseconds to reset all device interfaces. This is the “hard reset” for the bus (not instrument settings).
REN	Remote Enable	When asserted: instruments accept remote commands. When released: instruments operate from front panel only.
SRQ	Service Request	Asserted by any device that needs attention. The controller must serial poll to find out who asserted it.
EOI	End Or Identify	Asserted by the talker on the last byte of a message, or by the controller during a parallel poll.

Service Request (SRQ)

SRQ is the interrupt mechanism of GPIB. When an instrument needs attention — a measurement completed, an error occurred, a trigger was received — it asserts the SRQ line. Because SRQ is a shared bus signal, the controller cannot tell from the line alone which device asserted it.

To identify the source, the controller performs a serial poll. This is a special bus operation where the controller asks each device for its status byte. The status byte contains:

• Bit 6 (RQS) — Set if this device asserted SRQ
• Bit 5 (ESB) — Event status bit (details in the Event Status Register)
• Bit 4 (MAV) — Message available in the instrument’s output buffer
• Bits 7, 3—0 — Instrument-specific

Reading the status byte clears the RQS bit and releases SRQ (if no other device is holding it).

In mcgpib, the check_srq tool reads the SRQ line state and automatically calls find_rqs to identify the requesting device. The serial_poll tool lets you read the status byte from specific instruments or all known listeners.

SCPI

The Standard Commands for Programmable Instruments (SCPI) is a command language layered on top of IEEE 488.2. It defines a hierarchical command structure organized by measurement function:

MEAS:VOLT:DC?       Measure DC voltage
CONF:CURR:AC 1,0.01 Configure for AC current, 1A range, 10mA resolution
TRIG:SOUR BUS       Set trigger source to bus trigger
SYST:ERR?           Read the error queue

graph TD
    ROOT["SCPI Root"]
    MEAS["MEASure"]
    CONF["CONFigure"]
    SENS["SENSe"]
    TRIG["TRIGger"]
    CALC["CALCulate"]
    SYST["SYSTem"]
    OUTP["OUTPut"]
    INST["INSTrument"]

    ROOT --> MEAS
    ROOT --> CONF
    ROOT --> SENS
    ROOT --> TRIG
    ROOT --> CALC
    ROOT --> SYST
    ROOT --> OUTP
    ROOT --> INST

    MEAS --> MV["VOLTage"]
    MEAS --> MC["CURRent"]
    MEAS --> MR["RESistance"]
    CONF --> CV["VOLTage"]
    CONF --> CC["CURRent"]
    SENS --> SV["VOLTage"]
    SENS --> SF["FREQuency"]
    SYST --> SE["ERRor?"]
    SYST --> SB["BEEPer"]

    style ROOT fill:#78350f,stroke:#d97706,color:#fde68a
    style MEAS fill:#334155,stroke:#94a3b8,color:#e2e8f0
    style CONF fill:#334155,stroke:#94a3b8,color:#e2e8f0
    style SENS fill:#334155,stroke:#94a3b8,color:#e2e8f0
    style TRIG fill:#334155,stroke:#94a3b8,color:#e2e8f0
    style CALC fill:#334155,stroke:#94a3b8,color:#e2e8f0
    style SYST fill:#334155,stroke:#94a3b8,color:#e2e8f0
    style OUTP fill:#334155,stroke:#94a3b8,color:#e2e8f0
    style INST fill:#334155,stroke:#94a3b8,color:#e2e8f0

Query vs command

SCPI commands ending with ? are queries — they ask the instrument for data and expect a response. Commands without ? configure the instrument and produce no response.

Type	Example	Behavior
Query	MEAS:VOLT:DC?	Instrument measures and sends the result
Command	CONF:VOLT:DC 10	Instrument configures itself, sends nothing
Common query	*IDN?	Returns identification string
Common command	*RST	Resets instrument to defaults

The IEEE 488.2 common commands (prefixed with *) work across all compliant instruments:

Command	Purpose
*IDN?	Identification: manufacturer, model, serial, firmware
*RST	Reset to power-on defaults
*CLS	Clear status registers and error queue
*ESE N	Set event status enable register
*ESR?	Read and clear event status register
*OPC	Set OPC bit when all pending operations complete
*OPC?	Return “1” when all pending operations complete
*SRE N	Set service request enable register
*STB?	Read status byte (same as serial poll, but as a query)
*TST?	Run self-test, return result
*WAI	Wait until all pending operations complete

Common subsystems

Most SCPI instruments organize commands into subsystems:

Subsystem	Purpose	Example
MEAS	One-shot measurement (configure + trigger + read)	MEAS:VOLT:DC?
CONF	Configure measurement function	CONF:RES 1E6
SENS	Detailed sensor/function configuration	SENS:VOLT:DC:RANG 10
TRIG	Trigger configuration	TRIG:SOUR IMM
CALC	Math and data processing	CALC:FUNC AVER
SYST	System settings and error handling	SYST:ERR?
OUTP	Output enable (power supplies, signal generators)	OUTP ON
INST	Channel/instrument selection (multi-channel units)	INST:SEL P6V

Note

Not all instruments implement SCPI. Equipment manufactured before the early 1990s typically uses proprietary command sets. The HP 3478A multimeter, for example, uses single-character function codes (F1 for DC voltage, F2 for AC voltage, etc.) rather than SCPI hierarchy. mcgpib works with both styles — it sends whatever text you give it directly to the GPIB bus.

Why GPIB still matters

GPIB was designed in an era when instruments cost tens of thousands of dollars and were built to last decades. That installed base has not gone away:

• Precision equipment — Many GPIB-only instruments (HP 3458A 8.5-digit multimeter, Keithley 6517B electrometer, HP 8566B spectrum analyzer) have no modern equivalent at the same performance and price point on the used market.
• Calibration labs — Reference-grade equipment often uses GPIB exclusively. USB and LAN interfaces are common on newer models but do not cover the full range of available standards.
• Test fixtures — Existing production test stations with GPIB wiring continue to operate because replacing them costs more than maintaining them.
• Reliability — The three-wire handshake, open-collector bus, and robust connectors make GPIB extremely reliable for long cable runs in electrically noisy environments.

Modern alternatives (USB-TMC, LXI/Ethernet, VXI) exist for new instruments, but they do not address the massive installed base of GPIB equipment. Projects like AR488 and mcgpib make it possible to control this equipment with modern software without buying expensive proprietary GPIB controllers.