MQTT dans LabVIEW : bibliothèques et patterns pour bancs de test

LabVIEW n'a pas de fonctions MQTT dans sa palette de base, mais les ajouter est simple : installez une bibliothèque G, appelez paho-mqtt via le Python Node ou faites tourner un petit bridge à côté de votre VI. La vraie difficulté est l'architecture. Un banc de test qui publie depuis sa boucle de mesure finira par bloquer un test au moindre hoquet réseau. Ce guide compare les options et présente un pattern qui garde des mesures déterministes et des résultats fiables.

Vos options en un coup d'œil

L'option open source la plus répandue est la bibliothèque MQTT Client du LabVIEW Open Source Project, disponible via VIPM et développée sur GitHub. Des toolkits commerciaux existent aussi sur le NI Tools Network. Tous suivent le même modèle : créer un client, se connecter, s'abonner, recevoir les messages via un événement ou une file d'attente, publier, se déconnecter. Les fonctionnalités évoluent d'une version à l'autre : lisez la description du paquet pour connaître la version du protocole et les options TLS avant de vous engager.

Concevez d'abord les topics

Mettez-vous d'accord sur une arborescence de topics avant de câbler quoi que ce soit. Pour un laboratoire de test, un sous-arbre par station fonctionne bien :

Le topic de statut retenu, combiné à un Last Will qui publie offline, donne à chaque tableau de bord l'état réel de chaque station, même après un plantage ou un câble réseau arraché. Voir MQTT Last Will et les messages retenus pour leur comportement. Pour les laboratoires plus importants, les règles générales des bonnes pratiques de conception de topics s'appliquent.

Pour les payloads, construisez un cluster (numéro de série, résultats de chaque étape, limites, pass/fail, horodatages) et convertissez-le avec Flatten To JSON. Côté réception, Unflatten From JSON avec le même type de cluster retransforme les commandes en données typées.

L'architecture qui ne bloque pas les tests

N'appelez jamais Publish dans une boucle de mesure cadencée. Un publish peut bloquer plusieurs secondes pendant que le client se reconnecte, et la temporisation de votre test dérivera sans prévenir.

Utilisez plutôt un schéma producteur/consommateur ou un Queued Message Handler :

1. Boucle de mesure : exécute la séquence de test et place résultats et télémétrie dans une file d'attente LabVIEW. Elle ne touche jamais au réseau.
2. Boucle MQTT : possède la référence du client. Elle défile les éléments et les publie, reçoit les commandes (via le user event de la bibliothèque ou un dequeue avec timeout) et les transmet à la boucle de mesure via une seconde file.
3. Gestion de la connexion : la boucle MQTT se reconnecte avec back-off et se réabonne après chaque reconnexion. Les résultats produits hors ligne restent dans la file (ou dans un fichier local) et sont publiés au retour de la connexion.

Cette séparation rend aussi le banc testable : vous pouvez exécuter la boucle de mesure en remplaçant la boucle MQTT par un stub qui écrit dans un fichier.

Option A : une bibliothèque G native

Avec une bibliothèque G installée depuis VIPM, le diagramme de la boucle MQTT ressemble généralement à ceci :

1. Create/Open client : hôte du broker broker.connectmq.com, port 1883 (ou 8883 avec TLS), un client ID unique comme labview-bench01-<random>, keep-alive de 30 s.
2. Set Will : topic testmqtt/labview/bench01/status, payload offline, QoS 1, retain true.
3. Connect avec un nom d'utilisateur et un mot de passe lus dans un fichier de configuration, jamais codés en dur dans le VI.
4. Publish online en retenu sur le topic de statut, puis Subscribe à testmqtt/labview/bench01/cmd/# en QoS 1.
5. Structure événement / boucle while : traitez les événements « message reçu » et défilez les éléments sortants.
6. À l'arrêt : publiez offline en retenu, puis faites un Disconnect propre (une déconnexion propre ne déclenche pas le Will).

Si la bibliothèque gère TLS, elle s'appuie généralement sur les fonctions TLS intégrées de LabVIEW et a besoin du certificat de la CA du broker. Testez d'abord TLS depuis un PC pour que les problèmes de certificats ne ressemblent pas à des bugs LabVIEW.

Option B : paho-mqtt via le Python Node

Le Python Node (LabVIEW 2018+) appelle des fonctions d'un module Python. Comme une session Python conserve l'état du module entre les appels, vous pouvez garder un client paho dans un module et l'appeler depuis LabVIEW comme une petite API. Installez la bibliothèque avec pip install paho-mqtt dans le même Python que celui utilisé par LabVIEW.

import queue
import uuid
import paho.mqtt.client as mqtt

_client = None
_inbox = queue.Queue()
_station = ""

def _on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        return
    client.publish(f"testmqtt/labview/{_station}/status", "online", qos=1, retain=True)
    client.subscribe(f"testmqtt/labview/{_station}/cmd/#", qos=1)

def _on_message(client, userdata, msg):
    _inbox.put((msg.topic, msg.payload.decode("utf-8", "replace")))

def connect(host, port, username, password, station):
    global _client, _station
    _station = station
    _client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                          client_id=f"labview-{station}-{uuid.uuid4().hex[:6]}")
    if username:
        _client.username_pw_set(username, password)
    _client.will_set(f"testmqtt/labview/{station}/status", "offline", qos=1, retain=True)
    _client.on_connect = _on_connect
    _client.on_message = _on_message
    _client.reconnect_delay_set(min_delay=1, max_delay=30)
    _client.connect(host, int(port), keepalive=30)
    _client.loop_start()           # thread réseau : reconnexion automatique
    return True

def publish(topic, payload, qos, retain):
    info = _client.publish(topic, payload, qos=int(qos), retain=bool(retain))
    return info.rc == mqtt.MQTT_ERR_SUCCESS

def poll(max_items):
    items = []
    while len(items) < int(max_items) and not _inbox.empty():
        items.append(_inbox.get_nowait())
    return items                   # liste de tuples (topic, payload)

def disconnect():
    _client.publish(f"testmqtt/labview/{_station}/status", "offline", qos=1, retain=True).wait_for_publish(5)
    _client.disconnect()
    _client.loop_stop()
    return True

Dans LabVIEW :

• Open Python Session une seule fois au démarrage (version 3.x, même architecture que LabVIEW) et conservez la référence de session dans le registre à décalage de la boucle MQTT.
• Appelez connect avec les paramètres du broker, puis poll toutes les 100 ms environ. Câblez comme type de retour un tableau de clusters de deux chaînes : chaque tuple devient un cluster (topic, payload).
• Appelez publish avec la chaîne JSON issue de Flatten To JSON.
• À l'arrêt, appelez disconnect, puis Close Python Session.

paho fait tourner son propre thread réseau avec reconnexion automatique : le côté LabVIEW reste simple et ne bloque jamais longtemps sur le réseau. Le même module fonctionne en MQTT 5 si vous passez protocol=mqtt.MQTTv5 au client. Pour en savoir plus sur la bibliothèque, voir MQTT avec Python.

Tester le banc sans matériel

Avant de brancher de vrais instruments, vérifiez la partie MQTT de bout en bout. Dans un terminal (ou dans le client en ligne), observez tout ce que publie la station :

mosquitto_sub -h broker.connectmq.com -p 1883 -t 'testmqtt/labview/#' -v

Dans un autre, envoyez une commande comme le ferait le MES :

mosquitto_pub -h broker.connectmq.com -p 1883 -q 1 \
  -t 'testmqtt/labview/bench01/cmd/start' -m '{"serial":"SN-0001","recipe":"A"}'

Vous devriez voir status = online, puis un message result pour SN-0001. Tuez maintenant le processus LabVIEW (sans arrêt propre) : au bout d'environ 1,5 fois l'intervalle de keep-alive, le broker publie le Will et le statut passe à offline. Cette seule vérification prouve que votre Will, le statut retenu et la logique de reconnexion fonctionnent.

Observer vos stations de test dans le navigateur

Pour des tests de régression automatisés, scriptez les mêmes étapes : publiez une commande, attendez le résultat avec un timeout et vérifiez ses champs. L'approche s'étend jusqu'à des tests hardware-in-the-loop complets.

Pièges courants

• Même client ID sur deux bancs après la copie d'un projet : les stations se déconnectent mutuellement en boucle. Générez l'ID à partir du nom de la station et d'un suffixe aléatoire.
• La publication comme référence de temps : si les résultats ne partent que lorsque le réseau est disponible, le journal de test et les données MQTT ne concordent pas. Horodatez les résultats au moment de la mesure, pas de la publication.
• Payloads énormes : les formes d'onde de millions d'échantillons vont dans des fichiers ou une base de données ; publiez un résumé et un lien. Comparez la taille des messages aux limites du broker avant la mise en production.
• Résultats retenus : ne retenez pas les résultats par unité, sinon chaque nouvel abonné reçoit un résultat périmé de la dernière unité. Ne retenez que de l'état.

LabVIEW et MQTT font bon ménage dès que le réseau vit dans sa propre boucle : choisissez une bibliothèque que vous pouvez maintenir, fixez topics et QoS dès le départ, utilisez un statut retenu avec Last Will et testez tout le chemin avec un client en ligne de commande avant que la première vraie unité n'arrive sur le banc. Si MATLAB assure l'analyse en aval, voir MQTT dans MATLAB.

Questions fréquentes