Un exécutable LabVIEW compilé ne tourne que sur le moteur d'exécution (RTE) de la même version et du même nombre de bits, donc la réponse à « quelle version de LabVIEW tourne sur chaque poste » doit être écrite quelque part, une ligne par poste. La plupart des usines ne peuvent pas produire cette liste en moins d'une journée, parce que la version vit dans un installeur que quelqu'un a lancé il y a trois ans et nulle part ailleurs. Ce guide vous donne l'inventaire, un script qui signale les incohérences, et une façon de garder la liste à jour.
Le mode de défaillance : un build qui ne démarre pas
La machine de développement passe à LabVIEW 2024 64 bits. Un changement de limite y est compilé, copié sur un poste qui fait tourner le même exécutable depuis 2019, et l'opérateur double-clique dessus. Une boîte de dialogue indique que le moteur d'exécution LabVIEW requis est introuvable, nomme la version et renvoie vers ni.com.
Le build n'a rien d'anormal. Le code compilé à l'intérieur d'un exécutable LabVIEW vise une version de RTE et un nombre de bits, et le poste a le RTE 2019 32 bits installé. Le RTE 2024 64 bits est une installation distincte, et le RTE 2024 32 bits aussi.
Parfois l'exécutable démarre et échoue plus tard. NI-DAQmx et NI-VISA supportent chacun une plage de versions de LabVIEW, donc un poste avec un vieux pilote peut charger le nouvel exécutable puis tomber en erreur au premier appel DAQ. Dans les deux cas, le poste est à l'arrêt jusqu'à ce qu'une personne avec les droits administrateur installe le bon RTE et les bons pilotes, sur un PC d'atelier qui n'a souvent pas de connexion internet.
Comment trouver le RTE d'un poste
Il vous faut quatre informations par poste : la version du RTE, son nombre de bits, la version de NI-DAQmx et la version de NI-VISA. Il vous faut ensuite la version et le nombre de bits de LabVIEW avec lesquels l'exécutable a été compilé, qui viennent de la machine de développement, pas du poste.
| Ce qu'il vous faut | Où le trouver |
|---|---|
| Version et nombre de bits du RTE | Programmes et fonctionnalités de Windows, entrées nommées comme « NI LabVIEW Runtime 2019 (32-bit) » |
| RTE sur les postes récents | NI Package Manager, onglet Installed, filtre sur « Runtime » |
| Versions de NI-DAQmx et NI-VISA | Aux deux mêmes endroits, entrées « NI-DAQmx » et « NI-VISA » |
| Version avec laquelle l'exécutable a été compilé | La spécification de build sur la machine de développement, ou la boîte À propos si l'auteur en a ajouté une |
| Date du build | Les propriétés de l'exécutable, onglet Détails, plus les informations de version de la spécification de build si elles ont été remplies |
Vérifiez le nombre de bits deux fois. Un LabVIEW 32 bits sur un Windows 64 bits produit un exécutable 32 bits qui a besoin du RTE 32 bits, et Programmes et fonctionnalités liste les deux variantes avec la même année.
Notez aussi le nombre de bits de la machine de développement. Un LabVIEW 32 bits et un 64 bits de la même année s'installent côte à côte, la spécification de build décide lequel compile, et après une mise à niveau il est facile de compiler avec celui que les postes n'ont pas.
Le modèle d'inventaire
Une ligne par poste, un fichier pour l'usine, sous Git à côté des documents de passation.
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 et bitness décrivent le build. rte_installed décrit le poste, dans le même format « année bits » pour qu'un script puisse comparer les deux. last_verified est la date à laquelle quelqu'un s'est tenu devant le poste et a vérifié, pas la date à laquelle la ligne a été saisie.
Laissez last_verified vide quand personne n'a vérifié. Une cellule vide est plus utile qu'une supposition, parce que le script ci-dessous la traite comme un problème.
Un script qui affiche les incohérences
Il lit le fichier et affiche chaque poste où le build et le RTE installé ne concordent pas, ou dont la ligne est périmée.
rte_check.py23 lines
# Affiche les postes dont le moteur d'exécution installé ne correspond pas au build, ou dont la ligne est périmée.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)}")Pour le fichier d'exemple, il affiche trois lignes. FCT-02 a besoin du RTE 2024 64 bits et a le 2019 32 bits, c'est le build bloqué de la première section. EOL-01 a été vérifié il y a plus de 90 jours, et CAL-01 ne l'a jamais été.
Lancez-le avant chaque mise en production. S'il affiche le poste sur lequel vous êtes sur le point de copier un build, installez d'abord le RTE, ou compilez avec la version que le poste a déjà. La mise à niveau elle-même est traitée dans mettre à niveau un poste de LabVIEW 2019 vers 2024.
La garder à jour
La liste se périme dès le lendemain de sa rédaction, sauf si sa mise à jour fait partie de la mise en production d'un build. Trois habitudes la gardent exacte.
Vérifiez à chaque mise en production. La personne qui copie un exécutable sur un poste met à jour executable_build_date, labview_version, bitness et last_verified le jour même. Aucun build ne quitte la machine de développement sans que sa ligne change.
Mettez la version dans l'exécutable. Remplissez les informations de version dans la spécification de build, affichez-les dans une boîte À propos avec la version et le nombre de bits de LabVIEW, et faites écrire par le build un version.txt à côté de l'exécutable. N'importe qui devant le poste peut alors lire le build sans licence LabVIEW.
Ajoutez une ligne pour la machine de développement. C'est celle dont la mise à niveau bloque tout le reste, et le jour où elle passe à une nouvelle version, le script signale chaque poste pour lequel elle compile.
Donnez au fichier un propriétaire et un emplacement. Sa place est dans le même dépôt que les documents de passation des postes, que documenter un poste de test pour la passation décrit, pour que la personne qui hérite du poste hérite de la liste. La raison pour laquelle cette liste est nécessaire, les VI binaires et les chaînes d'outils par version, est traitée dans pourquoi le contrôle de version LabVIEW est si pénible.
La partie ingrate de l'exercice est de découvrir que deux postes portant la même étiquette font tourner des builds différents depuis un an.
Le contraste : quand le poste est du texte
Un poste Python sous le TofuPilot Framework n'a pas de moteur d'exécution à faire correspondre. Le poste est un dossier de procedure.yaml, phases/*.py et plugs/*.py, et un push Git construit un déploiement avec un identifiant comme dep_abc123, immuable et lié à un commit.
Le CSV devient une requête. tofupilot deployments ls --procedure-ids <id> --environments production liste ce qui est construit, la page du poste dans TofuPilot montre quel déploiement chaque poste fait tourner, et chaque run uploadé porte le deployment_id qui l'a produit. « Quelle version tourne sur FCT-02 » est une consultation, et « quelles unités ont tourné sur l'ancienne version » est un filtre sur la liste des runs, que tracer un changement de test jusqu'aux unités expédiées parcourt.
Commencez par un poste
Prenez le poste signalé par le script qui a le plus de runs par semaine, reconstruisez-le en Python avec le TofuPilot Framework avec les mêmes limites, et faites-le tourner à côté de la version LabVIEW sur les mêmes unités pendant deux semaines. Le côté Python n'a besoin que du CLI et de rien d'autre, sur n'importe quelle version de Windows déjà présente sur le poste.
# Installe le CLI, puis lance le poste en local (sans compte) ou avec upload.curl -fsSL https://www.tofupilot.app/install | shtofupilot run ./procedure.yamltofupilot run ./procedure.yaml --uploadLa reconstruction pas à pas est dans comment migrer de LabVIEW vers Python pour les tests de fabrication avec TofuPilot, et le framework lui-même est sur tofupilot.com/products/framework. L'offre Lab est gratuite, et tofupilot run fonctionne sans compte.
