La revue de code a besoin d'un diff, et un .vi n'en a pas en dehors de LVCompare sur une machine sous licence avec la même version de LabVIEW installée. Donc sur la plupart des lignes de production, la revue d'un changement de test se résume à « l'intégrateur a envoyé le nouveau build », et la première personne qui voit le changement est l'opérateur. Ce guide explique à quoi sert une revue sur un poste de test, pourquoi elle n'a pas lieu avec des VI, et donne une liste de contrôle qui vous en apporte l'essentiel malgré tout.
À quoi sert une revue sur un poste de test
Trois types de changement atteignent un poste, et chacun mérite un second regard avant de tourner sur du produit.
Une limite a changé. La limite basse du rail 3,3 V passe de 3,2 V à 3,15 V. Le relecteur demande qui a décidé, s'il y a une dérogation ou un changement de conception derrière, et ce qu'il advient des unités qui ont mesuré 3,17 V le mois dernier.
Une phase a été ajoutée. Une nouvelle mesure de fuite arrive après Power Rails. Le relecteur vérifie qu'elle a des limites, qu'elle n'ajoute pas vingt secondes à un cycle qui était déjà le goulot d'étranglement, et qu'elle ne demande pas un changement de montage que personne n'a prévu.
Un contournement de montage est entré. Une boucle de réessai autour d'un relais capricieux, un délai de 500 ms avant une requête SCPI, une broche sautée parce que le pogo 14 est usé. Ce sont ces changements qui deviennent permanents, et la revue est le seul moment où quelqu'un demande s'ils devraient l'être.
Rien de tout cela ne concerne le style. Sur un poste, la revue porte sur les limites et les résultats, parce que ce sont eux qui décident de ce qui est expédié.
Pourquoi elle n'a pas lieu avec des VI
Une revue est une suite de petites étapes, et chacune d'elles suppose du texte.
| Étape de la revue | Ce qu'il lui faut | Ce qu'un .vi vous donne |
|---|---|---|
| Voir ce qui a changé | Un diff ligne par ligne | « Binary files differ » |
| Voir qui a changé quelle partie | Un blame par ligne | Un auteur pour tout le fichier |
| Le lire sans outillage | Un navigateur et une page de pull request | LabVIEW Professional avec LVCompare, la même version, toutes les dépendances résolues |
| Commenter un changement précis | Une ancre de ligne | Une capture d'écran avec une flèche dessinée dessus |
| Fusionner deux changements relus | Une fusion textuelle à trois voies | LVMerge, Professional uniquement, avec des cas connus de nœuds dupliqués |
| Relier le changement aux résultats | Une version estampillée sur chaque run | Rien, sauf si le build en écrit une |
LVCompare est un vrai outil et il fait bien son travail. Il charge deux VI et surligne les nœuds ajoutés, supprimés, déplacés ou recâblés.
Mais il n'est livré qu'avec le Professional Development System, à environ 5 500 $ par licence et par an depuis le passage à l'abonnement, et il a besoin des deux VI chargés, donc chaque SubVI, classe et bibliothèque doit se résoudre sur la machine du relecteur. Ce qu'il peut et ne peut pas faire est dans LVCompare et LVMerge : ce qu'ils ne peuvent pas faire.
Le résultat pratique est que la revue se déplace vers la personne qui a cette machine. Sur la plupart des lignes, c'est la personne qui a fait le changement, ce qui n'est pas une revue.
Ce que les équipes font à la place
Trois contournements sont courants. Chacun fait une partie du travail et rate une chose précise.
Des captures d'écran dans un ticket. L'auteur colle le nouveau diagramme, parfois avec l'ancien à côté. Le relecteur voit ce que l'auteur a choisi de montrer, et rate une constante modifiée dans un SubVI, une structure de cas recâblée deux cadres plus loin, ou un typedef qui a décalé tous ses appelants.
Un deuxième ingénieur ouvre le VI. Il faut une licence, la même version et quelqu'un qui lit LabVIEW, ce qui dans beaucoup d'équipes est un ensemble d'une seule personne.
Le deuxième ingénieur voit le nouvel état sans l'ancien et relit de mémoire. Quand l'équipe a un seul ingénieur LabVIEW, le facteur bus en ingénierie de test explique pourquoi ce relecteur n'existe généralement pas.
LVCompare sur le PC du relecteur. C'est ce qui se rapproche le plus d'une vraie revue. Il faut la licence Professional et la même version, et les fichiers doivent parfois être renommés pour ouvrir deux copies, ce qui casse les classes et leurs membres.
Rien n'est enregistré : pas de fil de commentaires, pas d'approbation, pas de lien entre le changement et le build qui l'a porté. Et quand deux personnes ont modifié le même VI, la fusion est un problème à part, que corriger les conflits de fusion LabVIEW sur des VI binaires traite.
Une liste de contrôle qui fonctionne quand même sur un poste LabVIEW
Vous ne pouvez pas differ le VI, alors sortez-en ce qui a besoin d'être relu.
- Mettez les limites dans un fichier de configuration que le VI lit au démarrage. Un CSV ou un INI à côté de l'exécutable transforme un changement de limite en un diff texte d'une ligne, relisible sur n'importe quel hébergeur Git, même si le VI qui le lit reste binaire.
- Écrivez une ligne de CHANGELOG par build : numéro de build, date, auteur, ce qui a changé, pourquoi, et le ticket. Le relecteur lit la ligne avant que le build n'atteigne l'atelier.
- Affichez le numéro de build et la version de LabVIEW dans la boîte À propos, et faites écrire le même numéro par le build dans un
version.txtà côté de l'exécutable. - Activez le code compilé séparé pour le projet, pour qu'un VI « modifié » dans Git signifie que sa source a changé et non qu'un VI appelé l'a fait recompiler.
- Faites tourner le nouveau build sur une unité de référence avant qu'il n'aille en atelier, et joignez ce run à la ligne du CHANGELOG.
Le fichier de limites est la pièce qui rapporte en premier.
measurement,unit,min,maxrail_3v3,V,3.15,3.4rail_5v,V,4.85,5.15leakage_ua,uA,,50Quand la limite basse du 3V3 bouge, la pull request sur ce fichier montre 3.2 devenir 3.15, l'auteur, la date et un endroit pour demander pourquoi. C'est l'essentiel d'une revue, et il n'a fallu aucune licence LabVIEW. Les points 3 et 5 ensemble sont ce qui vous permet de répondre plus tard quelles unités ont tourné avec quelle limite, ce que tracer un changement de test jusqu'aux unités expédiées détaille.
La plupart des lignes ont déjà un processus de revue. C'est l'opérateur, et le verdict est de savoir si la ligne s'arrête.
Le contraste : une pull request sur un changement de limite
Sur un poste Python sous le TofuPilot Framework, la limite vit dans procedure.yaml, et le même changement est une pull request que n'importe quel hébergeur Git affiche.
main: - name: Power Rails python: phases.power_rails measurements: - name: rail_3v3 unit: V validators: - operator: ">="- expected_value: 3.2+ expected_value: 3.15 - operator: "<=" expected_value: 3.4Un relecteur répond à trois questions à partir du seul diff, sans rien ouvrir d'autre. Ce qui a changé : la limite basse de rail_3v3, de 3,2 V à 3,15 V, et rien d'autre dans le fichier.
Pourquoi : la description de la pull request, qui renvoie à la dérogation ou à la note de conception. Ce que cela fait aux unités déjà testées : toute unité qui a mesuré entre 3,15 V et 3,2 V échouait avant et passe maintenant, et le relecteur demande ce décompte à l'historique des runs dans TofuPilot avant d'approuver.
Six mois plus tard, quand quelqu'un demande qui a abaissé cette limite, la réponse tient en une commande.
# Qui a changé la limite basse de rail_3v3, et dans quel commit.git blame -L '/rail_3v3/,+6' procedure.yaml# 7c2e91a4 (Priya Nair 2026-03-11 14:02:33 +0100 24) expected_value: 3.15La fusion crée un déploiement, le poste le récupère, et chaque run uploadé ensuite porte l'identifiant du déploiement. Le relecteur qui a approuvé le changement ouvre la procedure dans TofuPilot une semaine plus tard et compare le FPY avant et après ce déploiement, ce qui boucle la boucle que la capture d'écran dans le ticket ne pouvait pas boucler.
Commencez par un poste
Choisissez le poste dont les limites changent le plus souvent, 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 premier changement de limite qui suit est votre première vraie revue.
# 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.
