Special expertise · Test automation

Test automation: instruments, sequencing and data in one program.

From LabVIEW programs that ran my cryostats overnight to production software on a factory line. This page sets out the automation problems I faced and how I solved them, then shows the programs themselves.

PhD · 2009–2014Thermoelectric and Nernst system, LabVIEW, 40+ versions Research Fellow · 2017–2021Lock-in tunnelling system, LabVIEW Industry · 2023–nowProduction control software for a photonic wafer prober

1.1 · Principles

How I automate a measurement.

I automate a measurement so that it runs the same way every time, without anyone watching, and so that every number can be traced back to how it was taken. Six principles, used in every system I have built:

Settle, then measure

No point is taken until every controlled quantity, temperature, field or bias, has reached its setpoint and passed a stability test. Most wrong data comes from measuring too early.

Recipes, not code changes

A run is a list of setpoints and timings loaded from a file. Changing an experiment means editing the recipe, not the program, so runs repeat exactly.

Closed loops where they matter

Temperature under PID on two stages, the magnetic field under a gaussmeter PID with a limited ramp rate, the sample heater ramped instead of stepped.

Safe states by default

Heaters switch off by themselves at the end of a sequence, and recipes start and end at zero so instruments never jump.

Every raw reading kept

Each reading is saved with its time, not just averages, so a result can be re-analysed later without re-measuring.

Traceable runs

A run log records settings and a remark for every run, so months later any data file can be traced back to how it was taken.

2.1 · Problem by problem

From my PhD, research-fellow and industry systems.

01Measuring before the system has settled
02A field that is not what was asked for
03Comparing a 1 and a 0 at the same field
04Experiments that keep changing
05Leaving a cryostat running overnight
06Eight instruments from different makers
07Data you can still trust months later
08Thousands of sweeps to analyse
09A tool the factory host can control
10Production cannot stop for a glitch

Getting trustworthy data

01PhD · Research Fellow

Measuring before the system has settled

Why it’s hard: Most wrong data is taken too early, while temperature, field or bias is still moving.
What I did: Gated every point on a stability test: distance from setpoint and standard deviation over a time window for temperature, a per-channel settling delay for bias and field.
Result: No point taken in a transient.

02Research Fellow

A field that is not what was asked for

Why it’s hard: An electromagnet driven open-loop drifts and overshoots, so the field at the sample is not the setpoint.
What I did: Closed the loop through a gaussmeter at the sample running its own PID on the magnet supply, with a limited ramp rate.
Result: The field is what the recipe asked for, reached smoothly.

03Research Fellow

Comparing a 1 and a 0 at the same field

Why it’s hard: A skyrmion bit is written by the field’s history, so the program must control sweep direction as well as value.
What I did: Made bias and field independent command channels, each with its own list of setpoints, settling delay and data file.
Result: Bias sweeps, field sweeps and time traces from one program.

Running unattended, safely

04PhD · Research Fellow

Experiments that keep changing

Why it’s hard: Editing code for every new run is slow and introduces bugs.
What I did: Defined each run as a recipe file of setpoints, heater currents and times, read by the program.
Result: New experiments without code changes, and runs that repeat exactly.

05PhD

Leaving a cryostat running overnight

Why it’s hard: A heater left on, or an instrument stepped abruptly, can ruin a sample or a run.
What I did: Ramped the sample heater instead of stepping it, switched it off automatically at the end of each sequence, and started and ended recipes at zero.
Result: Overnight runs with no one watching.

06PhD · Research Fellow

A rack of instruments from different makers

Why it’s hard: Each instrument speaks its own command set over GPIB or VISA, and timing between them matters.
What I did: Drove them all from one LabVIEW program: temperature controller, three nanovoltmeters, current sources, a source-measure unit, a DMM, the magnet supply, a lock-in and a gaussmeter.
Result: One front panel for the whole experiment.

Keeping results traceable

07PhD · Research Fellow

Data you can still trust months later

Why it’s hard: Averages hide problems, and a file with no context cannot be re-analysed.
What I did: Saved every raw reading with its time, and wrote a run log with the settings and a typed remark for every run.
Result: Any result can be traced to how it was taken, and re-analysed without re-measuring.

08Research Fellow · Industry

Thousands of sweeps to analyse

Why it’s hard: Comparing runs by hand is slow and inconsistent.
What I did: Wrote a MATLAB pipeline to import, filter, bin, average and plot thousands of sweeps the same way, and later a Python framework for wafer-test data.
Result: Every report compared like with like.

Production: software a factory can run

09Industry

A tool the factory host can control

Why it’s hard: Production lines expect equipment to report states and alarms and take commands over SECS/GEM.
What I did: Implemented SECS/GEM from the HSMS layer up, with equipment states, alarms and reconnection.
Result: The prober integrates with factory systems.

10Industry

Production cannot stop for a glitch

Why it’s hard: A stage fault or database error must not cost a wafer or a shift.
What I did: Built automatic stage and database recovery, a vacuum interlock, traceable motion logs and versioned recipes recorded on every run.
Result: Long, stable runs on customer production lines.

3.1 · My LabVIEW programs

Read out of the saved files.

Two of my LabVIEW programs, redrawn from the saved files, and the production software I architect today.

Thermopower and Nernst 4.16 · PhD

NCMR Assembly 2.55 · Research Fellow

The production control software is described in the wafer prober case study →

Why it matters to you

The same discipline, from a lab bench to a production line.

Stability gating before measuringSoak and settle criteria in test flows
Recipe files instead of code changesVersioned test recipes and sequences
Closed loops on temperature and fieldThermal heads and stimulus control
Safe states and automatic shutdownInterlocks and fault recovery
Raw data and run logsTraceability and failure analysis