Device drivers

Quatm separates experiment logic from instrument communication. Every instrument is addressed through a logical name in device_db.py; the driver decides whether that name maps to a serial port, a VISA resource, a TCP socket, a USB device or a vendor DLL.

Access modes

All modes support simulation. In simulation the same experiment code runs against a dummy backend, which is essential for developing sequences without occupying the apparatus.

Driver categories

The bundled catalogue covers:

• Real-time control — ADwin, FPGA, timing and trigger distribution.
• Lasers and light — Toptica, Moglabs, Vescent, laser locks and shutters.
• Signal generation and RF — Spectrum AWGs, Rigol, Valon, DDS boards.
• Scientific cameras — Andor, FLIR/BlackFly, PCO and generic video sources.
• Motion and positioning — PI stages, Thorlabs, piezo mirrors.
• DAQ and power supplies — NI, MCC, Keysight, Keithley.
• Environmental monitoring — temperature controllers, magnetometers, wavemeters, vacuum gauges.

The catalogue and per-driver verification status are tracked in the repository (docs/DRIVER_VERIFICATION.md). A driver is considered verified only after it has been exercised on real hardware.

Writing a driver

A driver is a normal Python class with:

• __init__ accepting the arguments declared in device_db.py;
• simulating handling for offline use;
• explicit close() releasing sockets, serial ports and vendor handles;
• optional check() / self-test hooks used by the Device Manager.

Place project-specific drivers under <project>/drivers/. They are imported before bundled drivers with the same suffix, so a laboratory can pin a local version without forking the framework.

Device health and leases

Opening a device acquires a cross-process lease, preventing two experiments from silently driving the same instrument. The Device Manager can probe instruments, verify drivers and report the current owner. Bus-level locking protects adapters that cannot be opened concurrently.