Python y LabVIEW: cuatro formas de hacerlos trabajar juntos

En mis bancos de pruebas, LabVIEW y Python suelen trabajar juntos. LabVIEW gestiona la interfaz del operador, el tiempo real y la FPGA. Python se encarga del análisis de datos y de la automatización de los ensayos. Hay varias formas de comunicarlos. Esto es lo que he aprendido.

La primera pregunta: ¿quién manda?

Antes de elegir una solución, empiezo por preguntarme qué programa da las órdenes.

• LabVIEW llama a Python: con el Python Node, integrado en LabVIEW.
• Python llama a LabVIEW: ejecuta un programa LabVIEW existente.
• Dos programas separados: cada uno funciona por su cuenta y se intercambian mensajes por la red.
• Python solo: controla directamente el hardware de NI u otro, sin LabVIEW.

LabVIEW llama a Python: el Python Node

Es la forma más sencilla de empezar. Tres reglas me evitan la mayoría de los problemas:

• Abrir la sesión Python una sola vez, antes del bucle, y no en cada vuelta. Si no, el programa se vuelve muy lento.
• Intercambiar datos sencillos: números, textos, arreglos. El código Python complejo queda oculto tras unas pocas funciones.
• Fijar la instalación de Python: un entorno Python propio para cada aplicación, con la misma versión de 32 o 64 bits que LabVIEW.

En la práctica, la mayoría de las fallas que he encontrado no vienen del código, sino de la instalación de Python.

Python llama a LabVIEW

Cuando Python dirige los ensayos, puede reutilizar un programa LabVIEW existente de tres formas:

• ActiveX: antiguo y solo para Windows, pero todavía funciona.
• Una DLL generada por LabVIEW: rápida, pero si el código LabVIEW falla, Python también.
• Un ejecutable lanzado por Python: sencillo pero lento. Mejor para tratamientos puntuales.

Dos programas separados

Es lo que recomiendo para un banco que funciona durante mucho tiempo. Si un programa falla, el otro sigue. Cada uno puede además actualizarse sin tocar el otro.

• TCP: sencillo, sin herramientas adicionales.
• ZeroMQ: más robusto, gestiona solo las reconexiones.
• gRPC: la solución que impulsa NI. El contrato se escribe en un archivo común y el código de ambos lados se genera a partir de él.
• HTTP: más lento, pero práctico para órdenes ocasionales.

¿Contrato o API? El contrato es el documento compartido que describe los mensajes intercambiados entre dos programas: ninguno de los dos lo posee. La API es el conjunto de funciones que un programa ofrece a los demás: le pertenece. Con gRPC, el contrato sirve para generar la API de cada lado.

¿Y si prescindimos de LabVIEW?

NI ofrece bibliotecas Python oficiales para la mayor parte de su hardware, como nidaqmx para las tarjetas de adquisición. Para un proyecto nuevo sin interfaz LabVIEW, Python puede bastar. NI también permite que LabVIEW y Python compartan el mismo hardware a la vez, y TestStand puede llamar directamente a scripts de Python.

Cómo elegir

• Prototipo o cálculo puntual: el Python Node.
• Banco que funciona durante mucho tiempo: dos programas separados, con gRPC o ZeroMQ.
• Python manda, llamadas poco frecuentes: un ejecutable o HTTP.
• Secuenciador TestStand: TestStand llamando directamente a Python.
• Proyecto nuevo sin interfaz LabVIEW: Python solo.

Para recordar

• Empezar con el Python Node es fácil; hacerlo confiable exige rigor con la instalación de Python.
• Para un banco duradero, separo los dos programas.
• LabVIEW conserva la interfaz, el tiempo real y la FPGA; Python, el análisis y la automatización.

Para saber más

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