Hi All,
I was reviewing the thread “DNP3 Event buffer backfill” and couldn’t figure out what state Ignition’s support for DNP3 events is in as of v8.0. If I lose connectivity to some number of my DNP3 outstations and they buffer, say, 40k events each with timestamps, will all of the data find its way into my historian on re-connection?
I saw Kevin saying “Yes, and that’s how we intend to support DNP3 event buffering. I think alarm and history systems still need some small changes to accommodate the arrival of this bulk data, though” in the other thread, but wasn’t sure where this got up to.
Cheers,
Ben
1 Like
We did some work on this in 8.0.13.
All your tags from DNP3 tags need to be in a dedicated tag group with the Queue Size OPC UA property set to something large enough to accommodate the number of events the device might buffer per tag. (so… don’t set this to 40k, set this to 40k divided by the number of points or something like that. Hopefully that’s a much smaller number than 40k).
When Ignition’s driver reconnects it should receive the events from the device and they’ll end up arriving in bulk at the OPC UA client side. From that point they should all move through the history system as you’d expect.
2 Likes
Ah, fantastic, thanks mate! Sounds like I’ve come across Ignition at just the right time for what I need to make happen on my sites.
Just to round out the discussion, do you think you could run me through what’s currently missing from the ignition DNP3 driver so that I can plan around it? I saw somebody mention that if your device only supports connection on a single port, there can be some issues with maintaining a warm Ignition gateway - ring any bells?
Cheers
1 Like
I think there may have been an issue where the DNP3 driver on the backup in a redundant pair would also make a connection but that should be fixed now.
Other limitations people have run into… it’s DNP3 over TCP/IP only, no secure auth, no dual endpoint or reverse connect or whatever you might know it as.
It also works best when the remote device supports unsolicited reporting. The polling strategy the driver currently uses (i.e. when you’re not using unsolicited mode) is… um, different that what is intended by DNP3. It uses the Read function to read points directly rather than doing periodic class 1/2/3 polls. Devices with lower conformance levels seem to have problems with this.
I’m hoping in the future we can come back to the DNP3 driver and spend some time fixing these things.
1 Like
Ah right, so when Ignition is actively polling, it’s doing something closer to what the modbus driver would be doing and just reading the value? Fortunately, my device supports sending unsolicited messages. Do I need to disable/enable anything or change anything else in the Tag Group to take advantage of that or will Ignition just end up receiving all of the unsolicited stuff plus whatever it actively polls for as long as I have unsolicited enabled at the outstation + a queue size of more than 1 event? Should the publishing interval be set to anything specific (defaults to -1)?
You don’t need to change anything else in the tag groups. Unsolicited messaging is configured on the device instance and is just a checkbox you need to enable.
Sorry to open this one again!
Up until now I’ve been using SQL Bridge Historical Groups to store data rather than the standard tag history feature. The reason I’ve been doing this is because I need my data stored in named tables rather than in the time series DB format used by Ignition (even though it’s a bit slower to do it my way).
If I set up my DNP3 tags to be in a tag group with an appropriate Queue Size, then add them to a Historical Group with a timer of 1 second, “Only evaluate when tags change” to true, OPC Data mode to subscribe and “Bypass store and forward” to false, can I expect my buffered tags to end up in the database after communications are re-established?
Cheers
Unless it has been added in the past month or so, No. Not for SQL Bridge.
The documentation for the SQL Bridge suggests that events are received asynchronously and that events received before the next execution will be used at the time of the next execution. Kevin described buffering as being introduced recently, so it sounds like the transaction group would receive multiple events if a queue of buffered data was received. I guess it would come down to whether the Transaction Group can handle inserting multiple lines at a time based on the timestamps of data received or if it just selects the latest values and inserts one line. Buffering being added recently makes me hopeful that it’s either been addressed already or that it’s not too challenging to add in.
It would be good to hear whether IA have already solved this problem or whether it’s something that could be added in while the buffering changes are still fresh in everyone’s minds! 
A post was split to a new topic: DNP3 Unsolicited Events Error