Code review needs a diff, and a .vi has none outside LVCompare on a licensed machine with the same LabVIEW version installed. So on most production floors the review of a test change is "the integrator sent the new build", and the first person to see the change is the operator. This guide covers what a review is for on a test station, why it doesn't happen with VIs, and a checklist that gets you most of it anyway.
What a Review Is For on a Test Station
Three kinds of change reach a station, and each one deserves a second pair of eyes before it runs on product.
A limit changed. The 3.3 V rail lower limit moves from 3.2 V to 3.15 V. The reviewer asks who decided, whether there's a deviation or a design change behind it, and what happens to units that measured 3.17 V last month.
A phase was added. A new leakage measurement goes in after Power Rails. The reviewer checks that it has limits, that it doesn't add twenty seconds to a cycle that was already the bottleneck, and that it doesn't need a fixture change nobody planned.
A fixture workaround went in. A retry loop around a flaky relay, a 500 ms delay before a SCPI query, a pin skipped because pogo 14 is worn. These are the changes that become permanent, and the review is the only moment anyone asks whether they should.
None of this is about style. On a station the review is about limits and outcomes, because those decide what ships.
Why It Doesn't Happen With VIs
A review is a sequence of small steps, and every one of them assumes text.
| Review step | What it needs | What a .vi gives you |
|---|---|---|
| See what changed | A line diff | "Binary files differ" |
| See who changed which part | Blame per line | One author for the whole file |
| Read it without tooling | A browser and a pull request page | LabVIEW Professional with LVCompare, the same version, every dependency resolving |
| Comment on a specific change | A line anchor | A screenshot with an arrow drawn on it |
| Merge two reviewed changes | A three-way text merge | LVMerge, Professional only, with known cases of duplicated nodes |
| Connect the change to results | A version stamped on each run | Nothing, unless the build writes one |
LVCompare is a real tool and it's good at its job. It loads two VIs and highlights the nodes that were added, removed, moved or rewired.
But it ships only with the Professional Development System, at roughly $5,500 per seat per year since the move to subscription, and it needs both VIs loaded, so every subVI, class and library has to resolve on the reviewer's machine. What it can and can't do is in LVCompare and LVMerge: what they cannot do.
The practical result is that the review moves to whoever has that machine. On most floors that's the person who made the change, which isn't a review.
What Teams Do Instead
Three workarounds are common. Each one gets part of the job done and misses a specific thing.
Screenshots in a ticket. The author pastes the new block diagram, sometimes with the old one next to it. The reviewer sees what the author chose to show, and misses a changed constant on a subVI, a rewired case structure two frames over, or a typedef that shifted every caller.
A second engineer opens the VI. This needs a seat, the same version and someone who reads LabVIEW, which on many teams is a set of one.
The second engineer sees the new state without the old one and reviews from memory. When the team has one LabVIEW engineer, bus factor in test engineering explains why this reviewer usually doesn't exist.
LVCompare on the reviewer's PC. This is the closest thing to a real review. It needs the Professional seat and the same version, and files sometimes have to be renamed to open two copies, which breaks classes and their members.
Nothing is recorded: no comment thread, no approval, no link from the change to the build that carried it. And when two people changed the same VI, the merge is a separate problem, which fix LabVIEW merge conflicts on binary VIs covers.
A Review Checklist That Works on a LabVIEW Station Anyway
You can't diff the VI, so move the things that need review out of it.
- Put limits in a config file the VI reads at startup. A CSV or INI next to the executable turns a limit change into a one-line text diff, reviewable in any Git host, even though the VI that reads it stays binary.
- Write one CHANGELOG line per build: build number, date, author, what changed, why, and the ticket. The reviewer reads the line before the build reaches the floor.
- Show the build number and LabVIEW version in the About box, and have the build write the same number to a
version.txtnext to the executable. - Turn on separate compiled code for the project, so a "modified" VI in Git means its source changed and not that a callee recompiled it.
- Run the new build on one golden unit before it goes to the floor, and attach that run to the CHANGELOG line.
The limits file is the piece that pays back first.
measurement,unit,min,maxrail_3v3,V,3.15,3.4rail_5v,V,4.85,5.15leakage_ua,uA,,50When the 3V3 lower limit moves, the pull request on this file shows 3.2 becoming 3.15, the author, the date and a place to ask why. That's most of a review, and it needed no LabVIEW licence. Items 3 and 5 together are what let you answer later which units ran which limit, which trace a test change to the units it shipped goes into.
Most floors already have a review process. It's the operator, and the outcome is whether the line stops.
The Contrast: A Pull Request on a Limit Change
On a Python station under the TofuPilot Framework, the limit lives in procedure.yaml, and the same change is a pull request that any Git host renders.
main: - name: Power Rails python: phases.power_rails measurements: - name: rail_3v3 unit: V validators: - operator: ">="- expected_value: 3.2+ expected_value: 3.15 - operator: "<=" expected_value: 3.4A reviewer answers three questions from the diff alone, without opening anything else. What changed: the lower limit on rail_3v3, from 3.2 V to 3.15 V, and nothing else in the file.
Why: the pull request description, which links the deviation or the design note. What it does to units already tested: any unit that measured between 3.15 V and 3.2 V failed before and passes now, and the reviewer asks for that count from the run history in TofuPilot before approving.
Six months later, when someone asks who lowered that limit, the answer is one command.
# Who changed the rail_3v3 lower limit, and in which commit.git blame -L '/rail_3v3/,+6' procedure.yaml# 7c2e91a4 (Priya Nair 2026-03-11 14:02:33 +0100 24) expected_value: 3.15The merge creates a deployment, the station pulls it, and every run uploaded after that carries the deployment id. The reviewer who approved the change opens the procedure in TofuPilot a week later and compares FPY before and after that deployment, which closes the loop the screenshot in the ticket never could.
Start With One Station
Pick the station whose limits change most often, rebuild it in Python with the TofuPilot Framework with the same limits, and run it next to the LabVIEW version on the same units for two weeks. The first limit change after that is your first real review.
# Install the CLI, then run the station locally (no account needed) or with upload.curl -fsSL https://www.tofupilot.app/install | shtofupilot run ./procedure.yamltofupilot run ./procedure.yaml --uploadThe rebuild is in how to migrate from LabVIEW to Python for manufacturing tests with TofuPilot, and the framework is at tofupilot.com/products/framework. The Lab tier is free, and tofupilot run works without an account.
