We’re in the process of implementing MQTT in our Ignition systems, but I’ve realized I might not fully understand how things work on the Engine side.
We currently have a single backend Ignition gateway with multiple sites connected. These sites are already in production, using Perspective HMIs populated by remote tag providers in our current setup.
We connected a test site to our new environment using MQTT, and I noticed that all the tags coming into the Engine are being created within the Engine tag provider. The problem is, our HMIs have hundreds of bindings that point to tags using the [site-name]/path/to/tag structure. I was under the impression that I could maintain this setup, with a tag provider subscribing to the relevant topics for each site.
Can someone help clarify how this should work and what steps I need to take?
(crossed posted this on cirrus link forum)
That's the way engine works. All tags come into Engine under their respective nodes. In the newest version, you can supposedly combine them into a UNS, but they will be under a single tag provider still. MQTT is really intended to be used for slow/low bandwidth connections, so if you're not in that scenario, you're still probably better off using remote tag providers.
Was there some issue with the gateway network you were having, or are these sites on low bandwidth connections?
Inductive pushed us towards MQTT as we are anticipating 5-7 million tags over the next few years and we were told ignition gateway would struggle with this. Some individual sites could have anywhere from 250-750k tags.
If you wanted to split this out to separate tag providers, you'd need to create a new tag provider for each site, then build reference tag UDTs that reference the appropriate tags in the Engine module.
But back to the original problem, and I think this would be worse rather than better. Reason being is that all tag updates sent through MQTT would get pushed to the central Ignition gateway regardless of whether they're used or not on the central system. So unless you're only pushing a small subset of tags over MQTT, this would be worse I would think.
I would have to understand your system better and how you're using it, but it sounds like you'll need to start scaling differently or re-architect how it's built to better handle the upcoming growth.
We are moving from a single, central gateway, to more of a scale out architecture. With multiple backend gateways, each handling only a few sites each.
My guess would be that's a better approach than moving to MQTT. It should distribute the load and allow you to grow the system by adding new servers as needed.
This is an older post, but I also have an MQTT broker with hundreds of thousands of topics. Some of them are operating at very fast update rates. Most are not so fast. However i set up an ignition test with MQTT Engine connecting to my broker, and it brought my broker to its knees be subscribing to everything. I really wish there was a way to subscribe only to needed topics. Filtering wont even work well for me because i have hundreds of devices, and I need to monitor a few topics on each device.
I would call this a misapplication of MQTT. Its primary value is the reduction in data traffic by delivering only changes. OPC/UA is much better at optimizing high-change-rate data flows.
You should reconsider your architecture.
(Not that the feature you want isn't a good idea--you should pitch it to Cirrus Link.)
Hmm. I had a prior project requiring 20mS data transfer, and IA sales Eng pointed me towards MQTT. In the end, I did it in hardware with a buffer, and didn’t use MQTT.
Huh. Sounds like a mistake. OPC with a 20ms Sampling interval and a >1 second publishing interval would efficiently package up multiple samples per message. (Presuming you are using a PLC's OPC server. IA's native drivers would need some tuning.)
I should clarify… only about 10% of the points are 100ms at the fastest. Many others are slower. But using Ignition as a SCADA UI-only in this case, I wouldn’t need to subscribe to all 1M topics. It seems like a very big assumption that anyone would want to subscribe to ALL AVAILABLE points on a given broker as basically the ONLY way to connect. I was hoping the Cirrus team was monitoring this chat! I’ll go leave the comment on their side.
Also.. I see the MQTT Engine includes an option for FILTERED NAMESPACES. This appears to filter OUT namespaces, so its not really useful for selectively subscribing to particular devices? Am I missing something?