Free Instrument Control Software in 2026 (7 That Actually Work)

A complete instrument automation stack can be assembled for zero licence cost, and it will drive any SCPI instrument from any vendor. The free options are not a compromise tier: PyVISA, OpenTAP, and NI-VISA are all used in production.

What free does not buy you is the time to assemble it. This post covers the seven tools worth knowing, what each replaces, and the specific gaps that remain.

1. PyVISA

Replaces: the instrument communication layer of any commercial tool.

The foundation. Talks to any instrument over USB, LAN, GPIB, or serial through a VISA backend, from Python.

import pyvisa
rm = pyvisa.ResourceManager()
dmm = rm.open_resource("USB0::0x2A8D::0x1301::MY57200001::INSTR")
print(dmm.query("*IDN?"))

Genuinely free: MIT licensed, no restrictions, commercial use fine.

Limits: it is transport only. You write every SCPI command and build everything above it.

See the PyVISA tutorial.

2. NI-VISA and Keysight IO Libraries Suite

Replaces: nothing, they are the layer PyVISA needs.

Both are free downloads and neither requires a paid licence for the product suite it comes from. Either provides the VISA implementation for USB, LAN, GPIB, and serial.

Genuinely free: yes, though both are proprietary rather than open source. Download and use without a licence key.

Limits: large installers, and they can conflict if both are installed. Pick one.

The pure-Python alternative: pyvisa-py needs no installer at all. It covers LAN and serial well, USB workably, and GPIB only with extra packages. Start here and install a vendor backend only if something does not enumerate.

See Keysight IO Libraries.

3. OpenTAP

Replaces: NI TestStand and PathWave Test Automation.

A production-grade test sequencer, open source under an OSI-approved licence, originally from Keysight. Runs test plans, applies limits, publishes results through pluggable listeners, and drives from a CLI.

tap run Regression.TapPlan --settings Production

Genuinely free: yes, including deployment. No per-station licences, which is the single largest saving against TestStand.

Limits: plugins are C#, so a Python-only team faces a language decision. Instrument coverage outside Keysight is your own plugin work.

See OpenTAP vs TestStand.

4. pytest

Replaces: the sequencing layer, for engineering validation.

Not designed for hardware and remarkably good at it. Fixtures handle instrument setup and teardown including cleanup on failure, parameterisation expresses test matrices, and JUnit XML output plugs into any CI system.

@pytest.mark.parametrize("vin", [3.0, 3.3, 3.6])
def test_regulation(bench, vin):
    bench.psu.set_voltage(vin)
    assert 1.76 <= bench.dmm.dc_volts() <= 1.84

Genuinely free: MIT licensed.

Limits: no operator interface. Production operators do not run pytest, and limits live in code rather than in configuration a test engineer can edit.

5. Keysight Command Expert

Replaces: the SCPI discovery problem, partially.

Free tool that connects to an instrument, browses its complete command set with documentation, lets you test commands interactively, and exports working code in Python, C#, MATLAB, and others.

Genuinely free: yes, no licence.

Limits: Keysight instruments are best supported, and the sequencing it offers is basic. Its real value is discovery rather than automation.

Why it is worth installing even if you automate in Python: finding the correct SCPI command for a specific model is genuinely tedious, and Command Expert removes that. Use it to discover, then paste into your own code.

6. tm_devices

Replaces: Tektronix OpenChoice, and improves on it substantially.

Tektronix's own supported Python package for their instruments. Typed command access, device discovery, proper error handling.

Genuinely free: Apache licensed, open source.

Limits: Tektronix hardware only.

See Tektronix OpenChoice alternatives.

7. TestFlow free version

Replaces: the authoring step.

Browser-based, vendor-neutral, with a free version. You name the instruments and describe the measurement in plain English, and the agent generates and runs the automation.

Genuinely free: the free version, with paid plans above it.

Limits: not a real-time platform, and not a production-floor operator sequencer.

Comparison table

A complete free stack

For a mixed-vendor bench with Python capability:

Total licence cost: zero. Total build time for a first working station: one to two weeks for someone who has done it before, three to four for someone who has not.

That build time is the real price of the free stack, and it is worth stating plainly rather than pretending free means costless.

Where free genuinely stops

Being honest about the gaps:

• •Real-time and FPGA. No free option. LabVIEW Real-Time and FPGA have no open-source equivalent, and neither does a HIL platform.
• •Production operator interfaces. Free sequencers do not ship one that a factory can use. You build it, and that is a real project.
• •Multi-UUT parallel test models. Achievable, not provided.
• •Support contracts. Community support is good and is not an SLA. In regulated production this matters.
• •Sensor conditioning UIs. Nothing free matches what FlexLogger or DEWESoft do for thermocouple and bridge configuration.

If none of those apply to you, and for most bench validation none do, the free stack is genuinely sufficient.

The one thing free does not solve

Every tool here still requires someone to know which SCPI commands a particular instrument needs, in which order, with which settling times, to make a particular measurement.

That knowledge is the actual bottleneck in most labs, and it is not a licence cost. It is engineer-weeks, and it recurs with every new instrument and every new test.

A worked example: a complete free bench

To make the stack concrete, here is a working characterisation station assembled entirely from free software.

# bench.py, the reusable layer
import pyvisa, yaml

class Instrument:
    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")
        self.idn = self.inst.query("*IDN?").strip()

    def check(self) -> None:
        response = self.inst.query("SYST:ERR?").strip()
        if not response.startswith(("0,", "+0,")):
            raise RuntimeError(f"{self.idn}: {response}")

class Supply(Instrument):
    def set_voltage(self, v: float) -> None: self.inst.write(f"VOLT {v}")
    def set_current_limit(self, a: float) -> None: self.inst.write(f"CURR {a}")
    def output(self, on: bool) -> None: self.inst.write(f"OUTP {'ON' if on else 'OFF'}")

class Dmm(Instrument):
    def configure_dc(self, rng: float = 10, nplc: float = 1) -> None:
        self.inst.write(f"CONF:VOLT:DC {rng}")
        self.inst.write(f"VOLT:DC:NPLC {nplc}")
    def read(self) -> float: return float(self.inst.query("READ?"))

def open_bench(path: str = "bench.yaml") -> dict:
    config = yaml.safe_load(open(path))
    return {"psu": Supply(config["psu"]), "dmm": Dmm(config["dmm"])}

# test_regulation.py, the test itself
import pytest
from bench import open_bench

@pytest.fixture(scope="module")
def bench():
    b = open_bench()
    b["psu"].set_current_limit(0.5)
    b["dmm"].configure_dc(nplc=10)
    yield b
    b["psu"].output(False)

@pytest.mark.parametrize("vin", [3.0, 3.3, 3.6])
def test_ldo_regulation(bench, vin):
    bench["psu"].set_voltage(vin)
    bench["psu"].output(True)
    vout = bench["dmm"].read()
    bench["psu"].check(); bench["dmm"].check()
    assert 1.76 <= vout <= 1.84, f"VOUT {vout:.4f} V at VIN {vin} V"

$ pytest test_regulation.py --junitxml=results.xml -v

That is a complete, CI-integrated, three-point validation test with proper cleanup, error checking, and machine-readable results. Total licence cost: zero. Total code: about sixty lines, most of it reusable across every future test.

Add Jinja2 and WeasyPrint for a PDF report, as described in automated test report generation, and the free stack is complete.

The maintenance cost of a free stack

Free removes the invoice, not the work. Naming the ongoing cost honestly is what makes the comparison against a paid tool useful rather than rhetorical.

The last row is the real cost and it is invisible until the author leaves. A paid tool comes with documentation someone else wrote; a free stack comes with documentation you owe yourself. Pin your dependencies, write a README with the resource strings and the bench layout, and the free stack stays free. Skip both and you have built a liability.

Two mitigations that cost almost nothing. Pin versions in a requirements.txt and commit the lock file, so a working bench stays working. And keep a per-instrument notes file with the resource string, the firmware version, and the commands that turned out to be model-specific.

The bench README is the highest-value document nobody writes. A working one is short:

# Bench 3, PMIC characterisation

## Instruments
| Role      | Model            | Resource string                          | Firmware |
|-----------|------------------|------------------------------------------|----------|
| Supply    | Keysight E36313A | TCPIP0::psu-bench3::inst0::INSTR         | 1.0.5    |
| DMM       | Keysight 34465A  | TCPIP0::dmm-bench3::inst0::INSTR         | A.03.02  |
| Load      | Chroma 63801     | TCPIP0::load-bench3::inst0::INSTR        | 2.14     |
| Scope     | Tektronix MSO44  | TCPIP0::scope-bench3::inst0::INSTR       | 1.28.1   |

## Quirks
- The load needs 200 ms after `:LOAD ON` before a reading is valid.
- 34465A must be on fixed range; autorange steps mid-log on the 3.3 V rail.
- Scope firmware 1.26 and earlier used a different `CURVe?` preamble. Do not downgrade.

## Setup
    python -m venv .venv && source .venv/bin/activate
    pip install -r requirements.txt   # pinned, do not upgrade casually

That document is the difference between a free stack that outlives its author and one that does not.

What a paid tool buys that free does not

Being straight about this, because the honest comparison is what makes the free recommendation credible.

• •Someone to call. In regulated production, a support contract is not a nicety.
• •Documentation you did not write. And that stays current without your effort.
• •An operator interface. Free stacks are code, and production operators do not run code.
• •Certified versioning. Traceability of which tool version produced which result, without you building it.
• •Instrument plugins already written. Especially for the awkward instruments: VNAs, spectrum analysers, anything with binary block transfers.
• •A migration path when the author leaves. Commercial tools have a hiring pool. Your bespoke stack does not.

If none of those apply to your situation, free genuinely wins. If two or more do, price the paid option properly rather than dismissing it, and see best test automation software for the wider field.

Common mistakes

• •Installing two VISA implementations and not choosing a primary. NI-VISA and Keysight IO Libraries can coexist, but you must be deliberate about which one PyVISA opens. This is the single most common setup failure.
• •Not pinning dependencies. A working bench that breaks after an unrelated pip install is an avoidable outage.
• •Treating free as zero cost. Build and maintenance are real. See the table above.
• •Skipping the README. The bench layout, resource strings, and quirks live in one person's head otherwise.
• •Rebuilding what a library already does. tm_devices, pymeasure, and vendor Python packages cover a lot. Check before writing a driver, see Python instrument control libraries compared.
• •Assuming free means unsupported. PyVISA and OpenTAP both have active communities and are used in production at serious scale.

Related reading

• •PyVISA tutorial
• •SCPI command cheat sheet
• •Best test automation software
• •LabVIEW alternatives
• •OpenTAP vs NI TestStand
• •Python instrument control libraries compared, picking the layer above VISA
• •Instrument control with VISA and SCPI, the protocol foundation
• •Keysight IO Libraries, one of the two VISA backends
• •GPIB vs USB vs LAN, the transport decision
• •Automated test report generation, the part free stacks usually lack
• •NI software licensing costs, what the paid route costs
• •Test sequencer comparison, the sequencing layer
• •Automate multimeter measurements with Python, the free stack applied
• •NI TestStand alternatives, what the free sequencers are measured against