PyVISA Tutorial in 2026 (Control Any Lab Instrument from Python)

PyVISA is a Python package for controlling measurement instruments over USB, LAN, GPIB, and serial. It wraps the VISA standard so that one API drives a Keysight multimeter, a Tektronix oscilloscope, and a Rigol power supply without you caring which cable they are on.

This tutorial covers installation, finding instruments, resource strings, the write and query distinction, binary waveform transfer, and the six traps that reliably waste an engineer's first afternoon.

Install

pip install pyvisa pyvisa-py

pyvisa is the API. The second package is a backend, and you need exactly one backend. Three choices:

Start with pyvisa-py over LAN. If a USB instrument will not enumerate or you need GPIB, install a vendor backend. See Keysight IO Libraries.

Find your instrument

import pyvisa

rm = pyvisa.ResourceManager()
print(rm.list_resources())

That prints resource strings. To see what each one is, ask it:

import pyvisa

rm = pyvisa.ResourceManager()
for resource in rm.list_resources():
    try:
        inst = rm.open_resource(resource)
        inst.timeout = 2000
        print(f"{resource}\n    {inst.query('*IDN?').strip()}")
        inst.close()
    except Exception as exc:
        print(f"{resource}\n    no response: {exc}")

*IDN? is universal. Every SCPI instrument answers it with manufacturer, model, serial number, and firmware version. If an instrument does not answer *IDN?, nothing else in this tutorial will work on it and the problem is the connection, not your code.

LAN instruments often do not appear in `list_resources()`. Discovery relies on mDNS or a configured list. Just address them directly:

scope = rm.open_resource("TCPIP0::192.168.1.50::inst0::INSTR")

Resource strings decoded

TCPIP0::192.168.1.42::inst0::INSTR
USB0::0x2A8D::0x1301::MY57200001::INSTR
GPIB0::22::INSTR
ASRL3::INSTR

Common vendor IDs: 0x2A8D Keysight, 0x0957 older Agilent, 0x0699 Tektronix, 0x1AB1 Rigol, 0xF4EC Siglent.

Write, read, query

The single most important distinction in PyVISA.

inst.write("VOLT 3.3")            # command, no response expected
value = inst.query("MEAS:VOLT?")  # command + read response
raw = inst.read()                 # read only, when a response is pending

Rule: if the SCPI string ends in `?`, use `query`. Otherwise use `write`.

Getting this wrong is the number one cause of mysterious timeouts. inst.write("MEAS:VOLT?") sends the query, the instrument puts a response in its output buffer, and nobody reads it. Your next query then reads that stale response and everything is off by one from that point on.

A complete session

import pyvisa

rm = pyvisa.ResourceManager()
dmm = rm.open_resource("USB0::0x2A8D::0x1301::MY57200001::INSTR")
dmm.timeout = 10000                    # milliseconds

try:
    print(dmm.query("*IDN?").strip())
    dmm.write("*RST")
    dmm.write("*CLS")

    dmm.write("CONF:VOLT:DC 10,0.0001")  # 10 V range, 100 uV resolution
    dmm.write("TRIG:SOUR IMM")

    for _ in range(5):
        print(f"{float(dmm.query('READ?')):.6f} V")

finally:
    dmm.close()
    rm.close()

*RST puts the instrument in a known state. *CLS clears the status and error registers. Doing both at the start of every script eliminates an entire category of "it worked yesterday" problems caused by leftover configuration.

Always check the error queue

SCPI instruments do not raise exceptions. Send a command with a typo and the instrument records an error and carries on. Your script produces numbers that look fine and are wrong.

def check(inst):
    problems = []
    while True:
        response = inst.query("SYST:ERR?").strip()
        code = int(response.split(",", 1)[0])
        if code == 0:
            break
        problems.append(response)
        if len(problems) > 20:
            break
    if problems:
        raise RuntimeError("instrument errors: " + "; ".join(problems))

Call it after every configuration block. This function finds more real bugs than any other twelve lines you will write.

Binary waveform transfer

For anything larger than a few hundred points, ASCII transfer is slow enough to dominate your run time. Use binary.

scope.write("DATA:SOURCE CH1")
scope.write("DATA:ENC RIBINARY")
scope.write("DATA:WIDTH 2")

ymult = float(scope.query("WFMOUTPRE:YMULT?"))
yoff = float(scope.query("WFMOUTPRE:YOFF?"))
yzero = float(scope.query("WFMOUTPRE:YZERO?"))
xincr = float(scope.query("WFMOUTPRE:XINCR?"))

raw = scope.query_binary_values("CURVE?", datatype="h", is_big_endian=True)
volts = [(point - yoff) * ymult + yzero for point in raw]
times = [i * xincr for i in range(len(volts))]

datatype follows Python's struct codes: "b" signed byte, "h" signed short, "f" float. It must match the DATA:WIDTH you set, and endianness must match the encoding. Get either wrong and you receive a plausible-looking waveform that is complete nonsense.

The scaling step is not optional. CURVE? returns digitiser levels, not volts.

The six traps

1. Timeout too short. The default is 2000 ms. A DMM doing a high-resolution integration, or a scope doing a long acquisition, takes longer. Set inst.timeout generously, 10000 ms or more for slow operations.

2. Missing termination character. Serial and some LAN instruments need an explicit terminator.

inst.read_termination = "\n"
inst.write_termination = "\n"

Symptom is a hang on the first query.

3. Querying a write-only command. inst.query("VOLT 3.3") sends a command that produces no response, then waits for one. Guaranteed timeout.

4. Not waiting for slow operations. Some commands return immediately but take time to complete. Use *OPC?, which blocks until the instrument finishes.

scope.write("AUTOSET EXECUTE")
scope.query("*OPC?")            # blocks until autoset completes

Use it deliberately rather than everywhere, because it costs a round trip.

5. Assuming SCPI is portable. It is standardised at the top of the tree and vendor-specific below it. *IDN?, *RST, and *CLS are universal. MEASUREMENT:IMMED:VALUE? is Tektronix and means nothing to Keysight. Always use the instrument's own programming guide.

6. Leaving instruments in a live state on error. Wrap in try/finally and disable outputs in the finally. A crashed script that leaves a supply at 12 V into a device rated for 3.3 V is an expensive bug.

Making it reusable

Once past the first script, wrap each instrument in a class.

class Dmm:
    def __init__(self, resource: str, timeout_ms: int = 10000):
        self.inst = pyvisa.ResourceManager().open_resource(resource)
        self.inst.timeout = timeout_ms
        self.inst.write("*RST"); self.inst.write("*CLS")

    def dc_volts(self, dc_range: float = 10, resolution: float = 1e-4) -> float:
        self.inst.write(f"CONF:VOLT:DC {dc_range},{resolution}")
        return float(self.inst.query("READ?"))

    def __enter__(self): return self
    def __exit__(self, *exc): self.inst.close()

Now the test reads as the test rather than as SCPI:

with Dmm("USB0::0x2A8D::0x1301::MY57200001::INSTR") as dmm:
    assert 3.2 <= dmm.dc_volts() <= 3.4

This is the point at which instrument code stops being a script and starts being maintainable. Eight methods per instrument is usually enough.

Talking to several instruments at once

Real tests use more than one instrument, and the pattern that scales is one ResourceManager and a dictionary keyed by role.

import pyvisa

ADDRESSES = {
    "psu":  "TCPIP0::192.168.1.42::inst0::INSTR",
    "dmm":  "USB0::0x2A8D::0x1301::MY57200001::INSTR",
    "load": "GPIB0::8::INSTR",
}

rm = pyvisa.ResourceManager()
bench = {}
for role, address in ADDRESSES.items():
    inst = rm.open_resource(address)
    inst.timeout = 10000
    inst.write("*RST"); inst.write("*CLS")
    print(f"{role:6s} {inst.query('*IDN?').strip()}")
    bench[role] = inst

Two things this buys you. The addresses live in one place, so moving an instrument from USB to LAN is a one-line change. And printing every *IDN? at startup gives you a record of exactly which serial numbers produced the run, which matters when a result is questioned months later.

Close them properly in a finally, and disable anything that sources power first:

finally:
    bench["psu"].write("OUTP OFF")
    bench["load"].write("INP OFF")
    for inst in bench.values():
        inst.close()
    rm.close()

Timeouts per operation, not per session

A single session timeout is a compromise: too short for a slow integration, too long to notice a hung instrument quickly. Set it per operation instead.

from contextlib import contextmanager

@contextmanager
def timeout(inst, ms: int):
    previous = inst.timeout
    inst.timeout = ms
    try:
        yield inst
    finally:
        inst.timeout = previous

dmm.timeout = 2000                     # quick default, catches problems fast
with timeout(dmm, 60000):              # this one operation is genuinely slow
    dmm.write("CAL:ALL?")
    result = dmm.read()

A short default is the useful part. With a 30-second blanket timeout, a wrong command wastes 30 seconds per occurrence and hides in a long run. With 2 seconds, it fails fast and obviously.

Backends, and why the same script behaves differently on two machines

The single most confusing part of pyVISA for newcomers. pyVISA is a wrapper; it does not talk to instruments itself. Underneath sits a backend, and which one you get is decided by a search order you did not choose.

import pyvisa

rm = pyvisa.ResourceManager()          # whichever backend is found first
rm = pyvisa.ResourceManager("@py")     # explicitly pyvisa-py
rm = pyvisa.ResourceManager("/Library/Frameworks/VISA.framework/VISA")  # explicit path

print(rm.visalib)                       # print what you actually got

Always print rm.visalib when a script works on one machine and not another. Nine times out of ten the two machines resolved different backends, and the tenth is a firewall.

pyvisa-py is the one worth knowing: pure Python, pip-installable, no vendor driver, and it covers LAN and USB completely. For a LAN-only bench it removes the entire vendor-driver install from your setup, which makes the whole stack reproducible from a requirements.txt. See GPIB vs USB vs LAN for whether you need more than that.

Closing sessions properly

The trap that produces "resource busy" errors an hour into a debugging session. A VISA session held by a crashed script can block the next one, and on some backends it survives the interpreter exiting.

import pyvisa
from contextlib import closing

rm = pyvisa.ResourceManager()
with closing(rm.open_resource("TCPIP0::192.168.1.42::inst0::INSTR")) as inst:
    inst.timeout = 10000
    print(inst.query("*IDN?"))
# session closed even if the block raised

Three habits: use a context manager or a finally, close the ResourceManager at the end of a long-running process, and if you do hit a stuck session, power-cycle the instrument's interface rather than hunting for the process. On LAN instruments, most have a "close all connections" option in the web interface, which is faster than either.

Common mistakes

• •Not knowing which backend you have. Print rm.visalib. See above.
• •Leaving the default timeout. It is often 2 seconds, which is far too short for a long acquisition and far too long for a discovery scan. Set it per operation.
• •Using `read()` after `write()` instead of `query()`. Same thing, more ways to get the ordering wrong.
• •Ignoring the termination character. read_termination and write_termination differ by instrument and by transport. If reads hang, this is the first thing to check.
• •Not checking `SYST:ERR?`. SCPI instruments do not raise. They queue the error and carry on.
• •Hard-coding resource strings. They change when a USB port or an IP changes. Use hostnames on LAN, and discover on USB.
• •Opening a new `ResourceManager` per instrument. One manager, several resources.
• •Assuming `query_binary_values` defaults match your instrument. Datatype, endianness, and container all need to match what you configured on the instrument.

Related reading

• •SCPI command cheat sheet, the commands to send
• •Instrument control with VISA and SCPI, the concepts underneath
• •Python instrument control libraries compared, the layers above pyVISA
• •GPIB vs USB vs LAN, choosing the transport
• •Free instrument control software, the whole zero-cost stack
• •Keysight IO Libraries, one of the backends
• •Automate multimeter measurements with Python, a first real script
• •Automate a Keysight power supply with Python, the stimulus side
• •Automate a Rigol oscilloscope with Python, binary transfers in practice
• •How to automate a VI curve sweep, multiple instruments together
• •Keysight Command Expert alternatives, finding the right command
• •LabVIEW to Python migration, where this leads
• •Automated test report generation, what to do with the data
• •Best test automation software, when a script is no longer enough
• •NI TestStand alternatives, the sequencer above the instrument layer