MQTT in LabVIEW: Bibliotheken und Muster für Prüfstände

LabVIEW hat keine MQTT-Funktionen in der Basispalette, aber sie lassen sich leicht ergänzen: Installiere eine G-Bibliothek, rufe paho-mqtt über den Python Node auf oder lass eine kleine Bridge neben deinem VI laufen. Der schwierige Teil ist die Architektur. Ein Prüfstand, der aus seiner Messschleife heraus publiziert, blockiert früher oder später einen Test, wenn das Netzwerk hakt. Dieser Leitfaden vergleicht die Optionen und zeigt ein Muster, das Messungen deterministisch und Ergebnisse zuverlässig hält.

Deine Optionen im Überblick

Die am weitesten verbreitete Open-Source-Option ist die Bibliothek MQTT Client des LabVIEW Open Source Project, verfügbar über VIPM und entwickelt auf GitHub. Daneben gibt es kommerzielle Toolkits im NI Tools Network. Alle folgen demselben Modell: Client erzeugen, verbinden, abonnieren, Nachrichten über ein Event oder eine Queue empfangen, publizieren, trennen. Der Funktionsumfang ändert sich zwischen Releases, lies also vor der Entscheidung in der Paketbeschreibung nach, welche Protokollversion und welche TLS-Optionen unterstützt werden.

Zuerst die Topics planen

Lege ein Topic-Layout fest, bevor du irgendetwas verdrahtest. Für ein Prüflabor funktioniert ein Teilbaum pro Station gut:

Das retained Status-Topic zusammen mit einem Last Will, der offline publiziert, liefert jedem Dashboard den echten Zustand jeder Station, auch nach einem Absturz oder einem gezogenen Netzwerkkabel. Wie sich beides verhält, steht unter MQTT Last Will und Retained Messages. Für größere Labore gelten die allgemeinen Regeln aus den Best Practices für Topic-Design.

Für die Payloads baust du einen Cluster (Seriennummer, Ergebnisse der Prüfschritte, Grenzwerte, Pass/Fail, Zeitstempel) und wandelst ihn mit Flatten To JSON um. Auf der Empfängerseite macht Unflatten From JSON mit demselben Cluster-Typ aus Befehlen wieder typisierte Daten.

Die Architektur, die Tests nicht blockiert

Rufe Publish niemals in einer getakteten Messschleife auf. Ein Publish kann sekundenlang blockieren, während sich der Client neu verbindet, und das Timing deines Tests verschiebt sich unbemerkt.

Nutze stattdessen ein Producer/Consumer- oder Queued-Message-Handler-Layout:

1. Messschleife: führt die Prüfsequenz aus und legt Ergebnisse und Telemetrie in eine LabVIEW-Queue. Sie fasst das Netzwerk nie an.
2. MQTT-Schleife: besitzt die Client-Referenz. Sie holt Einträge aus der Queue und publiziert sie, empfängt Befehle (über das User Event der Bibliothek oder ein Dequeue mit Timeout) und reicht sie über eine zweite Queue an die Messschleife weiter.
3. Verbindungsbehandlung: Die MQTT-Schleife verbindet sich mit Back-off neu und abonniert nach jedem Reconnect erneut. Ergebnisse, die offline anfallen, bleiben in der Queue (oder einer lokalen Datei) und werden publiziert, sobald die Verbindung zurück ist.

Diese Trennung macht den Prüfstand auch testbar: Du kannst die Messschleife laufen lassen und die MQTT-Schleife durch einen Stub ersetzen, der in eine Datei schreibt.

Option A: eine native G-Bibliothek

Mit einer über VIPM installierten G-Bibliothek sieht das Blockdiagramm der MQTT-Schleife typischerweise so aus:

1. Create/Open client: Broker-Host broker.connectmq.com, Port 1883 (oder 8883 mit TLS), eine eindeutige Client-ID wie labview-bench01-<random>, Keep-Alive 30 s.
2. Set Will: Topic testmqtt/labview/bench01/status, Payload offline, QoS 1, Retain true.
3. Connect mit Benutzername und Passwort aus einer Konfigurationsdatei, niemals fest im VI.
4. Publish online retained auf das Status-Topic, danach Subscribe auf testmqtt/labview/bench01/cmd/# mit QoS 1.
5. Ereignisstruktur / While-Schleife: Events „Nachricht empfangen“ behandeln und ausgehende Einträge aus der Queue holen.
6. Beim Herunterfahren: offline retained publizieren, dann sauber Disconnect (ein sauberes Trennen löst den Will nicht aus).

Unterstützt die Bibliothek TLS, nutzt sie meist die eingebauten TLS-Funktionen von LabVIEW und braucht das CA-Zertifikat des Brokers. Teste TLS zuerst von einem PC aus, damit Zertifikatsprobleme nicht wie LabVIEW-Bugs aussehen.

Option B: paho-mqtt über den Python Node

Der Python Node (LabVIEW 2018+) ruft Funktionen aus einem Python-Modul auf. Da eine Python-Session den Modulzustand zwischen Aufrufen behält, kannst du einen paho-Client in einem Modul halten und ihn aus LabVIEW wie eine kleine API aufrufen. Installiere die Bibliothek mit pip install paho-mqtt in genau dem Python, das LabVIEW verwendet.

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()           # Netzwerk-Thread: verbindet sich automatisch neu
    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 von (topic, payload)-Tupeln

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

In LabVIEW:

• Open Python Session einmal beim Start (Version 3.x, gleiche Bitbreite wie LabVIEW) und die Session-Referenz im Schieberegister der MQTT-Schleife halten.
• connect mit den Broker-Daten aufrufen, danach etwa alle 100 ms poll. Als Rückgabetyp ein Array aus Clustern mit zwei Strings verdrahten: Jedes Tupel wird zu einem Cluster (Topic, Payload).
• publish mit dem JSON-String aus Flatten To JSON aufrufen.
• Beim Herunterfahren disconnect und anschließend Close Python Session aufrufen.

paho betreibt einen eigenen Netzwerk-Thread mit automatischem Reconnect, die LabVIEW-Seite bleibt also einfach und blockiert nie lange am Netzwerk. Dasselbe Modul funktioniert mit MQTT 5, wenn du dem Client protocol=mqtt.MQTTv5 übergibst. Mehr zur Bibliothek selbst unter MQTT mit Python.

Den Prüfstand ohne Hardware testen

Bevor du echte Messgeräte anschließt, prüfe die MQTT-Seite Ende-zu-Ende. Beobachte in einem Terminal (oder im Online-Client) alles, was die Station publiziert:

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

Sende in einem zweiten Terminal einen Befehl, so wie es das MES tun würde:

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

Du solltest status = online sehen und danach eine result-Nachricht für SN-0001. Beende jetzt den LabVIEW-Prozess hart (kein sauberer Stopp): Nach etwa dem 1,5-Fachen des Keep-Alive-Intervalls publiziert der Broker den Will, und der Status wechselt auf offline. Diese eine Prüfung beweist, dass Will, retained Status und Reconnect-Logik funktionieren.

Deine Prüfstationen im Browser beobachten

Für automatisierte Regressionstests skriptest du dieselben Schritte: Befehl publizieren, mit Timeout auf das Ergebnis warten und dessen Felder prüfen. Der Ansatz skaliert bis zu vollständigen Hardware-in-the-Loop-Tests.

Typische Stolperfallen

• Gleiche Client-ID auf zwei Prüfständen nach dem Kopieren eines Projekts: Die Stationen trennen sich gegenseitig in einer Schleife. Erzeuge die ID aus dem Stationsnamen plus einem zufälligen Suffix.
• Publizieren als Zeitbasis: Gehen Ergebnisse nur raus, wenn das Netzwerk steht, passen Prüfprotokoll und MQTT-Daten nicht zusammen. Versieh Ergebnisse beim Messen mit einem Zeitstempel, nicht beim Publizieren.
• Riesige Payloads: Wellenformen mit Millionen Samples gehören in Dateien oder eine Datenbank; publiziere eine Zusammenfassung und einen Verweis. Prüfe die Nachrichtengrößen gegen die Broker-Limits, bevor du live gehst.
• Retained Ergebnisse: Ergebnisse pro Teil nicht als retained senden, sonst bekommt jeder neue Subscriber ein veraltetes Ergebnis des letzten Teils. Nur Zustände retainen.

LabVIEW und MQTT passen gut zusammen, sobald das Netzwerk in einer eigenen Schleife lebt: Wähle eine Bibliothek, die du pflegen kannst, lege Topics und QoS früh fest, nutze einen retained Status mit Last Will und teste den ganzen Weg mit einem Kommandozeilen-Client, bevor das erste echte Teil auf den Prüfstand kommt. Wenn MATLAB nachgelagert die Analyse übernimmt, siehe MQTT in MATLAB.

Häufig gestellte Fragen