OPC-UA or MQTT?

Maker
, ,
1

Hello!

I'm using Igntion maker for my home brewery. My brewery consists of 3 PLCs. Until now I have been using OPC-UA between each PLC and Ignition, and its work good. But I want to learn more about unified namespace, MQTT, ISA95, Industri4.0 etc. So, I want to transform the brewery into more industrial solutions etc.

So, as far as I understand the best (only?) way of creating a unified namespace is by using MQTT. So, should I use MQTT between the PLCs, or OPCUA? I've been testing MQTT transmission in ignition to publish all OPCUA tags to MQTT, which actually works very well. Is this a good solution? Then bind the MQTT tags to button, graphs etc in ignition?

If a professional company should make a solution for this, how would the architecture look like?

Any tips and tricks regarding this is very appreciated :slight_smile:

2

Basically what you have is already the base line for unified namespace. The PLCs will stil talk OPC-UA to Ignition and Ignition publishes the tags to MQTT. If you're using Sparkplug, you can specify different group, node, and device IDs. This is where the unified namespace comes in. If you're specifying devices with folders in Ignition already, you can leave some of this off. On most of mine, I only have group and node IDs specified, but that drives what topics the tags are pushed to on MQTT no different really than if you created folders for each PLC under the folder you're using to push the data to MQTT with in your transmitter settings.

You won't use the MQTT tags on the local Ignition project, but on say a remote project with Ignition pointing to the same MQTT broker, but using MQTT Engine instead of MQTT Transmission, you'd have a new tag provider called MQTT Engine that you pull your tags from to use on your screen.

3

Thank you, sounds good! Is it more common to use opcua over MQTT between PLC and Ignition? And MQTT is mostly used between igniton and cloud/remote?

Sounds like I should stick with OPCUA then? And publish all opc tag to the MQTT broker.

And I should use opcua for the local project instead of MQTT? I assume this is for more stability etc? So I order the OPCUA tags inn MQTT transmission folder, and bind those OPC tags to the ignition project?

I hope I got this right, and any more tips and tricks regarding this is very appreciated, thanks :grin:

4

Hi again,

I have been testing a little bit on this, and this is what I got so far:

Made a new tag provider (OPCUA_MQTT):

image
image1284×190 6.02 KB

Made a transmitter that publishes all tags from OPCUA_MQTT:

image
image1303×190 5.54 KB

I made the transmitter without specifying node id, group id etc, so that I can do that from creating folders in the tag prover:

image
image702×206 10.6 KB

So, when I change the value of "New Tag", the result looks like this while using MQTT Explorer:
image

While in node-red the result looks like this:

image
image564×602 32.8 KB

I feel like I am on to something here, or? What about the result in MQTT Explorer? Any more advice is appreciated :slight_smile:

5

This is using SparkplugB which is a more custom tailored protocol on top of MQTT which standardizes how data is sent, and how to handle loss in communications, etc. MQTT Explorer doesn't support it, and as far as I know MQTT.fx is the only test client that does at the moment. Look for v1.7.1 for the last free version if I recall. It will let you connect to the broker and specify that it's SparkplugB and you'll see the values in there as well.

Using SparkplugB, upon initial connection, the transmitter publishes all the tags, datatypes, timestamps, and initial values as part of the BIRTH message. At that point, everything is report by exception for any updates to those tags.

6

Here's another free client

and our Github has some more that might be interesting if you need to diagnose
Sparkplug B.