MQTT, cRIO and large-scale systems

By Anders Pedersen Sekanina · November 2025 · ← Back to blog

At the NORDLUG meeting on 11 November 2025 I gave a talk on how MQTT can be used as a generic communication protocol in large LabVIEW/cRIO systems. The talk was based on a real refactoring project and showed how MQTT can replace a mix of REST APIs, network-published shared variables and other proprietary protocols.

The starting point: a large, heterogeneous system

The existing system consisted of a Windows PC running LabVIEW as a central hub, communicating with a number of cRIOs via Network Published Shared Variables and FPGA layers, and with other PCs and tools via REST API, SSH and MODBUS. It worked – but it was hard to extend, and the communication was tightly coupled to NI's own protocols.

The goal was to replace this mixture with one common protocol: MQTT. With a central broker in the middle, all devices – Windows/Linux PCs, cRIOs, Python/C++/C# programs and third-party tools – can talk to each other over the same publish/subscribe system. This gives far looser coupling and makes it straightforward to add new clients without touching existing code.

What is MQTT?

MQTT (Message Queuing Telemetry Transport) is an open OASIS standard designed as an extremely lightweight publish/subscribe protocol. It was originally developed for IoT devices with limited bandwidth and processing power, but is today used at large scale in manufacturing, telecommunications, automotive, and oil & gas.

An MQTT packet contains a topic (a text string divided by / for subtopics, e.g. system/group1/device23/data), a set of flags (QoS level 0/1/2, DUP and Retain) and a payload of up to 256 MB – typically JSON text. Clients subscribe to topics at a central broker, and all messages published to a topic are forwarded to all subscribers. It is simple, reliable and language-agnostic.

MQTT in LabVIEW

NI's MQTT support in LabVIEW makes it relatively straightforward to integrate a broker into an existing system. In the demo I showed how LabVIEW can both publish and subscribe to topics, and how a cRIO via the NI Scan Engine can expose its I/O values directly onto the MQTT bus. The Scan Engine runs by default at a 10 ms update rate (minimum < 1 ms), while the MQTT layer typically runs at 100 ms (minimum 10 ms) – a trade-off that suits most applications.

One important detail about MQTT topics is that they are case-sensitive (myTopic ≠ mytopic), so it pays to define a clear topic structure from the start, for example:

mysystem/json/v1/group1/device23/data

Wildcards make it easy to subscribe to entire groups: mysystem/json/v1/group1/# captures all signals in group1, while mysystem/+/+/group1/+/data subscribes to the data field in group1 across all versions and devices.

Home automation with LabVIEW and MQTT

As a finale I showed a fun demo: MQTT and LabVIEW used for home automation. It illustrated nicely that the protocol is completely generic – the same broker and the same LabVIEW VIs can be used for industrial test systems and for controlling the lights at home.

Next NORDLUG meeting

The next meeting is 24 November 2025 – online – with Jesper Kjær Sørensen from Gpower on VIPM and Tom McQuillan. The meeting after that is 20 January 2026 in-person and online, covering LabVIEW and source code control. Everyone is welcome – see more on the Community page.

/Anders Pedersen Sekanina