MQTT/IoT

[BobO]

If I were able to find a small simple implementation of EIP implicit, or even a clear spec, I might take a stab at it, but I have been unsuccessful. The PxK team licensed a stack (we have access to the same stack), but it is much heavier than I am comfortable adding. Our upcoming TLS email release was a pig to add, but was needed.

[evan]

Great information!

At first read, it seems like that is considerably more complex that we were envisioning, at least for now. Given the relatively nascent state of MQTT at the shop floor, I am very reluctant to do anything more than a very generic MQTT publish and subscribe.

We are definitely kicking around the idea of doing a data to JSON and JSON to data conversion mechanism in a future release, so I could see other data conversions happen as well. Even at that, we would probably leave the MQTT pub/sub fairly generic and push the payload definition into other instructions. As long as we give you the ability to publish and subscribe to a raw data buffer, you should be able to funnel the payload in or out of data conversion functions and get pretty much exactly what you are wanting.

In the meantime, I don't see any reason that you couldn't implement their interface with a little elbow grease. Not as convenient as what you are describing, but not overly hard either. I think a major fitness function for our MQTT implementation is going to exactly this: can I, without crazy amounts of effort, get data to and from common formats? Then over time as certain standards prove they are in fact standard, we'll look at canning those in purpose-built instructions.

I am working on a new application that uses MQTT to communicate with an Inductive Automation Ignition SCADA system.  We selected the BRX because it has MQTT.  Being naive about the details, we started working on this implementation only to realize that Ignition SCADA implementation of MQTT relied on the Sparkplug B payload specification.  I am not afraid about the elbow grease required to implement this application, but I am new to the Do-more Designer.  The only sticking part of this is how the data is packed into the payload.  Sparkplug uses Google protocol buffers or Protobufs.  I am not sure that there is any way that I can perform the same binary encoding that is required by Google Protobufs using native instructions in the Do-more Designer, but I am not completely familiar with the entire instruction set.   

I was wondering if the Sparkplug specification has been implemented or if there were any future plans for this.

As far as it being mainstream, There are now two other vendors that provide varieties of MQTT implementations that are compatible with Ignition.  - Opto22 Groov Epic and EZautomation EZRackPLC.   However, we like the BRX for the combination of features and price point.

Thanks

[BobO]

Do-more is well capable of building the binary data buffers. Not familiar with the specifics of SparkPlug, but we'll answer any questions you have about building data frames.

[Andrew S]

We are thinking that the MQTTSUB will have an optional DWORD parameter, where as a topic is updated, we'll set the corresponding bit. User can clear after he dispositions.

Did this happen and I'm missing where it is? I was about to ask for this as a feature request but now I see you've already thought about it.

I'm needing this exact feature. I have multiple subscriptions and some of them can receive the same message over and over again. Currently the only way I know that a new message has arrived is to compare it with what I saw previously, but this won't work if it's the same data. My devices can be on very low bandwidth metered lines so I don't want to add timestamps or other unique IDs to make the received packet different because they're essentially wasted bandwidth. Having a user-reset-able bit would resolve my issue.

Andrew.

[BobO]

Did this happen and I'm missing where it is? I was about to ask for this as a feature request but now I see you've already thought about it.

I'm needing this exact feature. I have multiple subscriptions and some of them can receive the same message over and over again. Currently the only way I know that a new message has arrived is to compare it with what I saw previously, but this won't work if it's the same data. My devices can be on very low bandwidth metered lines so I don't want to add timestamps or other unique IDs to make the received packet different because they're essentially wasted bandwidth. Having a user-reset-able bit would resolve my issue.

Andrew.

It was going to be harder than we hoped. Is there a value of the subscribed data that is considered invalid or out of range? If so, initialize to that and clear to that after the arrival of a new message.

[Andrew S]

I'd tried clearing the string that receives the subscribed data but I got some strange behavior. I'll post that separately because I'm seeing something else strange that might be related. I'll try setting an actual value instead of clearing the string too.

[Andrew S]

Ignore issue mentioned above about strange behavior comparing cleared strings. I think that's just an artifact of the MQTT device issue I just posted.

[ddubs2248]

Do-more is well capable of building the binary data buffers. Not familiar with the specifics of SparkPlug, but we'll answer any questions you have about building data frames.

BobO, could you work an example of building a binary data buffer that would be Sparkplug B compliant?  Or perhaps even a hint...I've read the Sparkplug B spec but its Greek to me...and I am Greek!

[BobO]

BobO, could you work an example of building a binary data buffer that would be Sparkplug B compliant?  Or perhaps even a hint...I've read the Sparkplug B spec but its Greek to me...and I am Greek!

My point was just that Do-more is capable of building any data that would be needed for any comm function, so in theory, you can implement any protocol. We haven't done anything with Sparkplug B yet, but from what I've seen from the spec, it involves publishing standardized MQTT topics that describe tags.

I'm sure that we can implement it in the PLC, but it really isn't an instruction based function. It would more likely be implemented as a pre-defined table of tags. That's doable, but it's not typical to the way we do things. We still like the idea, but we simply don't have the manpower to get everything done that we like.

[ddubs2248]

Well that is no good...currently everything we use is moving to Sparkplug B...Ignition, Canary Labs, Factory Studio.  I hate the idea of only being able to leverage modbus as the method of getting data out of PLC to something else.  We ran test with the new BRX, BX-08AD-3 analog module, over MQTT using a Mosquitto broker and MQTT.fx, and we can push an average of 180 unique readings/sec using the MQTT Pub instruction set at 0.001 ms.  That's pretty powerful!  We are about to connect the Groov Epic and perform similar testing, but I do not believe it will fair as well. 

Do you have any information on timeline of anything being implemented for the BRX line?  If it became Sparkplug B compliant it opens up world of opportunity to use these controller on multiple platforms (beyond Cmore).  AD had Think & Do (now obsolete...I know TND10 is in the works but have no idea what controllers it will connect to natively or if MQTT Sparkplug B is being considered), Point of View (obsolete).  Point of View and native drivers so that was nice, but gone.  Indusoft has native drivers, but no support for UDTs and will most likely be replaced by Aveva with Intouch HMI.  Are there any other HMI platforms that BRX (Do-More) communicates with direct drivers? 

BRX is a powerful product and people do not give it the credit it deserves, but unless native drivers are going to be developed, for other software platforms, or MQTT Sparkplug B becomes available, then it will be severely handcuffed. 

Maybe there are other options for moving this data out of the BRX that I am not aware of...if so I am all ears!  Sorry for the rant, but I love where the product is going and want to leverage it on several projects so any insight would be awesome! 

[BobO]

So Sparkplug B is becoming standard? Not just Ignition?

[ddubs2248]

Yes sir....Canary Labs just added an MQTT Sparkplug B connector.  Factory Studio has done the same.  I know the EZPLC from EZAutomation has already incorporated Sparkplug B configuration on the PLC side, as well as Opto22 Groov Epic.

I am setting up the Groov Epic now and will report back its data throughput, but its high density analog input card has a data refresh rate of 225ms...their 8CH version is 11ms...but I'd take the BRX-08AD-XX at 45ms for the price point!

[BobO]

Yes sir....Canary Labs just added an MQTT Sparkplug B connector.  Factory Studio has done the same.  I know the EZPLC from EZAutomation has already incorporated Sparkplug B configuration on the PLC side, as well as Opto22 Groov Epic.

I am setting up the Groov Epic now and will report back its data throughput, but its high density analog input card has a data refresh rate of 225ms...their 8CH version is 11ms...but I'd take the BRX-08AD-XX at 45ms for the price point!

Look at our new -3 analog...1.2ms for all 8 channels. Universal current and voltage. Internal power. Onboard filtering. And cheaper.

[ddubs2248]

Well that is no good...currently everything we use is moving to Sparkplug B...Ignition, Canary Labs, Factory Studio.  I hate the idea of only being able to leverage modbus as the method of getting data out of PLC to something else.  We ran test with the new BRX, BX-08AD-3 analog module, over MQTT using a Mosquitto broker and MQTT.fx, and we can push an average of 180 unique readings/sec using the MQTT Pub instruction set at 0.001 ms.  That's pretty powerful!  We are about to connect the Groov Epic and perform similar testing, but I do not believe it will fair as well. 

We are!...only downfall of the -3 is 15 bit resolution on typical sensor ranges of 0-5 VDC, 4-20 mA, 0-10 VDC....if it was 16 bit...BAM bees knees!

[BobO]

We are!...only downfall of the -3 is 15 bit resolution on typical sensor ranges of 0-5 VDC, 4-20 mA, 0-10 VDC....if it was 16 bit...BAM bees knees!

15 vs 16 is a deal breaker? Interesting. We've always felt like 16 bit was overkill for most industrial apps.

We're kicking Sparkplug B around. How many tags would a typical system need to support?