Python for Lab Work
Python for experimental work: analyzing data, controlling instruments, and building the software that runs a measurement.
New here? Start with Setup & Installation and Python Basics — everything else assumes those.
Start Here
| Page | What it covers |
|---|---|
| Setup & Installation | Installing Python, VS Code, the scientific stack, and the hardware drivers for the instruments you actually use (NI-VISA, NI-488.2/GPIB, NI-DAQmx, Thorlabs Kinesis) |
| Workflows | Notebooks vs. scripts and when to reach for each; working in VS Code |
| Python Basics | The language itself — values, functions, loops, imports, and the errors you’ll meet first |
| Working Effectively | Writing calculations as reusable functions, building your own module, keeping raw data separate from analysis |
Analyzing Data
| Page | What it covers |
|---|---|
| Arrays and Plotting | NumPy arrays, reading and writing data files, and Matplotlib figures you can put in a report. The rest of this section builds on it |
| Curve Fitting | Fitting a model with scipy.optimize.curve_fit; parameters, uncertainties, residuals, χ², weighted fits |
| Error Propagation | Propagating uncertainties by hand and with the uncertainties package |
| Fourier Analysis | DFT/power spectra with rfft, frequency resolution, windowing, and aliasing |
Talking to Instruments
Adapt-this-snippet patterns for instrument control and data acquisition — reach for these when you need to control a device or pull in data and want a working example to start from.
| Page | What it covers |
|---|---|
| VISA Instrument Control | Controlling bench instruments over VISA with pyvisa, including GPIB addressing (NI-488.2) |
| DAQ Devices (NI-DAQmx) | Reading voltages and waveforms directly off a DAQ device’s analog/digital channels with nidaqmx |
| Motor Control (Thorlabs Kinesis) | Driving a Thorlabs motorized stage from Python via the Kinesis SDK (pythonnet bridge) |
Building Lab Software
Guides, not snippets. Where the reference pages give you a working example to adapt, these walk through building lab software — the design decisions, the trade-offs, and the structure that keeps a growing project maintainable. They’re meant to be read start to finish, not consulted line by line.
The guides build on each other. You start by wrapping a single instrument in a reusable class, then share that instrument across processes, then assemble a full acquisition app, put a GUI on it, and finally step back to the architecture that holds a larger application together. Read them in order the first time; each one assumes the ideas from the one before.
| Step | Guide | What it covers |
|---|---|---|
| 1 | Instrument Wrapper Classes | Wrapping an instrument in a reusable Device class; subclassing for a specific model |
| 2 | Sharing an Instrument Across Processes | A socket server that arbitrates access so multiple scripts or threads can use one bus without conflict |
| 3 | Structuring a Data-Acquisition App | Organizing files, acquisition loops, and threading into a maintainable data-taking application |
| 4 | Building a GUI | A live-plotting desktop app with PySide6 + PyQtGraph (with a note on Tkinter for lighter needs) |
| 5 | Architecting a Lab App (MVC) | Separating View, Model, and Controller; hardware abstraction; thread-safety via signals; offline/mock mode |
A few conventions
- Examples assume
import numpy as npandimport matplotlib.pyplot as pltwhere those libraries are used. - Instrument addresses, serial numbers, and file paths in the examples are placeholders — replace them with values for your hardware.
- SCPI commands (the text strings sent to instruments) are specific to an instrument model. The examples note which model they were written for; consult your instrument’s programming guide to adapt them.