A built LabVIEW executable runs only on the Run-Time Engine of the same version and bitness, so the answer to "which LabVIEW version runs on each station" has to be written down, one row per station. Most plants can't produce that list in under a day, because the version lives in an installer someone ran three years ago and nowhere else. This guide gives you the inventory, a script that flags the mismatches, and a way to keep the list true.
The Failure Mode: A Build That Won't Start
The development machine gets upgraded to LabVIEW 2024 64-bit. A limit change is built there, copied to a station that has run the same executable since 2019, and the operator double-clicks it. A dialog says the required LabVIEW Run-Time Engine can't be found, names the version, and points at ni.com.
Nothing is wrong with the build. The compiled code inside a LabVIEW executable targets one Run-Time Engine version and one bitness, and the station has RTE 2019 32-bit installed. RTE 2024 64-bit is a separate install, and so is RTE 2024 32-bit.
Sometimes the executable starts and fails later instead. NI-DAQmx and NI-VISA each support a range of LabVIEW versions, so a station on an old driver can load the new executable and then error on the first DAQ call. Either way the station is down until someone with admin rights installs the right RTE and drivers, on a floor PC that often has no internet connection.
How to Find the RTE on a Station
You need four things from each station: the Run-Time Engine version, its bitness, the NI-DAQmx version and the NI-VISA version. Then you need the LabVIEW version and bitness the executable was built with, which comes from the development machine, not the station.
| What you need | Where it is |
|---|---|
| RTE version and bitness | Windows Programs and Features, entries named like "NI LabVIEW Runtime 2019 (32-bit)" |
| RTE on newer stations | NI Package Manager, Installed tab, filter on "Runtime" |
| NI-DAQmx and NI-VISA versions | Same two places, entries "NI-DAQmx" and "NI-VISA" |
| Version the executable was built with | The build specification on the development machine, or the About box if the author added one |
| Build date | The executable's Properties, Details tab, plus the version information from the build specification if it was filled in |
Check the bitness twice. A 32-bit LabVIEW on a 64-bit Windows produces a 32-bit executable that needs the 32-bit RTE, and Programs and Features lists both variants with the same year.
Write down the development machine's bitness as well. A 32-bit and a 64-bit LabVIEW of the same year install side by side, the build specification decides which one builds, and after an upgrade it's easy to build with the one the stations don't have.
The Inventory Template
One row per station, one file for the plant, under Git next to the hand-over documents.
station,product,executable_build_date,labview_version,bitness,rte_installed,daqmx,visa,last_verifiedFCT-01,controller-pcba,2024-11-03,2019,32-bit,2019 32-bit,19.6,19.5,2026-09-01FCT-02,controller-pcba,2026-08-14,2024,64-bit,2019 32-bit,19.6,19.5,2026-09-01EOL-01,drone-assembly,2023-06-18,2020,32-bit,2020 32-bit,20.1,20.0,2026-03-12CAL-01,imu-module,2021-02-09,2018,32-bit,2018 32-bit,18.6,18.0,labview_version and bitness describe the build. rte_installed describes the station, in the same "year bitness" format so the two can be compared by a script. last_verified is the date someone stood at the station and checked, not the date the row was typed.
Leave last_verified empty when nobody has checked. An empty cell is more useful than a guess, because the script below treats it as a problem.
A Script That Prints the Mismatches
This reads the file and prints every station where the build and the installed RTE disagree, or where the row is stale.
rte_check.py23 lines
# Prints stations whose installed Run-Time Engine doesn't match their build, or whose row is stale.import csvfrom datetime import dateMAX_AGE_DAYS = 90with open("stations.csv", newline="") as f: rows = list(csv.DictReader(f))for row in rows: needed = f"{row['labview_version']} {row['bitness']}" installed = row["rte_installed"].strip() problems = [] if installed != needed: problems.append(f"needs RTE {needed}, has {installed or 'nothing recorded'}") if not row["last_verified"]: problems.append("never verified") else: age = (date.today() - date.fromisoformat(row["last_verified"])).days if age > MAX_AGE_DAYS: problems.append(f"last verified {age} days ago") if problems: print(f"{row['station']:8} {'; '.join(problems)}")For the sample file it prints three lines. FCT-02 needs RTE 2024 64-bit and has 2019 32-bit, which is the stranded build from the first section. EOL-01 was last verified more than 90 days ago, and CAL-01 has never been verified at all.
Run it before every release. If it prints the station you're about to copy a build to, install the RTE first, or build with the version the station already has. The upgrade itself is covered in upgrade a station from LabVIEW 2019 to 2024.
Keeping It True
The list decays the day after you write it, unless updating it is part of releasing a build. Three habits keep it accurate.
Verify at every release. Whoever copies an executable to a station updates executable_build_date, labview_version, bitness and last_verified on the same day. No build leaves the development machine without its row changing.
Put the version in the executable. Fill the version information in the build specification, show it in an About box with the LabVIEW version and bitness, and have the build write a version.txt next to the executable. Then anyone at the station can read the build without a LabVIEW licence.
Add a row for the development machine. It's the one whose upgrade strands everything else, and the day it moves to a new version the script flags every station it builds for.
Give the file one owner and a home. It belongs in the same repository as the station hand-over documents, which document a test station for hand-over describes, so the person who inherits the station inherits the list. The reason the list is needed at all, binary VIs and per-version toolchains, is covered in why LabVIEW version control is so painful.
The dry part of this exercise is discovering that two stations with the same label have run different builds for a year.
The Contrast: When the Station Is Text
A Python station under the TofuPilot Framework has no Run-Time Engine to match. The station is a folder of procedure.yaml, phases/*.py and plugs/*.py, and a Git push builds a deployment with an id like dep_abc123, immutable and tied to one commit.
The CSV becomes a query. tofupilot deployments ls --procedure-ids <id> --environments production lists what's built, the station page in TofuPilot shows which deployment each station runs, and every uploaded run carries the deployment_id that produced it. "Which version runs on FCT-02" is a lookup, and "which units ran the old version" is a filter on the run list, which trace a test change to the units it shipped walks through.
Start With One Station
Take the station the script flagged with the most runs per week, 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 Python side needs the CLI and nothing else, on any version of Windows the station already has.
# 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.
