News:

  • October 20, 2026, 03:25:54 AM

Login with username, password and session length

Author Topic: MQTT/IoT  (Read 60656 times)

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3628
  • Darth Ladder
Re: MQTT/IoT
« Reply #30 on: June 04, 2020, 03:59:09 PM »
You want 16-bit at 800Hz??   That's not a PLC, that's data acquisition.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

ddubs2248

  • Sr. Member
  • ****
  • Posts: 64
Re: MQTT/IoT
« Reply #31 on: June 04, 2020, 04:00:39 PM »
I would not say deal breaker, but we deal with systems with 30,000 to 60,000 psi transducers, so detectable changes better than 1 psi/bit are sometimes necessary. 

Do you think 500 tags is doable (at least to start)?  I would assume there are several others out there that could chime in on this!

ddubs2248

  • Sr. Member
  • ****
  • Posts: 64
Re: MQTT/IoT
« Reply #32 on: June 04, 2020, 04:01:54 PM »
You want 16-bit at 800Hz??   That's not a PLC, that's data acquisition.

I know right!!!  Why not have both in the BRX platform?? Heck up the price a little!  And we typically only need 10Hz, but I was just testing the bandwidth on the new analog input card!
« Last Edit: June 04, 2020, 04:03:38 PM by ddubs2248 »

ddubs2248

  • Sr. Member
  • ****
  • Posts: 64
Re: MQTT/IoT
« Reply #33 on: June 04, 2020, 04:22:15 PM »
Just finished the Groov Epic test...and in fairness the data refresh rate for the card is best case 225ms (4.44 S/s)...they do offer another one that is 11 ms

So the results:

Groov Epic PR1, set to scan the controller at 1 ms, using the GRV-IV-24 analog input voltage card (0-5 VDC input): sampled for 40 seconds and received 85 unique values, or 2.125 S/s

To compare,

BRX Do-More, set to publish at 1 ms on changed value, using the BX-08AD-3 analog input voltage card (0-5 VDC input): sampled for 10 seconds and we received 1,827 unique values, or 182.7 S/s

The BRX is powerful!

So how fast can we get Sparkplug B implemented??  :)

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6177
  • Yes Pinky, Do-more will control the world!
Re: MQTT/IoT
« Reply #34 on: June 04, 2020, 06:10:51 PM »
Just finished the Groov Epic test...and in fairness the data refresh rate for the card is best case 225ms (4.44 S/s)...they do offer another one that is 11 ms

So the results:

Groov Epic PR1, set to scan the controller at 1 ms, using the GRV-IV-24 analog input voltage card (0-5 VDC input): sampled for 40 seconds and received 85 unique values, or 2.125 S/s

To compare,

BRX Do-More, set to publish at 1 ms on changed value, using the BX-08AD-3 analog input voltage card (0-5 VDC input): sampled for 10 seconds and we received 1,827 unique values, or 182.7 S/s

The BRX is powerful!

So how fast can we get Sparkplug B implemented??  :)

What? You don't like paying far more and getting much less? Weird.

I'm gonna investigate Sparkplug. I'll let you know.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

ddubs2248

  • Sr. Member
  • ****
  • Posts: 64
Re: MQTT/IoT
« Reply #35 on: June 05, 2020, 10:43:53 AM »
One more update

BRX Do-More, set to publish at 1 ms on changed value, using the BX-08AD-2B analog input voltage card (0-5 VDC input): sampled for 10 seconds and we received 501 unique values, or 50.1 S/s (all 8 Channels Active)

BRX Do-More, set to publish at 1 ms on changed value, using the BX-08AD-2B analog input voltage card (0-5 VDC input): sampled for 10 seconds and we received 555 unique values, or 55.5 S/s (1 Channel Active)

Just thought I would provide some more information for those interested! 

So what is the over/under on having Sparkplug B implemented by the end of Q2 2020??  (It just sounds better that way....like you have more time!)  ;)

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6177
  • Yes Pinky, Do-more will control the world!
Re: MQTT/IoT
« Reply #36 on: June 05, 2020, 11:00:01 AM »
So what is the over/under on having Sparkplug B implemented by the end of Q2 2020??  (It just sounds better that way....like you have more time!)  ;)

0%

Q2 ends in 3 weeks. The next scheduled release is early Q4.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6177
  • Yes Pinky, Do-more will control the world!
Re: MQTT/IoT
« Reply #37 on: June 05, 2020, 01:44:57 PM »
Trying to envision how Sparkplug could be configured from DmD. As of now, I am trending toward it having a SysConfig based driver config, which would be a subset of MQTT, plus additional fields. The tags themselves are more problematic, but, I think we could add a flag to documentation records indicating that that tag should be exposed via Sparkplug. From the user's perspective, it would just be an additional column in the DocView with a checkbox to expose the tag. Maybe. Until I change my mind.

The potential performance hit is significant; scanning and updating 100s of tags every scan could really dog the scan. So I'm thinking of tuning that with two parameters: 1) minimum time between updates, and 2) maximum tags updated per scan. If you care about maximum update rate, but don't care what the scantime hit is, you'd set #1 to 0 and #2 to 'All'. If there are lots of tags and they are all changing constantly, that might create a big scan hit, but for certain apps it doesn't matter. If tight scans are your thing, you could increase #1 and/or reduce #2 to just a few tags per scan. It might take a second or more to get through a long tag list, but the scan hit would be imperceptible, and for SCADA, 1 second updates may be plenty good.

This could happen.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

ddubs2248

  • Sr. Member
  • ****
  • Posts: 64
Re: MQTT/IoT
« Reply #38 on: June 09, 2020, 03:08:18 PM »
BobO,

Agree with the system config and documentation flag approach.  Some other things to consider or think about ahead of time:

  •   Ability to create multiple NodeID's
  •   Ability to categorize or include a "tag" to a specific NodeID

As far as scanning...are you thinking this is an either/or option or would you have the ability to have the ability to create a scan class and configure your "tags" to those parameters?  Definitely curious about expanding on this to see what is possible and also realistic.

For a frame of reference, there are times where we would push out maybe 10 "tags" at 10Hz (100 ms).  This could also be faster if the option exists.  Almost everything else could be configured/published at a much slower rate (250 - 1000 ms).  I understand you have to build this for the masses, but just wanted to give some additional data...so hopefully it is useful.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6177
  • Yes Pinky, Do-more will control the world!
Re: MQTT/IoT
« Reply #39 on: June 09, 2020, 03:20:19 PM »
BobO,

Agree with the system config and documentation flag approach.  Some other things to consider or think about ahead of time:

  •   Ability to create multiple NodeID's
  •   Ability to categorize or include a "tag" to a specific NodeID

As far as scanning...are you thinking this is an either/or option or would you have the ability to have the ability to create a scan class and configure your "tags" to those parameters?  Definitely curious about expanding on this to see what is possible and also realistic.

For a frame of reference, there are times where we would push out maybe 10 "tags" at 10Hz (100 ms).  This could also be faster if the option exists.  Almost everything else could be configured/published at a much slower rate (250 - 1000 ms).  I understand you have to build this for the masses, but just wanted to give some additional data...so hopefully it is useful.

At this point Sparkplug B is still pretty niche, and I am very resource constrained. If this happens, it needs to happen in the easiest way. That will be true at both the config and driver implementation level. If I were confident that it was the protocol to end all protocols, I might be able to justify more, but so far that doesn't appear to be the case. I like the idea, though, because I think it has the potential to be more widely supported and it should be pretty easy to develop.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

ddubs2248

  • Sr. Member
  • ****
  • Posts: 64
Re: MQTT/IoT
« Reply #40 on: June 09, 2020, 03:27:25 PM »
BobO,

Completely understood and just having the ability would be enough...hopefully it shakes out!  Just throwing a few nice to haves out there, in the beginning, so it could be known ahead of time   :D

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6177
  • Yes Pinky, Do-more will control the world!
Re: MQTT/IoT
« Reply #41 on: June 09, 2020, 03:29:36 PM »
BobO,

Completely understood and just having the ability would be enough...hopefully it shakes out!  Just throwing a few nice to haves out there, in the beginning, so it could be known ahead of time   :D

I do appreciate the feedback. Just want to set expectations.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

ddubs2248

  • Sr. Member
  • ****
  • Posts: 64
Re: MQTT/IoT
« Reply #42 on: January 28, 2021, 07:21:23 PM »
Well how is progress coming?  It would still be awesome to leverage an MQTT setup table that would allow us to check yes/no for our tags to publish/subscribe.  Happy 2021 by the way HOST!