SCPI Command Cheat Sheet for Lab Instruments (2026 Reference)

SCPI is a text command language for test instruments, standardised at the top of the command tree and vendor-specific below it. That single fact explains why a cheat sheet is useful and why it can never be complete: *IDN? works everywhere, and the command to read a peak-to-peak voltage differs between every oscilloscope vendor.

This reference collects the commands that come up daily, organised by instrument class, with the syntax rules and the specific places vendors diverge.

Syntax rules

Short and long form. Documentation writes MEASure:VOLTage:DC?. The uppercase letters are the short form. MEAS:VOLT:DC? and MEASURE:VOLTAGE:DC? are both valid and identical. Mixed case is accepted. Use short form in scripts.

The colon. Separates levels of the tree. A leading colon returns to the root:

VOLT 3.3;:CURR 0.5          correct, CURR resolves from the root
VOLT 3.3;CURR 0.5           may fail, CURR is looked up under VOLT

This is the single most common chaining bug.

The question mark. Makes a command a query, which returns a response. Anything with ? needs a read. Anything without must not be read.

Parameters. Space-separated after the command, comma-separated between them.

CONF:VOLT:DC 10,0.0001

Channel lists. (@1) or (@1,3) or (@1:4) for a range.

VOLT 3.3,(@1)
OUTP ON,(@1,2)

Universal commands (IEEE 488.2)

These work on every compliant instrument.

**Start every script with *RST then *CLS, and check SYST:ERR? after every configuration block.** That is the entire error-handling discipline and it is worth more than the rest of this page.

Digital multimeter

MEAS vs CONF plus READ. MEAS:VOLT:DC? resets the function and reconfigures every time, which is slow. For a loop, use CONF once outside and READ? inside. This alone can double throughput.

NPLC is the accuracy and speed dial. NPLC 10 is slow and quiet, NPLC 0.02 is fast and noisy. NPLC 1 rejects mains hum well and is a good default.

Power supply

Always set limits before enabling the output, and always read setpoints back. Supplies clamp silently to their range and report no error.

Oscilloscope

This is where vendors diverge most. Both columns shown.

Rigol scopes largely follow the Keysight-style colon-prefixed tree, which is why Rigol scripts often port from Keysight examples with modest changes. See automating a Rigol oscilloscope and Keysight vs Tektronix.

Function and arbitrary waveform generator

`OUTP:LOAD` catches everyone. Generators default to assuming a 50 ohm load. Drive a high-impedance input with that default and you get exactly twice the amplitude you asked for. Set it to INF for scope inputs and most digital circuits.

Electronic load

Note that loads use INP rather than OUTP. Sending OUTP ON to a load is a common and confusing error.

Switch and matrix

Channel numbering is typically slot then channel, so 1001 is slot 1 channel 01. Always ROUT:OPEN:ALL before configuring, or you inherit whatever the previous test left closed.

The debugging loop

When a command does not work:

1. 1

   Confirm the instrument is there. *IDN?. If this fails, the problem is the connection.

2. 2

   Reset. *RST then *CLS. Removes leftover state.

3. 3

   Send the single command in isolation, then immediately SYST:ERR?. Do not debug inside a loop.

4. 4

   Read the error text. -113,"Undefined header" means the command does not exist on this model. -222,"Data out of range" means the value is wrong, not the command.

5. 5

   Check the programming guide for that exact model. Not the family, not a generic reference.

Step 3 is the one people skip and it is the one that resolves most problems in under a minute.

Reading a SCPI response correctly

Responses are strings and they arrive in forms that trip up naive parsing.

Two habits worth adopting. Always strip() before parsing, because trailing newlines are normal and int("1\n") works while bool("0\n") does not do what you expect. And never compare a boolean response as a string: "0" is truthy in Python, so if inst.query("OUTP?"): is true whether the output is on or off.

Chaining commands to cut round trips

Every command is a round trip, so a script sending 5,000 short commands spends real time on latency alone. Semicolons combine them into one transfer.

inst.write("VOLT 3.3;:CURR 0.5;:OUTP ON")

The leading colon after each semicolon returns to the root of the tree. Without it, the second command is resolved relative to the first one's node, which either errors or, worse, silently addresses something else.

Within one subsystem you can omit it deliberately:

inst.write("CONF:VOLT:DC 10;:VOLT:DC:NPLC 10")   # cross-subsystem, colon needed
inst.write("TRIG:SOUR IMM;COUN 1")               # same subsystem, no colon

Queries chain too, and the responses come back separated by semicolons:

response = inst.query("VOLT?;:CURR?")
voltage, current = (float(v) for v in response.strip().split(";"))

Combining a configuration block into one write typically removes 60 to 80 percent of the setup latency in a loop.

Temperature chamber and environmental

Less standardised than the instrument classes above, because many chambers speak Modbus rather than SCPI. Where SCPI is offered, this is the shape.

The one to get right is the stability flag. Reaching a setpoint is not the same as being stable at it, and measuring during the overshoot is a common source of results that will not reproduce. Poll the stability condition and add a dwell on top of it:

def wait_stable(chamber, target_c, tol=1.0, dwell_s=600, timeout_s=7200):
    import time
    t0 = time.time(); stable_since = None
    while time.time() - t0 < timeout_s:
        actual = float(chamber.query(":MEAS:TEMP?"))
        if abs(actual - target_c) <= tol:
            stable_since = stable_since or time.time()
            if time.time() - stable_since >= dwell_s:
                return actual
        else:
            stable_since = None
        time.sleep(10)
    raise TimeoutError(f"chamber never stabilised at {target_c} C")

Status and synchronisation

The subsystem most people skip and then need at exactly the wrong moment. These are standard across every SCPI instrument.

The practical pattern for anything slow (an acquisition, a sweep, a calibration) is to issue the command then *OPC?, which blocks until it finishes rather than guessing at a sleep:

scope.write("ACQuire:STATE ON")
scope.query("*OPC?")            # returns when the acquisition is genuinely done
value = scope.query("MEASUrement:IMMed:VALue?")

Start every session with *CLS so you are not reading errors left over from someone else's session. That single habit removes a category of confusing failures.

Common mistakes

• •Assuming a command is standard because it looks standard. Only the IEEE 488.2 * commands and the top of the tree are portable. Measurement commands are vendor territory.
• •Skipping `SYST:ERR?`. SCPI does not raise. A rejected command silently leaves the previous setting in place.
• •**Using a fixed sleep instead of *OPC?.** Either too slow or intermittently wrong, and the wrong one is worse.
• •Forgetting the short form is the capitalised part. :SOURce:VOLTage:LEVel and :SOUR:VOLT:LEV are the same command. Mixed partial abbreviations are not.
• •Omitting the leading colon after a semicolon. CMD1;:CMD2 restarts at the root. CMD1;CMD2 stays in the current subsystem, which is usually not what you meant.
• •Not clearing status at session start. *CLS first, every time.
• •Trusting a command copied from a different model in the same series. Firmware and options differ. Check *IDN? and *OPT?.

Related reading

• •PyVISA tutorial, sending these commands from Python
• •Instrument control with VISA and SCPI, the concepts
• •Keysight Command Expert alternatives, finding model-specific commands
• •Keysight 34465A SCPI commands, a full worked reference
• •Automate multimeter measurements with Python, the DMM section applied
• •Automate a Keysight power supply with Python, the supply section applied
• •Automate a Tektronix function generator with Python, the AWG section applied
• •Automate a Rigol oscilloscope with Python, the scope section applied
• •GPIB vs USB vs LAN, the transport underneath
• •Python instrument control libraries compared, wrapping these commands
• •Free instrument control software, the zero-cost stack
• •Keysight 33600A programming, another worked example
• •Automated test report generation, recording what the commands returned
• •NI TestStand alternatives, where these commands become test steps