Calling DNP3 experts. Seeking to expand a testing lab with DNP3 representative devices.
Feedback:
Previous Feedback:
What are the most common for you? What other devices would be useful to test? Feedback on priority is welcome.
Thank you much!
Anything SEL (Schweitzer Engineering Laboratories). We currently have ~80 651 relays talking DNP3 to Ignition and a like number of RTACs. The RTAC is nearly ubiquitous in the power industry in place of PLCs used for automation in many other industries, and the relays and meters are industry standards.
We use DNP3 everywhere we possibly can, relegate Modbus to devices in the field, poll them from an RTAC, and use the DNP3 deadbands to do all our compression before data leaves the site. As such, event messages and unsolicited messaging are critical.
We have oodles of SEL devices running DNP3, including a few test lab subjects and a few to which I could likely provide internet access. More (way more) than happy to provide any assistance I can, I do feel there are some improvements I would really like to see (first two; being able to write without scripting, and being able to control event and integrity polls) in the DNP3 implementation.
PS - we have enough 3505 RTACs laying around that I could probably provide you one for testing.
You can, but maybe you’re talking about control operations and not writing?
Totally on our radar and coming in the future when we do a big round of DNP3 driver improvements. The primary operating mode of the driver will shift to class-based polling instead of point-based polling. It will be configurable for backwards compatibility.
Yes, it is the control operations, that are so simple in Modbus because there it is just writing. FWIW select-before-operate is preferred (in our and many other houses) and does definitely complicate things.
I think the only way to accommodate that would be for each of the point types used by control operations (analog and binary outputs? I think I’m missing another from memory) we could somehow allow you to pre-configure a control operation that would be invoked when a tag for that point type was written to. It’s a little goofy, and you’d have no ability to customize the parameters beyond what was pre-configured, but it might work. It would probably be opt in behavior.
The biggest problem I have with the scripting of the control operations is the script entries require the point number. This is a place where I can make mistakes, if the point number I enter in the script doesn’t match the intended target…
So, for my use if I could just reference the Ignition tag and the scripting functions got the point number from either the tag definition or the OPC server that would be a big advantage. Then I only need to get the point number right in one place, when defining the tag, and there’s much less risk of error.
If I leave the OPC server configuration blank, and set the OPCItemPath to be the full DNP address (that’s how we do it) on the Ignition tag then I can parse the point number from the OPCItemPath, but it is a bit clunky. Any way to make that simpler/smoother would go a long way.
I think we’re typing at the same time. Yes, the 3505 would work, the whole family uses the same library. As I said in the edit to my post, we can probably provide you with one. Programming software is free, or I can volunteer to do some basic programming.
One more item for this thread, because I just came up against it.
The system.dnp3 script functions include a freezeCounters method. This issues a DNP3 Immediate Freeze command.
DNP3 also has a Freeze and Reset Counters function that freezes the accumulator value and causes the RTU to reset to zero. Can that functionality be added to system.dnp3?