Mettre à niveau un poste LabVIEW 2019 vers 2024

Mettre à niveau un poste de LabVIEW 2019 vers 2024, c'est une compilation de masse sur la machine de développement plus une mise à niveau du moteur d'exécution (RTE) et des pilotes sur chaque poste qui fera tourner le nouveau build. La première moitié prend un après-midi. La seconde est là où les builds restent bloqués, parce qu'un exécutable 2024 ne démarre pas sur un RTE 2019, et que les pilotes d'un poste vieux de cinq ans ont leurs propres plages de versions prises en charge.

Avant de commencer

Notez ce qu'il y a dans l'atelier avant de toucher à la machine de développement. Une ligne par poste, remplie en allant le voir, pas de mémoire.

Trois choses ressortent du tableau. Le poste pilote est celui avec le plus gros volume et une ligne complète (FCT-01 ici) : il vous donne une comparaison en jours, pas en mois. Tout poste sur une architecture différente de votre cible (tous, si vous passez de 32 à 64 bits) a besoin du nouveau RTE et de nouveaux pilotes 64 bits, pas seulement du RTE. Et une ligne avec « personne » dans la colonne reconstruction est une décision, pas une mise à niveau : voir la section sur quand ne pas mettre à niveau.

La méthode d'inventaire complète, y compris comment lire la version du RTE sur un poste en marche, est dans quelle version de LabVIEW tourne sur chaque poste.

L'ordre de mise à niveau

L'ordre compte plus que n'importe quelle étape prise seule, parce que chacune n'est facile à annuler que jusqu'à la suivante.

1. La machine de développement d'abord. Installez LabVIEW 2024 à côté de 2019, pas à sa place. Vous aurez besoin de 2019 pour reconstruire l'ancien exécutable si le pilote échoue.
2. Taguez le dernier commit 2019, puis ouvrez le projet dans 2024 et lancez Tools, Advanced, Mass Compile sur le dossier du projet. Enregistrez tout.
3. Validez la compilation de masse comme un seul commit sans aucun changement fonctionnel, et dites-le dans le message. Taguez-le. La section suivante explique pourquoi.
4. Construisez l'exécutable sur 2024. Corrigez ce que le build signale (en général un VI déprécié ou une palette de pilote modifiée), chaque correction dans son propre commit après la compilation de masse, jamais mélangée dedans.
5. Un seul poste pilote. Installez le RTE 2024 et les DAQmx et VISA correspondants sur FCT-01 seulement. Laissez le RTE 2019 installé ; les RTE coexistent. Déployez le nouveau build à côté de l'ancien.
6. Côte à côte pendant deux semaines. Faites tourner le build 2024 et le build 2019 sur les mêmes unités, comparez les mesures et le pass/fail par phase. Pas seulement le FPY : une limite qui se comporte différemment sur un nouveau pilote se voit comme un décalage dans une distribution, pas toujours comme une défaillance.
7. Puis le reste, un poste à la fois, dans l'ordre de votre tableau.

Deux semaines est le plus petit intervalle où un décalage de mesure est visible par rapport à la variation normale sur un poste à 400 runs par semaine. Sur un poste à 60 runs par semaine, attendez plus longtemps.

Ce que la compilation de masse fait à votre historique Git

La compilation de masse réécrit chaque VI qu'elle recompile, et après un changement de version c'est chaque VI du projet. Le dépôt apparaît entièrement modifié dans un seul commit. C'est inévitable et ce n'est pas grave, tant que vous le rendez retrouvable.

# Encadre la compilation de masse de deux tags pour que l'historique de part et d'autre reste accessible.git tag -a lv2019-last -m "Last commit built with LabVIEW 2019 32-bit"# Ouvrez le projet dans LabVIEW 2024, lancez Tools > Advanced > Mass Compile, enregistrez tout.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 --tags

Les deux tags font deux choses. lv2019-last est l'endroit où vous vous placez pour reconstruire l'ancien exécutable si le pilote échoue. lv2024-first dit à quiconque lira git log plus tard que rien entre ces deux tags n'est un vrai changement, pour qu'il arrête d'y chercher le commit qui a déplacé une limite.

Gardez le commit de compilation de masse pur. Si vous y corrigez aussi un VI cassé, cette correction devient invisible, enterrée dans un diff de mille binaires réécrits. Corrigez-la dans le commit suivant. Le code compilé séparé dans LabVIEW, expliqué couvre le réglage qui réduit le bruit entre deux compilations de masse ; il ne réduit pas la compilation de masse elle-même, et les classes LabVIEW en particulier peuvent encore apparaître modifiées après.

La compilation de masse est aussi le moment où l'histoire LVCompare s'arrête pour l'ancien historique. Comparer un VI d'avant le tag avec un VI d'après montre chaque nœud comme modifié. C'est attendu, et c'est pourquoi pourquoi le contrôle de version LabVIEW est si pénible place la compilation de masse parmi les quatre sources de douleur.

Compatibilité des pilotes

Chaque pilote NI (DAQmx, VISA, et tout pilote propre à un instrument que vous utilisez) prend en charge une plage de versions de LabVIEW et une architecture. Un poste 2019 32 bits avec un DAQmx de cette époque ne servira pas forcément un build 2024 64 bits, et la version qui sert 2024 peut abandonner la prise en charge d'une carte plus ancienne dans le châssis.

Ne devinez pas d'après les numéros de version. Vérifiez les tableaux de compatibilité de NI pour DAQmx et VISA contre la version et l'architecture de LabVIEW que vous visez, et contre chaque carte et interface du poste, avant d'installer quoi que ce soit sur le pilote. Écrivez les versions choisies dans le tableau d'inventaire. Ce tableau est le seul document dont la prochaine personne aura besoin.

Deux cas méritent un examen à part. Un poste avec une carte ancienne que le nouveau DAQmx ne liste plus est un poste que vous ne pouvez pas mettre à niveau sans remplacer du matériel. Et un poste PXI avec du code FPGA compilé pour 2019 a besoin du module FPGA et d'une recompilation du bitfile, ce qui est un projet en soi.

Quand ne pas mettre à niveau

La mise à niveau vaut le coup pour un poste qui tournera des années et a besoin de nouveaux instruments ou de nouveau code. Elle ne vaut pas le coup dans trois cas.

Un poste qui sera remplacé. Si le montage doit être reconstruit l'an prochain, laissez-le sur 2019 et mettez l'effort dans le remplacement. Le RTE 2019 continue de tourner.

Un produit proche de la fin de vie. Les 5 000 dernières unités d'un produit ne justifient pas les deux semaines côte à côte et le risque sur les pilotes. Gelez le poste, documentez-le, et notez les versions du RTE et des pilotes dans l'inventaire pour qu'il puisse être reconstruit une fois s'il le faut.

Un poste PXI avec une synchronisation FPGA que vous ne pouvez pas retester. Si le test d'acceptation de la synchronisation demande un équipement ou des unités que vous n'avez plus, une mise à niveau qui touche au bitfile FPGA est un changement que vous ne pouvez pas valider. Ne le faites pas.

Dans les trois cas, la ligne honnête dans l'inventaire est « reste sur 2019, reconstruire depuis le tag lv2019-last sur la VM de développement 2019 ». Gardez cette VM.

Le contraste

Un poste TofuPilot Framework épingle son environnement d'exécution en texte. pyproject.toml nomme la version de Python et les paquets, et le déploiement construit depuis un commit emporte l'environnement résolu avec lui.

# L'environnement d'exécution est épinglé ici ; le déploiement construit depuis ce commit l'emporte avec lui.[project]name = "controller-pcba-fct"version = "2.4.1"requires-python = ">=3.12,<3.13"dependencies = ["tofupilot", "pyvisa", "pyvisa-py"]

Changer de version de Python est une modification d'une ligne dans une pull request, relue comme n'importe quelle autre. tofupilot deploy --prod construit un déploiement immuable avec un identifiant comme dep_abc123, et tofupilot pull met ce même build sur chaque poste, donc il n'y a pas de RTE à installer poste par poste et aucun poste sur une version que les autres n'ont pas. Chaque run envoyé depuis un déploiement récupéré porte le deployment_id, donc la comparaison côte à côte est un filtre dans TofuPilot plutôt qu'un tableur. Et si le pilote échoue, le retour arrière instantané ré-épingle chaque poste de production sur le déploiement précédent sans reconstruction, tandis que les runs déjà envoyés gardent l'identifiant du build qui les a produits.

Comment déployer des scripts de test Python sur les postes de production couvre le flux de déploiement, et gérer une équipe de test mixte LabVIEW et Python couvre la période où les deux types de poste rapportent à la même procedure.

Commencez par un poste

Quand vous déplacez effectivement un poste, le pilote de votre tableau d'inventaire est celui à déplacer. Reconstruisez-le sous forme de procedure.yaml avec ses phases et ses plugs en Python avec le TofuPilot Framework, gardez les mêmes limites, et faites-le tourner en parallèle du build LabVIEW sur les mêmes unités pendant deux semaines, le même protocole que la mise à niveau.

# 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 --upload

La reconstruction est dans comment migrer de LabVIEW vers Python pour les tests de fabrication avec TofuPilot, et le framework est sur tofupilot.com/products/framework. L'offre Lab est gratuite, et tofupilot run fonctionne sans compte.