News:

  • March 29, 2024, 01:47:33 AM

Login with username, password and session length

Author Topic: DNP3  (Read 7899 times)

ryanastiefes

  • Sr. Member
  • ****
  • Posts: 55
DNP3
« on: November 18, 2015, 02:29:19 AM »
Any thoughts on implementating the DNP3 protocol? 

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Re: DNP3
« Reply #1 on: November 18, 2015, 08:23:30 AM »
I'm not familiar with it, but just scanned some info. The messaging seems pretty straightforward, and apparently there are subsets of the RTU protocol suitable for embedded systems. We don't have any current plans to support it, but at first read, I'd say Do-more could handle it fine as a custom protocol.
"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

henke

  • Full Member
  • ***
  • Posts: 21
Re: DNP3
« Reply #2 on: April 19, 2017, 10:22:28 PM »
I'm not familiar with it, but just scanned some info. The messaging seems pretty straightforward, and apparently there are subsets of the RTU protocol suitable for embedded systems. We don't have any current plans to support it, but at first read, I'd say Do-more could handle it fine as a custom protocol.

It would be excellent to see DNP3 via Ethernet implemented as an officially sanctioned, supported and documented protocol. This feature is becoming absolutely necessary in both Water Treatment and Energy Distribution industries.
Where's my kitty?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Re: DNP3
« Reply #3 on: April 20, 2017, 09:19:59 AM »
The next significant bit of development will be to develop expansion modules for BRX, but after that we would like to spend some time doing comm protocols.
"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

mhulbert

  • Newbie
  • *
  • Posts: 1
Re: DNP3
« Reply #4 on: May 03, 2017, 08:30:23 PM »
Can I jump on the band-wagon for DNP3 as well? It's like the Modbus of the Electric Utility/Generation world.

Would also like to see native support of SDI-12. Very common for Geo-science type instruments (typically low power/low rate stuff like water well monitors, etc). This could probably easily be a custom protocol but having it as a supported things would be best.
Thanks!

b_carlton

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 606
    • thePLCguy
Re: DNP3
« Reply #5 on: May 04, 2017, 01:26:17 PM »
In homage to the POM Port how about Plug In Protocols (PIPs) if the code space would get a little crowded with a bunch of specialty protocols. Each bringing the firmware support, specialized heap structures and instructions. Some might have do be associated with specialty add-on modules if the protocol requires such hardware. Possibly a profit center if needed.
« Last Edit: May 04, 2017, 01:28:04 PM by b_carlton »
An output is a PLC's way of getting its inputs to change.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Re: DNP3
« Reply #6 on: May 04, 2017, 02:01:25 PM »
In homage to the POM Port how about Plug In Protocols (PIPs) if the code space would get a little crowded with a bunch of specialty protocols. Each bringing the firmware support, specialized heap structures and instructions. Some might have do be associated with specialty add-on modules if the protocol requires such hardware. Possibly a profit center if needed.

I like the idea. Implementation is hard.

In a system with an OS that supports dynamic linking, this is easy. In a PLC built on bare metal, not so easy.

If there is enough business to justify a module-based implementation, that's a fairly easy answer, however we are still very far away from the point in BRX development where we can justify the time to develop narrowly focused specialty modules. To further complicate the decision, unless ADC specifically requests it due to them feeling like there is a large enough market to justify it, Host is just rolling the dice if we develop such modules.

Another less obvious aspect is that if you sell an expansion module there is an expectation of a more complete implementation, which can be deceptively time consuming. A minimalist implementation as a built-in protocol is often good enough, and requires far less work overall.

The POM port does give us nice options for slave side protocols. Turning the ECOMLT hardware into simple slave protocol converters might be a nice middle ground. The hardware cost is low enough that minimalist implementations wouldn't be bad, and I would think most customers would be willing to spend $69 to add a protocol they needed.

That doesn't answer master side protocols though. That's a much bigger problem, and will likely remain the domain of full expansion modules and robust markets...as time permits.
"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: 5975
  • Yes Pinky, Do-more will control the world!
Re: DNP3
« Reply #7 on: May 04, 2017, 02:02:47 PM »
For DNP3 specifically...are y'all wanting master or slave side?
"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

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3553
  • Darth Ladder
Re: DNP3
« Reply #8 on: May 04, 2017, 02:50:58 PM »
however we are still very far away from the point in BRX development where we can justify the time to develop narrowly focused specialty modules.

Agree -- analog, high density discrete, and native remote I/O are all more urgent.

Quote
The POM port does give us nice options for slave side protocols. Turning the ECOMLT hardware into simple slave protocol converters might be a nice middle ground. The hardware cost is low enough that minimalist implementations wouldn't be bad, and I would think most customers would be willing to spend $69 to add a protocol they needed.

I'd think the protocolified POMs could (and should) sell for more than hardware-only versions.  Maybe $169 or so, at least.  For $100 (assuming a one-off app) people get to avoid writing a protocol.  Prosoft used to sell Modbus modules for the SLC for $1300.  I think the current version is $2K.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Re: DNP3
« Reply #9 on: May 04, 2017, 03:16:04 PM »
Agree -- analog, high density discrete, and native remote I/O are all more urgent.

Analog is going well. We had some bumps in the road, but I think we cleared them this week.

I know the BRX EBC is coming along nicely, as is 32 point I/O. No specific launch date on those yet, but they aren't hard things to finish. Once the analog launch is past engineering dependencies and BRX production has settled into a nice rhythm, we'll get those launched.
"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

Garyhlucas

  • Hero Member
  • *****
  • Posts: 398
Re: DNP3
« Reply #10 on: May 04, 2017, 10:37:03 PM »
Glad to hear analog is moving along. Our product is starting to get lots of attention and I'd love to move us over to the BRX soon. We need 16 4-20 inputs.

henke

  • Full Member
  • ***
  • Posts: 21
Re: DNP3
« Reply #11 on: January 30, 2018, 02:05:06 AM »
Can I jump on the band-wagon for DNP3 as well? It's like the Modbus of the Electric Utility/Generation world. Would also like to see native support of SDI-12. Very common for Geo-science type instruments (typically low power/low rate stuff like water well monitors, etc). This could probably easily be a custom protocol but having it as a supported things would be best.
Thanks!
I'm not familiar with it, but just scanned some info. The messaging seems pretty straightforward, and apparently there are subsets of the RTU protocol suitable for embedded systems. We don't have any current plans to support it, but at first read, I'd say Do-more could handle it fine as a custom protocol.
For DNP3 specifically...are y'all wanting master or slave side?
Code: [Select]
DNP3 uses the term outstation to denote remote computers as are found in the field. from https://www.dnp.org/pages/aboutdefault.aspx

DNP3 has been adopted widely by power companies and water utilities where radios are relied on. Basically, it provides a buffer or backlog of data that updates the master station (SCADA) once comms are re-established. So the answer to the master or slave side question is really only slave, for which the protocol designers use the term "outstation". It's pretty exciting to think that Do-more could handle it fine ... even if it wasn't on the POM of the BRX initially. It would be great to see on the H2-DM1E and the T1H-EBC100 as well. And I have to agree with hulbert about SDI-12 support for serial as well.

Where's my kitty?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Re: DNP3
« Reply #12 on: January 30, 2018, 09:32:29 AM »
DNP3 is definitely going to get a look. Not sure on form factor, but my expectation is standalone in an ECOM variant.

SDI-12 seems like it would take custom hardware. The protocol sounds easy enough. Since it requires custom hardware (with the 12V and single data line) it would make sense to put it into a variant of a SERIO, but since it is a multi-sensor bus, it sounds like overkill to have 3 or 4 ports on the module. Gotta think about that.
"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

henke

  • Full Member
  • ***
  • Posts: 21
Re: DNP3
« Reply #13 on: January 31, 2018, 02:25:14 AM »
DNP3 is definitely going to get a look. Not sure on form factor, but my expectation is standalone in an ECOM variant.

SDI-12 seems like it would take custom hardware. The protocol sounds easy enough. Since it requires custom hardware (with the 12V and single data line) it would make sense to put it into a variant of a SERIO, but since it is a multi-sensor bus, it sounds like overkill to have 3 or 4 ports on the module. Gotta think about that.

Great news BobO, very encouraging to hear that there could be an ECOM variant for DNP3. The D2 group of products is mature (in a good way) and therefore a solid candidate.  There's a fleet of "SCADAPacks" out there that Schneider seems to want to deprecate while having customers move to M580. The BMXNOR0200H product they have for the M340 line sounds similar to what an ECOM variant would be ... their combined market share seems worthy of a competitor. Would love to know actual stats on market share but I'm sure they are available somewhere.

SERIO-SDI12 with one port sounds like a great potential product as well!
Where's my kitty?

henke

  • Full Member
  • ***
  • Posts: 21
Re: DNP3
« Reply #14 on: January 31, 2018, 02:37:36 AM »
Interesting that the group behind the WITS DNP3 variant has decided to try to broaden their appeal by a renaming to “Worldwide Industrial Telemetry Standard”.
  http://www.witsprotocol.org/2018/01/
Where's my kitty?