LVCompare et LVMerge fonctionnent tous les deux. LVCompare affiche un diff nœud par nœud de deux VI, et LVMerge réalise une vraie fusion à trois voies vers un nouveau VI. Les deux exigent une licence LabVIEW Professional avec chaque dépendance résoluble sur la machine qui les exécute, et aucun ne tourne là où les revues ont lieu : dans une pull request sur le web, ou sur le portable d'un collègue sans Professional.
Ce que fait chaque outil
| Outil | Entrée | Sortie | Nécessite |
|---|---|---|---|
| LVCompare | Deux VI (deux fichiers, ou deux révisions d'un même VI) | Une fenêtre listant chaque différence de face-avant, de diagramme, d'attributs et de connecteur, avec les deux VI ouverts côte à côte | LabVIEW Professional, même version que les VI, tous les SubVI et classes résolubles |
| LVMerge | VI Base, VI Theirs, VI Yours | Un VI fusionné que vous acceptez ou rejetez différence par différence, puis enregistrez | Comme LVCompare, et les deux branches doivent se charger sans boîte de dialogue de dépendance manquante |
Les deux outils ouvrent les VI dans une vraie instance de LabVIEW. C'est pour cela que la règle des dépendances existe : si Power Rails.vi appelle DMM Read.vi depuis une bibliothèque que la machine de diff n'a pas, LabVIEW cherche, et la comparaison soit se bloque sur une boîte de dialogue, soit s'exécute sur un VI cassé.
Les configurer avec Git
Git exécute ce que vous déclarez comme difftool ou mergetool, donc les brancher tient en quelques lignes de configuration. Les lignes ci-dessous valent pour un LabVIEW 64 bits sous Windows, lancées depuis Git Bash. Adaptez le chemin d'installation à votre version de LabVIEW ; le chemin, la version de l'outil et les VI doivent tous correspondre.
# difftool et mergetool LabVIEW. Les chemins dépendent de la version et de l'architecture de LabVIEW.# L'ordre des arguments de LVMerge est Base, Theirs, Yours, Merged, et les quatre doivent être absolus.[difftool "lvcompare"] cmd = \"C:/Program Files/National Instruments/Shared/LabVIEW Compare/LVCompare.exe\" \"$(cygpath -aw \"$LOCAL\")\" \"$(cygpath -aw \"$REMOTE\")\" -nobdcosm -nofppos[mergetool "lvmerge"] cmd = \"C:/Program Files/National Instruments/Shared/LabVIEW Merge/LVMerge.exe\" \"$(cygpath -aw \"$BASE\")\" \"$(cygpath -aw \"$REMOTE\")\" \"$(cygpath -aw \"$LOCAL\")\" \"$(cygpath -aw \"$MERGED\")\" trustExitCode = false[diff] tool = lvcompare[merge] tool = lvmergeTrois détails portent toute la configuration.
L'ordre des arguments. Git expose les trois entrées de fusion comme $BASE, $LOCAL (la vôtre) et $REMOTE (la leur), et la sortie comme $MERGED. LVMerge attend Base, Theirs, Yours, Merged, donc $REMOTE passe avant $LOCAL. Inversez-les et l'outil se lance, s'ouvre, et fusionne à l'envers.
Les chemins absolus. Git passe aux outils des chemins relatifs vers un répertoire temporaire. LVCompare et LVMerge veulent des chemins Windows absolus, ce que produit cygpath -aw. Sans cela, l'outil signale un fichier manquant ou n'ouvre rien.
La version. Le chemin de l'exécutable contient l'installation de LabVIEW, et l'outil qu'elle contient n'ouvre que les VI d'une version compatible. Une équipe sur LabVIEW 2019 et 2024 garde deux jeux de lignes et bascule selon la machine.
Indiquez aussi à Git que les fichiers sont binaires, pour qu'il ne tente jamais de fusion texte ni de conversion de fins de ligne dessus.
# Ne jamais traiter ces fichiers comme du texte. Git les stocke et les restaure ; les outils ci-dessus les comparent.*.vi binary*.ctl binary*.seq binaryEnsuite git difftool -- "FCT/Power Rails.vi" ouvre LVCompare sur la copie de travail contre HEAD, et git mergetool -- "FCT/Power Rails.vi" ouvre LVMerge pendant une fusion en conflit.
Les modes de défaillance
Ce sont ceux qui apparaissent en pratique et dont la cause est connue.
| Symptôme | Cause | Contournement |
|---|---|---|
| LVCompare refuse d'ouvrir le second fichier, ou l'ouvre comme une copie | LabVIEW ne peut pas garder deux VI du même nom en mémoire, donc une copie doit être renommée, et un membre de classe renommé n'appartient plus à sa classe | Comparez un VI ordinaire, ou extrayez l'autre révision dans un second dossier et comparez depuis là ; pour les membres de classe, acceptez que le contexte de classe soit perdu |
| Une boîte de dialogue de recherche apparaît et la comparaison se bloque | Un SubVI, un typedef ou une classe dont dépend le VI n'est pas sur la machine de diff, ou pas au chemin attendu par le VI | Lancez la comparaison depuis la machine de développement du projet avec le .lvproj ouvert, jamais depuis un checkout nu |
| Le VI fusionné contient un nœud en double | LVMerge duplique un nœud supprimé puis rajouté dans une branche | Inspectez le diagramme fusionné avant d'enregistrer, retirez le doublon, exécutez le VI une fois |
| L'outil ouvre les mauvaises révisions, ou rien ne se passe | L'ordre des arguments est faux (LVMerge attend Base, Theirs, Yours, Merged), ou un chemin est relatif | Vérifiez l'ordre dans .gitconfig, enveloppez chaque chemin dans cygpath -aw |
| La configuration marche sur un PC et échoue sur un autre | Le chemin d'installation et la version de l'outil dépendent de la version et de l'architecture de LabVIEW | Gardez un bloc de configuration par version de LabVIEW dans le README du dépôt et copiez celui qui correspond |
LVCompare.exe n'existe tout simplement pas | La licence est Base ou Full, pas Professional | Aucun dans LabVIEW ; la revue passe sur une machine avec Professional |
Ce qu'ils ne peuvent pas faire
Quatre manques, et aucun n'est un bug. Ils découlent du fait que les outils sont des instances de LabVIEW.
Relire dans une pull request sur le web. GitHub, GitLab et Bitbucket affichent un diff de texte. Pour un .vi, ils affichent « Binary file changed ». Le relecteur télécharge les deux révisions, ouvre LVCompare en local, et rédige la revue de mémoire. Personne ne commente la ligne 27 d'un diagramme.
Tourner sur une machine sans Professional. Les licences Base et Full ne livrent pas les outils. Dans une équipe où une seule personne a Professional, cette personne est le seul relecteur, quel que soit l'organigramme.
Fusionner une classe ou un typedef de façon fiable. Le problème de renommage ci-dessus casse l'appartenance à la classe pendant une comparaison, et un changement de typedef se propage dans chaque VI qui l'utilise, ce que LVMerge traite un VI à la fois. La plupart des équipes fusionnent les classes en choisissant un côté et en refaisant l'autre à la main, ce que résoudre les conflits de fusion LabVIEW sur des VI binaires détaille.
Comparer un .seq. Les séquences TestStand ne sont pas des VI. Enregistrées en XML, elles se comparent un peu mieux dans Git seul, mais elles ne restent pas quelque chose que vous fusionneriez à la main, et LVCompare et LVMerge ne les ouvrent pas.
Quand ils restent le bon outil
Si vous restez sur LabVIEW, utilisez-les. LVCompare sur la machine de développement avant chaque commit est ce qui se rapproche le plus de relire son propre diff, et il attrape le fil accidentel et la constante que vous ne vouliez pas changer. LVMerge vaut le bricolage sur l'ordre des arguments quand deux ingénieurs ont tous deux fait de vrais changements de diagramme dans le même VI et qu'aucun ne veut refaire une journée de travail.
Ce sont les bons outils pour la machine qui les possède. Ils n'ont jamais été conçus comme le processus de revue d'une équipe, et les traiter comme tel est l'origine de la douleur décrite dans pourquoi le contrôle de version LabVIEW est si pénible. Là où ils s'arrêtent, les options honnêtes sont une convention (une seule personne par VI à la fois), une seconde licence Professional, ou sortir les limites du diagramme vers un fichier que Git sait lire. Revue de code pour les tests LabVIEW : pourquoi elle échoue couvre le côté équipe.
Le contraste
Un poste TofuPilot Framework est du texte : procedure.yaml, phases/*.py, plugs/*.py. Le même conflit sur la même limite, quand deux branches ont toutes deux changé le plancher du 3,3 V, ressemble à ceci dans le fichier.
- name: rail_3v3 unit: V validators: - operator: ">="<<<<<<< HEAD expected_value: 3.15======= expected_value: 3.1>>>>>>> widen-3v3-limit - operator: "<=" expected_value: 3.4Vous lisez les deux valeurs, en choisissez une ou demandez aux deux auteurs, supprimez les marqueurs, git add, commit. Une minute, sur n'importe quelle machine, sans licence. Tout le reste des deux branches a fusionné tout seul, parce que Git pouvait le lire. Le relecteur de la pull request a vu les deux valeurs candidates avant la fusion, et après le push un poste récupère le déploiement et chaque run qu'il envoie à TofuPilot porte l'identifiant de ce déploiement.
Commencez par un poste
Quand vous déplacez un poste, prenez celui dont les VI entrent le plus souvent en conflit. Reconstruisez-le sous forme de procedure.yaml avec ses phases et ses plugs en Python avec le TofuPilot Framework, gardez des limites identiques, et faites-le tourner en parallèle de la version LabVIEW sur les mêmes unités pendant deux semaines.
# 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 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.
