MQTT en LabVIEW: librerías y patrones para bancos de prueba

LabVIEW no trae funciones MQTT en la paleta base, pero añadirlas es fácil: instala una librería G, llama a paho-mqtt a través del Python Node o ejecuta un pequeño bridge junto a tu VI. Lo difícil es la arquitectura. Un banco de pruebas que publica desde dentro de su bucle de medida acabará bloqueando una prueba cuando la red falle. Esta guía compara las opciones y muestra un patrón que mantiene las medidas deterministas y los resultados fiables.

Tus opciones de un vistazo

La opción open source más usada es la librería MQTT Client del LabVIEW Open Source Project, disponible en VIPM y desarrollada en GitHub. También existen toolkits comerciales en el NI Tools Network. Todos siguen el mismo modelo: crear un cliente, conectar, suscribirse, recibir mensajes mediante un evento o una cola, publicar y desconectar. Las funciones cambian entre versiones, así que lee la descripción del paquete para conocer la versión del protocolo y las opciones de TLS antes de decidirte.

Diseña primero los topics

Acuerda una estructura de topics antes de cablear nada. Para un laboratorio de pruebas, un subárbol por estación funciona bien:

El topic de estado retenido, combinado con un Last Will que publica offline, da a cada dashboard el estado real de cada estación, incluso tras un cuelgue o un cable de red desconectado. Consulta MQTT Last Will y mensajes retenidos para ver cómo se comportan ambos. Para laboratorios más grandes se aplican las reglas generales de buenas prácticas de diseño de topics.

Para los payloads, construye un cluster (número de serie, resultados de cada paso, límites, pass/fail, timestamps) y conviértelo con Flatten To JSON. En el lado receptor, Unflatten From JSON con el mismo tipo de cluster convierte los comandos de nuevo en datos tipados.

La arquitectura que no bloquea las pruebas

Nunca llames a Publish dentro de un bucle de medida temporizado. Un publish puede bloquearse varios segundos mientras el cliente se reconecta, y la temporización de tu prueba se desviará sin avisar.

Usa en su lugar un esquema productor/consumidor o un Queued Message Handler:

1. Bucle de medida: ejecuta la secuencia de prueba y encola resultados y telemetría en una cola de LabVIEW. Nunca toca la red.
2. Bucle MQTT: es dueño de la referencia del cliente. Desencola elementos y los publica, recibe comandos (mediante el user event de la librería o un dequeue con timeout) y los reenvía al bucle de medida por una segunda cola.
3. Gestión de la conexión: el bucle MQTT se reconecta con back-off y vuelve a suscribirse tras cada reconexión. Los resultados que llegan sin conexión se quedan en la cola (o en un archivo local) y se publican cuando vuelve la conexión.

Esta separación también hace que el banco sea testeable: puedes ejecutar el bucle de medida sustituyendo el bucle MQTT por un stub que escriba en un archivo.

Opción A: una librería G nativa

Con una librería G instalada desde VIPM, el diagrama de bloques del bucle MQTT suele quedar así:

1. Create/Open client: host del broker broker.connectmq.com, puerto 1883 (o 8883 con TLS), un client ID único como labview-bench01-<random>, keep-alive de 30 s.
2. Set Will: topic testmqtt/labview/bench01/status, payload offline, QoS 1, retain true.
3. Connect con usuario y contraseña leídos de un archivo de configuración, nunca escritos en el VI.
4. Publish online retenido en el topic de estado y luego Subscribe a testmqtt/labview/bench01/cmd/# con QoS 1.
5. Estructura de eventos / bucle while: gestiona los eventos de "mensaje recibido" y desencola los elementos salientes.
6. Al apagar: publica offline retenido y luego haz Disconnect limpio (una desconexión limpia no dispara el Will).

Si la librería soporta TLS, normalmente se apoya en las funciones TLS integradas de LabVIEW y necesita el certificado de la CA del broker. Prueba primero TLS desde un PC para que los problemas de certificados no parezcan bugs de LabVIEW.

Opción B: paho-mqtt a través del Python Node

El Python Node (LabVIEW 2018+) llama a funciones de un módulo de Python. Como una sesión de Python conserva el estado del módulo entre llamadas, puedes mantener un cliente paho en un módulo y llamarlo desde LabVIEW como una pequeña API. Instala la librería con pip install paho-mqtt en el mismo Python que usa 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()           # hilo de red: se reconecta automáticamente
    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                   # lista de tuplas (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

En LabVIEW:

• Open Python Session una vez al arrancar (versión 3.x, con la misma arquitectura que LabVIEW) y guarda la referencia de sesión en el shift register del bucle MQTT.
• Llama a connect con los datos del broker y después a poll cada 100 ms aproximadamente. Cablea como tipo de retorno un array de clusters de dos strings: cada tupla se convierte en un cluster (topic, payload).
• Llama a publish con el string JSON de Flatten To JSON.
• Al apagar, llama a disconnect y luego a Close Python Session.

paho ejecuta su propio hilo de red con reconexión automática, así que el lado de LabVIEW queda simple y nunca se bloquea mucho tiempo en la red. El mismo módulo funciona con MQTT 5 si pasas protocol=mqtt.MQTTv5 al cliente. Más sobre la librería en MQTT con Python.

Prueba el banco sin hardware

Antes de conectar instrumentos reales, comprueba el lado MQTT de extremo a extremo. En un terminal (o en el cliente online), observa todo lo que publica la estación:

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

En otro, envía un comando como lo haría el MES:

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

Deberías ver status = online y después un mensaje result para SN-0001. Ahora mata el proceso de LabVIEW (no una parada limpia): en torno a 1,5 veces el intervalo de keep-alive, el broker publica el Will y el estado pasa a offline. Esa única comprobación demuestra que tu Will, el estado retenido y la lógica de reconexión funcionan.

Observa tus estaciones de prueba en el navegador

Para pruebas de regresión automatizadas, automatiza los mismos pasos: publica un comando, espera el resultado con un timeout y comprueba sus campos. El enfoque escala hasta un testing hardware-in-the-loop completo.

Errores habituales

• Mismo client ID en dos bancos tras copiar un proyecto: las estaciones se desconectan mutuamente en bucle. Genera el ID a partir del nombre de la estación más un sufijo aleatorio.
• Usar la publicación como referencia de tiempo: si los resultados solo salen cuando hay red, el log de la prueba y los datos MQTT no coinciden. Pon el timestamp a los resultados cuando se miden, no cuando se publican.
• Payloads enormes: las formas de onda con millones de muestras van en archivos o en una base de datos; publica un resumen y un enlace. Comprueba el tamaño de los mensajes frente a los límites del broker antes de ponerlo en producción.
• Resultados retenidos: no retengas resultados por unidad, o cada nuevo suscriptor recibirá un resultado obsoleto de la última unidad. Retén solo estado.

LabVIEW y MQTT encajan bien una vez que la red vive en su propio bucle: elige una librería que puedas mantener, acuerda topics y QoS desde el principio, usa un estado retenido con Last Will y prueba todo el camino con un cliente de línea de comandos antes de que la primera unidad real llegue al banco. Si MATLAB hace el análisis aguas abajo, consulta MQTT en MATLAB.

Preguntas frecuentes