I’ve been having issues with the DNP3 device connecting to MicroLogix 1400 when the network connection between the two is broken. When the connection is resumed the device will show connected but the tag will show a bad quality until the device is disabled/enabled or just saved. This is periodically happening on both a production Ignition 7.9.13 & inhouse on my development Ignition 8.0.8.
Today I tried it with a dnp outstation simulator from freyrscada on Ignition 8.0.8 and everytime the connection is broken, Ignition will not recover and just prints the following messages repeatedly on its log, until the device is saved or reenabled.
[[id: 0x42442cd7, L:/192.168.0.164:45042 - R:/192.168.0.114:20000]] fragment timer expired
Wireshark shows the following during the down interval
This is on Ubuntu 18.04.4 & OpenJDK 1.8
Support ticket #120087 created
I am having the same problem. The device is connected, but the tag shows bad quality. I'm using Ignition Edge 7.9.20. What should be the workaround for this? Thanks in advance!
I too have been having the same issue with Edge 8.0.6 and 8.0.17. I haven't found any way to recover from this state other than to edit/save the device, bounce the DNP driver, or bounce OPC-UA. Since we only work with DNP/3 outstations, this is a debilitating bug that greatly reduces the value of this software package.
Have you tried v8.1? (I recall some DNP3 improvements in the relatively recent past.) V8.0 is end-of-life, and therefore will receive no more fixes.
Thanks for the note. I'm planning on giving 8.1 a try.
Hi.
It seems that the bug is still in version 4.1.27 of the DNP3.0 driver. I'm using Ignition 8.1.27.
The error is critical for us as we are in the process of finishing a big SCADA project for PV monitoring using DNP3.0 protocol.
Does the Ignition DNP3.0 driver only support application layer single fragment messages?
Exact same issue here. This is quite debilitating. After the fragment timer, warning, we get an exception and failed write errors, and then all tags from that device are of bad quality until a dnp3 driver restart.
We're on 7.9.17 but it sounds like this issue persists in 8.1? Hesitant about upgrading a system on an old site if the issue persists...
It's tough to diagnose this without Wireshark captures. I don't know if anybody ever tried to run this issue through support and where that went. It's never made it's way to me, whatever the case.
At this point it probably won't make much difference. There's a new DNP3 driver that is already done with development and just stuck in a QA backlog until probably after ICC. It'll go into beta after QA, then be released ASAP.
Exciting to hear there will be a new DNP3 driver! It's our go-to for SEL RTAC to Ignition, at least until SEL/Codesys updates their OPC-UA metadata implementation or we decide to take the 61850 plunge.
Any chance the new driver will allow bit-level DNP3 addressing similar to the Modbus implementation? Right now we have to pull in the register in as a counter and then break it apart into binary expression tags with getBit() which can be a performance drag.
We haven't seen the specific bug mentioned here, but we have encountered two other DNP3 oddities in the past:
- We route bitpacked registers from RTACs to Ignition as counter objects since we were getting floating point error even when the object type was an int.
- A colleague was reminding me earlier today about how Ignition's DNP3 polling is all over the map in no discernable order - they are not clean requests to inspect in wireshark like we'd have from most other DNP3 devices.
Bit level addressing isn’t planned, but I’d imagine the other issues are fixed.
The new driver uses class-based polling by default, which is a significantly different (and more correct) approach than the current driver, which does explicit polled reads like a traditional PLC driver unless you’ve opted into unsolicited messaging.
Did you manage to finishing that SCADA project. I am just starting one project conecting DNP 3 protocol with ignition SCADA and I would like to know if DNP3 works on Ignition SCADA.
Yes we've done multiple grid-scale PV plants with DNP3 pushing 100,000 tags. We had to make some changes on the fly due to problems mentioned above, and we've now completely refactored how we are connecting to and addressing our tags coming from our plant controller and other SEL RTACs. But still going strong on DNP3 on Ignition 8.1.
Hello.
Can you advise me on what I should watch out for when using DNP3 in Ignition SCADA?
I'm using the S7 1200 PLC and the CP 1243-7 communications processor.
Hi Kevin
Are you able to provide an update on the status of the new DNP3 driver you mentioned, was it released and what version?
Cheers
Thanks Kevin, do you have an idea of when this might go into LTS?
Cheers
It’ll be in an 8.1 release before the end of the year. Beta period is 6 weeks as planned.
Thanks Kevin
Have you resolved this issue? Is there a specific solution?