Le contrôle de version sous LabVIEW est pénible parce qu'un VI est un fichier binaire. Git le stocke, le versionne et le restaure, mais il ne peut pas afficher un diff ligne par ligne, ne peut pas fusionner les modifications de deux personnes sur le même VI, et ne peut pas vous dire qui a changé une limite. L'outillage de NI réduit cet écart, une licence Professional à la fois.
Ce que Git offre à un fichier texte et pas à un VI
Git a été conçu pour le texte. Chaque fonctionnalité que vous attendez d'un gestionnaire de sources sur un fichier Python découle du fait que Git sait lire des lignes, et un .vi ne lui en donne aucune à lire.
| Capacité | phases/power_rails.py | Power Rails.vi |
|---|---|---|
| Stocker et restaurer une version | Oui | Oui |
Diff ligne par ligne (git diff) | Oui | Non, Git affiche « Binary files differ » |
Blame (git blame) sur une limite | Oui | Non |
| Fusion à trois voies de deux modifications | Oui, automatique quand les modifications ne se chevauchent pas | Non, Git s'arrête sur un conflit |
| Revue dans une pull request sur le web | Oui | Non, le relecteur télécharge les deux versions et les ouvre |
| Fonctionne sur n'importe quelle machine | Oui | Seulement avec la même version de LabVIEW installée |
| Licence nécessaire pour relire | Aucune | Une licence LabVIEW, Professional pour LVCompare |
La colonne de droite n'est pas un réglage de Git que vous pourriez changer. Git ne peut pas fusionner ce qu'il ne sait pas analyser, et un diagramme est un graphe sérialisé dans un format que seul LabVIEW lit. Il en va de même pour le contenu des .ctl, .lvclass et .lvlib, et pour un .seq TestStand (binaire par défaut, et l'option d'enregistrement en XML se compare un peu mieux mais ne reste pas quelque chose que vous fusionneriez à la main).
Les quatre sources de douleur
La plupart des problèmes « LabVIEW et Git » se ramènent à quatre mécanismes. Chacun a son propre guide dans cette série. Cette section en est la carte.
Des VI binaires
Le message de commit est le seul enregistrement lisible de ce qui a changé dans un VI. Si le message dit « limites corrigées », c'est tout ce que quiconque saura jamais de ce commit, vous compris dans six mois. LVCompare et LVMerge montrent le diff du diagramme, sur une machine où ils sont installés et sous licence.
Une seule personne par VI à la fois
Parce que Git ne peut pas fusionner deux modifications du même VI, deux ingénieurs qui touchent au même fichier sur deux branches produisent un conflit que Git ne peut pas résoudre seul. La réponse habituelle est une convention : vous annoncez dans quel VI vous êtes, et personne d'autre ne l'ouvre avant que vous ayez poussé. Cela tient dans une équipe de deux. Résoudre les conflits de fusion LabVIEW sur des VI binaires explique quoi faire quand cela dérape.
Code compilé et compilation de masse
Par défaut, un fichier VI contient à la fois sa source et son code compilé. Recompilez un appelant parce que le connecteur d'un appelé a changé, et le fichier de l'appelant change sur le disque alors que vous n'y avez rien modifié. Séparer le code compilé du fichier source (le réglage « Separate compiled code from source file », disponible depuis LabVIEW 2010) déplace la partie compilée vers un cache d'objets local et supprime l'essentiel de ce bruit.
Il ne le supprime pas entièrement. Une compilation de masse, que vous lancez après tout changement de version ou d'architecture (32 ou 64 bits) de LabVIEW, réécrit chaque VI qu'elle touche, si bien que tout le dépôt apparaît modifié dans un seul commit et que l'historique de part et d'autre ne se compare plus proprement. Le code compilé séparé dans LabVIEW, expliqué couvre le réglage et ses limites.
Un moteur d'exécution par poste
Un exécutable compilé ne tourne que sur le moteur d'exécution (RTE) LabVIEW de la même version et de la même architecture. Un poste sous RTE 2019 32 bits ne démarrera pas un build issu de LabVIEW 2024 64 bits tant que quelqu'un n'aura pas installé ce RTE, et les pilotes DAQmx et VISA de ce poste ont leurs propres plages de versions prises en charge. « Quelle version du test tourne sur le poste 3 » a donc deux réponses : le commit d'où vient le build, et le RTE et les pilotes dont ce build a besoin. Quelle version de LabVIEW tourne sur chaque poste est l'inventaire.
Ce que NI vous donne
NI sait tout cela et a construit un vrai outillage autour. Cela mérite d'être dit honnêtement, conditions comprises.
| Outil | Ce qu'il fait | Condition |
|---|---|---|
| LVCompare | Diff graphique de deux VI, face-avant et diagramme, nœud par nœud | Professional Development System, chaque dépendance résoluble sur cette machine |
| LVMerge | Fusion à trois voies (Base, Theirs, Yours) vers un VI fusionné | Comme LVCompare, plus les deux branches doivent se charger |
| Code compilé séparé | Garde le code compilé hors du fichier source, pour que les appelants n'apparaissent pas modifiés quand un appelé change | Réglage par VI ou par projet, toujours pas un diff, et une compilation de masse touche encore les fichiers |
| Gestion de sources du Project Explorer | Extraire et valider depuis LabVIEW via un fournisseur configuré | Dépend du fournisseur, et le diff a toujours besoin de LVCompare |
Le schéma est le même à chaque fois : l'outil fonctionne, et il a besoin du même LabVIEW sous licence installé sur la machine où il tourne. Les revues ont lieu sur une page web, et aucun outil NI n'y tourne. La page de NI sur la gestion de configuration logicielle et LabVIEW est le résumé honnête de ce qu'ils recommandent, et la documentation sur la séparation du code compilé des VI couvre le réglage.
LabVIEW est un outil capable avec un vivier de lecteurs qui rétrécit. La douleur du versionnement est propre aux fichiers binaires, et elle ne disparaît pas avec une meilleure convention. Elle disparaît avec du texte.
À quoi ressemble un poste en texte
Un poste TofuPilot Framework est un dossier : procedure.yaml, phases/*.py, plugs/*.py. Tout est du texte. Voici un changement de limite sur un rail 3,3 V, exactement tel que Git l'affiche dans une pull request, sans plugin ni licence, sur n'importe quelle machine.
git-diff.txt21 lines
# git diff d'un changement de limite, tel que n'importe quel relecteur le voitdiff --git a/procedure.yaml b/procedure.yamlindex 3f2a1c7..8b9e0d4 100644--- a/procedure.yaml+++ b/procedure.yaml@@ -2,7 +2,7 @@ name: Controller PCBA FCT-version: 2.4.0+version: 2.4.1 unit: serial_number: default_value: SN-000000@@ -24,7 +24,7 @@ main: unit: V validators: - operator: ">="- expected_value: 3.2+ expected_value: 3.15 - operator: "<=" expected_value: 3.4Deux lignes changées, et le relecteur voit l'ancienne valeur, la nouvelle et l'auteur sans rien ouvrir. git blame procedure.yaml nomme qui a fixé 3,15 et quand. Deux ingénieurs qui modifient des phases différentes sur deux branches fusionnent automatiquement.
La phase derrière cette limite est une fonction ordinaire. La limite n'y figure pas, et c'est justement le point : le code lit l'instrument, et la procedure porte le nombre.
# La phase du rail 3.3 V. La limite vit dans procedure.yaml, pas ici.def power_rails(measurements, dmm): measurements.rail_3v3 = dmm.read_voltage()La même propriété se prolonge jusqu'à l'atelier. Un push Git construit un déploiement immuable avec un identifiant comme dep_abc123, les postes le récupèrent avec tofupilot pull, et chaque run envoyé depuis ce poste porte le deployment_id. Dans TofuPilot, « quelles unités ont tourné en 2.4.0 et lesquelles en 2.4.1 » est un filtre sur la liste des runs, et ramener chaque poste au déploiement précédent est une seule action sans reconstruction. Tracer un changement de test jusqu'aux unités livrées le détaille, et comment versionner des tests matériels avec Git et TofuPilot couvre l'organisation du dépôt.
Commencez par un poste
Prenez le poste qu'une seule personne peut ouvrir, ou celui avec le plus gros volume. 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 de la version LabVIEW sur les mêmes unités pendant deux semaines. La première pull request sur ce poste est le premier changement de limite relisible que votre usine ait jamais eu.
# 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.
