Upgrading a station from LabVIEW 2019 to 2024 is a mass compile on the development machine plus a Run-Time Engine and driver upgrade on every station that will run the new build. The first half takes an afternoon. The second half is where builds get stranded, because a 2024 executable won't start on a 2019 RTE, and the drivers on a five-year-old station have their own supported version ranges.
Before You Start
Write down what's on the floor before you touch the development machine. One row per station, filled in by walking to it, not from memory.
| Station | Current RTE and bitness | DAQmx and VISA versions | Who can rebuild | Runs per week |
|---|---|---|---|---|
| FCT-01 | 2019 32-bit | DAQmx 19.x, VISA 19.x | Marc | 420 |
| FCT-02 | 2019 32-bit | DAQmx 19.x, VISA 19.x | Marc | 380 |
| EOL-01 | 2019 32-bit | DAQmx 18.x, VISA 19.x | Marc | 150 |
| CAL-01 | 2018 32-bit | DAQmx 18.x, VISA 18.x | nobody | 60 |
Three things fall out of the table. The pilot station is the one with the highest volume and a complete row (FCT-01 here): it gives you a comparison in days, not months. Any station on a different bitness than your target (all of them, if you're going from 32-bit to 64-bit) needs the new RTE and new 64-bit drivers, not just the RTE. And a row with "nobody" in the rebuild column is a decision, not an upgrade: see the section on when not to upgrade.
The full inventory method, including how to read the RTE version off a running station, is in which LabVIEW version runs on each station.
The Upgrade Order
The order matters more than any single step, because each one is cheap to undo only until the next one.
- Development machine first. Install LabVIEW 2024 next to 2019, not instead of it. You'll need 2019 to rebuild the old executable if the pilot fails.
- Tag the last 2019 commit, then open the project in 2024 and run Tools, Advanced, Mass Compile on the project folder. Save everything.
- Commit the mass compile as one commit with no functional change in it, and say so in the message. Tag it. The next section is why.
- Build the executable on 2024. Fix the things the build reports (usually a deprecated VI or a changed driver palette), each in its own commit after the mass compile, never mixed into it.
- One pilot station. Install the 2024 RTE and matching DAQmx and VISA on FCT-01 only. Leave the 2019 RTE installed; RTEs coexist. Deploy the new build next to the old one.
- Side by side for two weeks. Run the 2024 build and the 2019 build on the same units, compare the measurements and the pass/fail per phase. Not just FPY: a limit that behaves differently on a new driver shows as a shift in a distribution, not always as a failure.
- Then the rest, one station at a time, in the order of your table.
Two weeks is the smallest interval where a shift in a measurement is visible against normal variation on a 400-run-a-week station. On a 60-run-a-week station, wait longer.
What Mass Compile Does to Your Git History
Mass compile rewrites every VI it recompiles, and after a version change that's every VI in the project. The repository shows as fully modified in one commit. That's unavoidable and it's fine, as long as you make it findable.
# Bracket the mass compile with two tags so history on either side stays reachable.git tag -a lv2019-last -m "Last commit built with LabVIEW 2019 32-bit"# Open the project in LabVIEW 2024, run Tools > Advanced > Mass Compile, save all.git add -Agit commit -m "Mass compile for LabVIEW 2024 64-bit. No functional change; every VI rewritten by the compiler."git tag -a lv2024-first -m "First commit built with LabVIEW 2024 64-bit"git push --tagsThe two tags do two jobs. lv2019-last is where you check out to rebuild the old executable if the pilot fails. lv2024-first tells everyone reading git log later that nothing between those two tags is a real change, so they stop looking there for the commit that moved a limit.
Keep the mass compile commit pure. If you also fix a broken VI in it, that fix is now invisible, buried in a diff of a thousand rewritten binaries. Fix it in the next commit. Separate compiled code in LabVIEW, explained covers the setting that reduces noise between mass compiles; it doesn't reduce the mass compile itself, and LabVIEW classes in particular can still show as modified after one.
The mass compile is also the moment the LVCompare story ends for the old history. Comparing a VI from before the tag with one from after shows every node as changed. That's expected, and it's why why LabVIEW version control is so painful puts mass compile among the four sources of pain.
Driver Compatibility
Each NI driver (DAQmx, VISA, and any instrument-specific driver you use) supports a range of LabVIEW versions and a bitness. A 2019 32-bit station running a DAQmx from that era won't necessarily serve a 2024 64-bit build, and the version that does serve 2024 may drop support for an older card in the chassis.
Don't guess from version numbers. Check NI's version compatibility tables for DAQmx and VISA against the LabVIEW version and bitness you're targeting, and against every card and interface in the station, before you install anything on the pilot. Write the versions you chose into the inventory table. That table is the one document the next person will need.
Two cases deserve a separate look. A station with a legacy card that the new DAQmx no longer lists is a station you can't upgrade without replacing hardware. And a PXI station with FPGA code compiled for 2019 needs the FPGA module and a recompile of the bitfile, which is its own project.
When Not to Upgrade
The upgrade is worth it for a station that will run for years and needs new instruments or new code. It's not worth it in three cases.
A station that will be replaced. If the fixture is due for a rebuild next year, leave it on 2019 and put the effort into the replacement. RTE 2019 keeps running.
A product near end-of-life. The last 5,000 units of a product don't justify the two-week side-by-side and the driver risk. Freeze the station, document it, and note the RTE and driver versions in the inventory so it can be rebuilt once if it has to be.
A PXI station with FPGA timing you can't retest. If the acceptance test for the timing needs equipment or units you no longer have, an upgrade that touches the FPGA bitfile is a change you can't validate. Don't make it.
In all three, the honest line in the inventory is "stays on 2019, rebuild from tag lv2019-last on the 2019 dev VM". Keep that VM.
The Contrast
A TofuPilot Framework station pins its runtime in text. pyproject.toml names the Python version and the packages, and the deployment built from a commit carries the resolved runtime with it.
# The runtime is pinned here; the deployment built from this commit carries it.[project]name = "controller-pcba-fct"version = "2.4.1"requires-python = ">=3.12,<3.13"dependencies = ["tofupilot", "pyvisa", "pyvisa-py"]Bumping the runtime is a one-line change in a pull request, reviewed like any other. tofupilot deploy --prod builds one immutable deployment with an id like dep_abc123, and tofupilot pull puts that same build on every station, so there's no per-station RTE to install and no station on a version the others aren't. Every run uploaded from a pulled deployment carries the deployment_id, so the side-by-side comparison is a filter in TofuPilot rather than a spreadsheet. And if the pilot fails, rollback re-pins every production station to the previous deployment with no rebuild, while the runs already uploaded keep the id of the build that produced them.
How to deploy Python test scripts to production stations covers the deployment flow, and run a mixed LabVIEW and Python test team covers the period when both kinds of station report to the same procedure.
Start With One Station
When you do move a station, the pilot from your inventory table is the one to move. Rebuild it as a procedure.yaml with phases and plugs in Python with the TofuPilot Framework, keep the same limits, and run it side by side with the LabVIEW build on the same units for two weeks, the same protocol as the upgrade.
# Install the CLI, run the station locally (no account needed), or run 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.
