I like to think of it like the marketing emails you never manage to escape. A company hands its emails to a mailing service, the mailing service keeps the list of subscribers and delivers copies to everyone on it, and you signed up once for a 10% off coupon and have received every email since. The company doesn’t know who you are, and you never talk to the company directly. In this setup, Transmission is the company, Distributor is the mailing service, and Engine is your inbox, still subscribed.

Why Use MQTT?

MQTT is a publish-and-subscribe protocol, and that structure is the reason to use it. The central gateway maintains a single broker connection no matter how many edge sites feed into it, instead of polling every device directly. Data is also published by exception, so values only cross the network when they change, which is useful on cellular links and other constrained networks.

MQTT alone consolidates connections into a single stream, but it says nothing about what the data looks like. A plain MQTT message is just a value on a named topic (think a string or a JSON blob), and every publisher may format it differently.

Sparkplug adds a standard structure on top of MQTT: publishers announce everything they’re going to send when they first connect, and the broker notifies subscribers if a publisher drops offline. Ignition uses that first announcement, called a birth certificate, to build matching tags automatically instead of you mapping topics to tags by hand.

It’s like the welcome email of the subscription that lists everything you’re about to receive. And if the company quietly shuts down, the mailing service lets you know instead of leaving you to wonder why the emails with deals stopped.

MQTT Transmission

Transmission is the publisher. It’s installed on an edge or site-level gateway that already polls local PLCs or sensors over OPC UA or native drivers. Transmission watches the tag providers or folders you select and publishes them to the broker in Sparkplug format. In the email analogy, Transmission is the company’s sending tool. The PLCs write the content, and Transmission hands it to the mailing service.

You don’t need Transmission if a device already publishes Sparkplug natively, or if the gateway only consumes MQTT data.

MQTT Distributor

Distributor is the broker. It runs inside an Ignition gateway and accepts connections from publishers and subscribers. It’s the mailing service itself. It keeps the subscriber list and moves the mail but never writes any of it.

Since Distributor runs inside Ignition, the module works well for proofs of concept, development environments, and smaller production systems. Larger production systems will often use a standalone broker such as Chariot or HiveMQ, especially when applications outside Ignition share the broker or when security policies require the broker and SCADA system to be separate. Transmission and Engine can connect to compatible external MQTT brokers, so Distributor is not required.

MQTT Engine

Engine is the MQTT subscriber. When it’s installed on a central Ignition gateway, it connects to the broker, subscribes to Sparkplug data, and creates Ignition tags for every edge node, device, and metric it receives. Think of it like your email inbox. Everything a company sends to you shows up there, sorted and ready to read.

Once created, these tags act like any other Ignition tags. You can display them in Ignition Perspective, historize them, and use them for alarming and scripting. Because Sparkplug carries connection state, Engine also marks tags with bad quality when an edge node goes offline.

Engine is not the broker. It connects to the broker as a client in the same way Transmission does. If you want MQTT data to show up in Ignition, this is the module that does it.

Quick Guide for Setting Up a Basic Edge-to-Central Connection

For a basic two-gateway architecture, install the Transmission module at the edge and both Distributor and Engine modules on the central gateway. Then:

1. Configure MQTT Distributor on the central gateway: Confirm that MQTT Distributor is enabled and listening for TCP connections on port 1883. Under Users, create a broker user or confirm that one already exists. For a production connection across an untrusted network, use TLS instead of the non-secure listener.

2. Verify Engine connection on the same gateway. Under MQTT Engine > Servers, confirm that the default connection points to tcp:https://static.dmcinfo.com/ and shows Connected. If authentication is enabled in Distributor, confirm that the Engine connection uses the matching credentials.

3. Configure Transmission connection on the edge gateway. Under MQTT Transmission > Servers, point the broker connection to tcp://:1883 and confirm it shows 1 of 1 connected. Afterward, create a Transmitter with the tag provider, publish path, a Sparkplug Group ID, and a unique Edge Node ID. Transmission uses the next folder beneath that path as the Device ID.

4. Verify data in the Designer. Browse the MQTT Engine tag provider on the central gateway, find your Group ID and Edge Node, and confirm metrics appear and update when source values change.

For anything beyond a test setup, structure the edge tags as UDTs so every equipment instance publishes the same structure. New equipment can then appear in the namespace with the same layout as everything else.

When to Use MQTT

MQTT is a strong fit when you’re consolidating many edge sites or feeding the same data to several consumers. MQTT is also worth considering for bandwidth-constrained or congested networks because its publish-by-exception model reduces unnecessary traffic. On one of my recent projects, we chose MQTT because of the number of devices. Terminating hundreds of individual connections at the Ignition gateway wasn’t practical, so the devices published through a broker and Ignition held a single consolidated connection.

MQTT is not the best choice for every system. For a handful of devices on a single reliable plant network, with Ignition as the only consumer, a direct OPC UA connection is simpler. The Gateway Network also handles tag, alarm, and history sharing between a small number of Ignition gateways without extra infrastructure. And MQTT means another service to configure, secure, and monitor.

Once each module’s responsibility is clear, it becomes easier to place components, troubleshoot connections, and scale the architecture. The same pattern can also support a unified namespace, in which sites publish to a shared structure consumed by SCADA, MES, analytics, and cloud applications.

The post Which Ignition MQTT Modules Do You Need? Transmission, Engine, and Distributor Explained appeared first on DMC, Inc..

Our challenge was to build a world-class alarm analysis dashboard entirely in Ignition Perspective. This year’s primary round was unique in that we had eight consecutive hours to plan, develop, test, and submit the application.

The Alarm Intelligence Center

Our goal was to build more than a list of alarms. While Ignition’s standard alarm status and journal tables serve many applications well, we wanted our dashboard to help operators understand what the alarm data was telling them.

The result was the Alarm Intelligence Center, an operator-focused dashboard organized around three questions:

• How healthy is the facility?
• Which alarms or sources need attention?
• Is performance improving over time?

The Implementation

We focused on creating a slick, intuitive dashboard that made both real-time alarm data and historical performance easy to understand at a glance.

On the backend, we used named queries and custom scripting to analyze current and historical alarm events. Using EEMUA-informed alarm management metrics, we turned that analysis into information operators could act on, including:

• Alarm rate and time spent in flood.
• Average time to acknowledge.
• Standing and chattering alarms.
• Priority distribution and historical trends.
• A Pareto view identifying the sources responsible for most of the alarm load.

We also built custom alarm status and alarm history tables that fit seamlessly with the dashboard’s visual style. The tables provided simplified filtering and controls for viewing alarm details, acknowledging active alarms, and shelving them.

The result was a polished, standards-driven dashboard that helped operators quickly understand system health, identify problem areas, and decide where to focus their attention.

DMC is proud to share that our submission received the Best Error Handling award.

The experience demonstrated what DMC does best: bring the right people together, quickly turn ideas into action, and deliver a polished solution under a demanding deadline.

Check out the project on Ignition Exchange.

The post DMC Wins ‘Best Error Handling’ in Preliminary Round of the 2026 ICC Build-a-Thon appeared first on DMC, Inc..

LabVIEW Discussion

The program kicked off with the community reviewing the latest LabVIEW trends, updates to certifications, and products reaching their end of life. Then, the group moved on to an ice breaker. During the activity, attendees shared how LabVIEW empowers them, discussed their favorite features, and expressed what they hope to learn in the future.

DMC CORTEX Application Framework

Next, Kevin Shirey, LabVIEW Champion and DMC Senior Project Engineer, led the main technical talk for the day presenting DMC CORTEX.

NI TestStand has a feature-rich set, but mastering it—especially for custom step types, process models, and integration—can be time-consuming. It can also be challenging to create custom operator interfaces and build in data visualization.

DMC’s solution is DMC CORTEX, a powerful, flexible test application framework designed to leverage TestStand for its sequencing capabilities by integrating into LabVIEW. DMC CORTEX is engineered to get developers from setup to actionable test data faster. By building on top of NI’s commercial off-the-shelf (COTS) software platforms, including LabVIEW and TestStand, CORTEX minimizes the need for custom development and maximizes the value of proven tools.

At the user group meeting, Kevin highlighted the CORTEX user interface and data visualization. He hinted at future LabVIEW User Group topics such as test modes, safety monitoring, error and alarm handling, station configuration, and parameterized sequence— all of which are already handled by CORTEX.

CORTEX also uses two publicly available DMC UI toolkits, which improve the UI/UX of the application. These toolkits are available for anyone to install and use on VIPM.io, and are widely used in the LabVIEW community:

• DMC GUI Suite
• DMC Styles Toolkit

If you are interested in attending the next Research Triangle LabVIEW user group, reach out to Kevin Shirey (kevin.shirey@localhost) or check out the NI Research Triangle LabVIEW User Group Forums.

The post Raleigh LabVIEW User Group Meeting at DMC Featuring CORTEX Application Framework appeared first on DMC, Inc..