Strange quality behaviour on DNP3 tags after changing IPs in script

Ignition
,
1

Hey all,
While doing some testing on an IP changing script I found a strange behavior in the quality of the tags.
I had written a script that would take two IPs, main and backup, if my watchdog didn’t update the comms would fail and the script would attempt to change to backup comms.

While testing to see if it would work, I connected a DNP3 outstation to the main IP and had no device connected to backup, as I just wanted to check if it would change properly.
The device IP changed well, but when I executed the script in quick succession in the script console and the left it alone a strange pulsing of bad quality occurred after the device connected.

Essentially all of the tags on the station would flicker between good and bad quality changing maybe twice a second in quick speed, or holding on bad quality. However when I updated the tags in the PLC, the tags on my Ignition would update. I can even write to the tags in bad quality and have it update on my PLC as if the tags was good quality.

This is similar behavior we have noticed in poor quality 4G comms on some of our remote sites.

How exactly is bad quality measured in Ignition, and why is that it seems to get stuck in this loop.

Note- When checking Wire Shark the tags appear to be communicating normally, restarting the driver on device configuration doesn’t fix this issue. The PLC and outstation are wired into my server with an ethernet cable and I can replicate this result, though how long it lasts varies.

2

Are you disabling the device before changing the IP address?

3

Do you have the device configured to use unsolicited messages?

There’s really only a few reasons the values would be bad quality:

  • trial expired
  • the read request failed for some reason
  • the points came back with a negative quality flag. We often see points that have the “offline” in the device, which turns into a bad quality in Ignition

Can you share the Wireshark capture?

4

Attached is PCAP I took, the behavior really began around ID 600/700. I can’t notice any specific difference from what I would expect from a normal capture of my DNP. This is a licensed system and as I said the bad quality flickers on and off rather quickly when this occurs.

test.pcap (264.4 KB)

5

Hey,
Currently my script currently checks the comms status and simply uses system.device.setDeviceHostname(x,y) to change the IP.

Would you recommend I disable the device then change the IP?

6

Yes, and possibly also delay re-enabling by the length of your longest tag group rate.

7

Okay, that sounds like a good idea. I’ll make those changes and test.

To be honest I can’t see this issue occurring in actual use as the script will be added to gateway timer scripting. But better safe than sorry.

Thanks!