Que faire quand votre ingénieur LabVIEW part

Quand votre ingénieur LabVIEW part, la première tâche est de figer ce qui tourne aujourd'hui, la deuxième est de découvrir ce que vous possédez vraiment, et la troisième est de garder les résultats qui remontent pendant que vous reconstruisez le poste le plus risqué en Python. La plupart des usines font la première et sautent les deux autres. L'ordre ci-dessous couvre les 48 premières heures, les deux premières semaines et les 30 premiers jours, dans cette séquence.

Les 48 premières heures

Faites ceci avant tout le reste. Chaque point prend une heure ou deux maintenant, et une semaine dans un mois.

1. Figez les builds déployés. Copiez sur un partage l'exécutable exact, l'installeur du moteur d'exécution et chaque fichier .ini ou de configuration de chaque PC de poste. Pas la source, la chose qui tourne. Si un PC de poste meurt la semaine prochaine, c'est ce que vous réinstallez.
2. Localisez les fichiers projet. Trouvez chaque .lvproj, .vi, .lvlib, .ctl, les fichiers .seq TestStand et la spécification de build qui a produit chaque exécutable déployé. Ils sont souvent sur le portable de l'ingénieur, un partage personnel ou une clé USB dans un tiroir.
3. Notez les versions exactes des runtimes. Version et bitness de LabVIEW, moteur d'exécution de chaque poste, version de TestStand, versions des drivers DAQmx et NI-VISA. Un VI de 2019 ne s'ouvre pas proprement en 2024 sans recompilation, et c'est à la recompilation que les choses cassent.
4. Exportez les informations de licence. Quelles licences sont en abonnement, quel compte NI les détient, quand ils se renouvellent. Les licences LabVIEW et les licences de déploiement TestStand ne sont plus qu'en abonnement. Un renouvellement manqué veut dire que vous ne pouvez pas ouvrir la source même après l'avoir retrouvée.
5. Copiez tout dans un dépôt. VI binaires compris. Git ne saura pas les comparer, mais il les horodate, et « la version qui était sur la ligne 3 le jour de son départ » devient un commit au lieu d'un souvenir. La documentation Git couvre les bases si l'usine ne l'a jamais utilisé.

Changez aussi les mots de passe des PC de poste et les identifiants du compte NI, et gardez un accès en lecture à la boîte mail de l'ingénieur pendant le préavis. La moitié des contournements d'instruments sont dans des fils d'e-mails.

Les deux premières semaines : l'inventaire

Vous ne pouvez pas prioriser ce que vous n'avez pas compté. Parcourez l'atelier avec un portable et remplissez une ligne par poste.

Le risque est fonction de trois choses : le volume, qui peut l'ouvrir et l'âge du runtime. Un poste à fort volume que personne ne peut ouvrir, sur un runtime que NI ne livre plus, est votre premier candidat à la reconstruction. Un poste à faible volume qu'un technicien sait déjà ajuster peut attendre un an.

Donnez à l'inventaire une échéance de deux semaines et un responsable, et faites-le signer par le directeur d'usine. C'est le document qui transforme « on a perdu notre gars LabVIEW » d'une panique en un plan avec une première ligne, et c'est celui que vous montrerez à un candidat ou à un intégrateur pour expliquer en quoi consiste le travail.

L'inventaire est aussi la première page du document de passation que vous n'avez jamais eu. Documenter un poste de test pour la passation contient le modèle complet, et Le facteur bus en ingénierie de test explique comment l'usine s'est retrouvée avec une colonne pleine de « Personne ».

Gardez les résultats qui remontent

Le rendement ne cesse pas d'avoir de l'importance parce que l'ingénieur est parti. Le seul changement que vous pouvez faire à un poste sans ouvrir sa séquence, c'est la destination des résultats.

Postez chaque run vers l'API REST v2 de TofuPilot. La charge utile est petite, l'authentification est un bearer token et le poste n'a pas besoin de Python.

{  "outcome": "PASS",  "procedure_id": "8122a38c-3fbc-4bf0-881b-24ea1e2cb937",  "serial_number": "UAUT-04829",  "part_number": "PCB-MAIN-V2",  "started_at": "2026-09-14T08:12:04Z",  "ended_at": "2026-09-14T08:13:41Z",  "phases": [    {      "name": "Power Rails",      "outcome": "PASS",      "started_at": "2026-09-14T08:12:10Z",      "ended_at": "2026-09-14T08:12:14Z",      "measurements": [        {          "name": "rail_3v3",          "outcome": "PASS",          "measured_value": 3.31,          "units": "V",          "validators": [            { "operator": ">=", "expected_value": 3.2, "outcome": "PASS" },            { "operator": "<=", "expected_value": 3.4, "outcome": "PASS" }          ]        }      ]    }  ]}

Le procedure_id vient de la page de la procedure dans TofuPilot. outcome vaut PASS, FAIL, ERROR, TIMEOUT ou ABORTED, et les horodatages sont en ISO 8601. Les phases et les mesures sont optionnelles, donc la version minimale viable, ce sont les six premiers champs. Créez une clé API par poste dans TofuPilot et gardez-la dans l'environnement du poste, pas dans le VI, pour que la changer plus tard n'implique pas un rebuild.

Depuis LabVIEW, les VI HTTP Client font cela en quatre nœuds : Open Handle, Add Header deux fois (Authorization: Bearer <api key> et Content-Type: application/json), POST vers https://www.tofupilot.app/api/v2/runs avec la chaîne JSON, Close Handle. Déposez-les dans le SubVI de rapport existant après l'écriture TDMS, pour que rien d'autre ne change dans la séquence. Si vous préférez ne pas toucher au VI du tout, faites écrire le JSON par le poste dans un dossier et laissez un court script Python le poster.

# Poste un fichier de run vers TofuPilot ; à appeler depuis un observateur de dossier ou System Exec après chaque testimport jsonimport osimport sysimport requestsAPI_URL = "https://www.tofupilot.app/api/v2/runs"def upload(path):    with open(path, encoding="utf-8") as f:        payload = json.load(f)    headers = {"Authorization": f"Bearer {os.environ['TOFUPILOT_API_KEY']}"}    response = requests.post(API_URL, json=payload, headers=headers, timeout=30)    response.raise_for_status()    print(f"Uploaded run {response.json()['id']} from {path}")if __name__ == "__main__":    upload(sys.argv[1])

Après une semaine, vous avez le FPY par poste et un Pareto des défaillances dans TofuPilot sans que personne n'ait ouvert un VI. C'est le chiffre que le directeur d'usine demande, et c'est le chiffre qui vous dit quel poste reconstruire en premier.

Les 30 premiers jours : reconstruire un poste

Prenez la première ligne de l'inventaire et reconstruisez-la en Python avec le TofuPilot Framework. Le poste devient un dossier : procedure.yaml pour la séquence et les limites, phases/ pour les étapes de test, plugs/ pour les instruments, tout en texte et tout sous Git. N'importe qui dans l'équipe peut l'ouvrir.

# FCT-01 reconstruit : mêmes limites que le poste LabVIEW, même format de numéro de sériename: Controller Board FCTversion: 2.0.0unit:  serial_number:    default_value: "UAUT-00000"  part_number:    default_value: "PCB-MAIN-V2"plugs:  - name: dmm    python: plugs.dmm:Multimeter    config:      address: "TCPIP::192.168.1.100::INSTR"main:  - name: Power Rails    python: phases.power_rails    measurements:      - name: rail_3v3        unit: V        validators:          - operator: ">="            expected_value: 3.2          - operator: "<="            expected_value: 3.4      - name: rail_5v        unit: V        validators:          - operator: ">="            expected_value: 4.8          - operator: "<="            expected_value: 5.2

# Lit deux rails ; le framework les vérifie contre les validateurs ci-dessusdef power_rails(measurements, dmm):    measurements.rail_3v3 = dmm.read_voltage(101)  # le canal 101 du mux est le rail 3V3    measurements.rail_5v = dmm.read_voltage(102)

Faites-le tourner en parallèle du poste LabVIEW sur les mêmes unités pendant deux semaines. Les deux postent vers la même procedure dans TofuPilot, donc la comparaison est un filtre sur la liste des runs, pas un tableur. Quand le poste Python est d'accord avec l'ancien sur chaque unité, et n'est en désaccord que là où l'ancien avait tort, retirez le VI. Migrer de LabVIEW vers Python contient la correspondance phase par phase.

Vous n'avez pas besoin de convertir le reste de l'atelier ce mois-ci. Gérer une équipe de test mixte LabVIEW et Python couvre la coexistence des deux pendant que l'inventaire se réduit une ligne à la fois.

Ce qu'il ne faut pas faire

N'embauchez pas un prestataire pour maintenir l'ancien VI en vie indéfiniment. Un intégrateur certifié NI facture typiquement un taux journalier à quatre chiffres, et chaque demande de modification revient en quelques jours ou semaines. C'est acceptable pour un trimestre de relais. Comme arrangement permanent, c'est payer une prime pour faire du surplace.

Ne réécrivez pas tout d'un coup. Six postes reconstruits en un trimestre, ce sont six postes non validés et un ingénieur épuisé. Un poste, en parallèle, deux semaines, puis le suivant.

Ne sautez pas le fonctionnement en parallèle. Le poste LabVIEW a dix ans de correctifs non documentés incrustés. La seule façon de les trouver est de faire tourner les deux sur les mêmes unités et de regarder où ils divergent.

Ne recréez pas le point de défaillance unique en Python. Le framework rend le poste lisible par n'importe qui. Gardez-le ainsi avec un dépôt, un README et une seconde personne qui l'a fait tourner.

Commencez par un poste

Choisissez le poste au plus fort volume, ou celui qu'une seule personne sait ouvrir. Reconstruisez-le en Python avec le TofuPilot Framework et faites-le tourner en parallèle de la version LabVIEW sur les mêmes unités pendant deux semaines. Comparez les deux jeux de résultats dans TofuPilot avant de retirer quoi que ce soit.

curl -fsSL https://www.tofupilot.app/install | shtofupilot run ./procedure.yaml

Le pas à pas est dans Migrer de LabVIEW vers Python, et le framework est sur https://tofupilot.com/products/framework. L'offre Lab est gratuite, et tofupilot run fonctionne sans compte.