Python et LabVIEW : quatre façons de les faire travailler ensemble

Sur mes bancs de test, LabVIEW et Python travaillent souvent ensemble. LabVIEW gère l'interface opérateur, le temps réel et le FPGA. Python se charge de l'analyse des données et de l'automatisation des essais. Le sujet : les différentes façons de les faire communiquer, et ce que j'en retiens.

La première question : qui commande ?

Avant de choisir une solution, je commence par me demander quel logiciel donne les ordres à l'autre.

• LabVIEW appelle Python : avec le Python Node, intégré à LabVIEW.
• Python appelle LabVIEW : il lance un programme LabVIEW existant.
• Deux programmes séparés : chacun tourne de son côté, et ils échangent des messages par le réseau.
• Python seul : il pilote directement le matériel, NI ou autre, sans LabVIEW.

LabVIEW appelle Python : le Python Node

C'est la solution la plus simple pour démarrer. Trois règles m'évitent la plupart des problèmes :

• Ouvrir la session Python une seule fois, avant la boucle et non à chaque tour : sinon, le programme devient très lent.
• Échanger des données simples : nombres, textes, tableaux. Le code Python complexe reste caché derrière quelques fonctions.
• Figer l'installation de Python : un environnement dédié à chaque application, de même version 32 ou 64 bits que LabVIEW.

En pratique, la plupart des pannes que j'ai rencontrées ne viennent pas du code mais de l'installation de Python.

Python appelle LabVIEW

Quand Python dirige les essais, il peut réutiliser un programme LabVIEW existant de trois façons :

• ActiveX : ancien et limité à Windows, mais il fonctionne encore.
• Une DLL générée par LabVIEW : rapide, mais si le code LabVIEW plante, Python plante aussi.
• Un exécutable lancé par Python : simple, mais lent. À réserver aux traitements ponctuels.

Deux programmes séparés

C'est la solution que je recommande pour un banc qui tourne longtemps : si l'un des deux programmes plante, l'autre continue, et chacun peut être mis à jour sans toucher à l'autre.

• TCP : simple et sans outil supplémentaire.
• ZeroMQ : plus robuste, il gère seul les reconnexions.
• gRPC : la solution poussée par NI. Le contrat est écrit dans un fichier commun, et le code des deux côtés en est généré automatiquement.
• HTTP : plus lent, mais pratique pour des commandes occasionnelles.

Contrat ou API ? Le contrat est le document partagé qui décrit les messages échangés entre deux programmes : aucun des deux ne le possède. L'API est l'ensemble des fonctions qu'un logiciel offre aux autres : elle lui appartient. Avec gRPC, le contrat sert à générer l'API de chaque côté.

Et si l'on se passait de LabVIEW ?

NI propose des bibliothèques Python officielles pour la plupart de son matériel, comme nidaqmx pour les cartes d'acquisition. Pour un nouveau projet sans interface LabVIEW, Python peut donc suffire. NI permet aussi à LabVIEW et à Python de partager le même matériel en même temps, et TestStand sait appeler directement des scripts Python.

Comment choisir

• Prototype ou calcul ponctuel : le Python Node.
• Banc qui tourne longtemps : deux programmes séparés, avec gRPC ou ZeroMQ.
• Python commande, appels rares : un exécutable ou HTTP.
• Séquenceur TestStand : l'appel direct de Python par TestStand.
• Nouveau projet sans interface LabVIEW : Python seul.

À retenir

• Démarrer avec le Python Node est facile ; le rendre fiable demande de la rigueur sur l'installation de Python.
• Pour un banc durable, je sépare les deux programmes.
• LabVIEW garde l'interface, le temps réel et le FPGA ; Python, l'analyse et l'automatisation.

Pour aller plus loin

NI, Python Node, LabVIEW API Reference, ni.com ; NI, Python Resources for NI Hardware and Software, ni.com ; NI, grpc-labview, GitHub