New DNP3 Driver Beta

Ignition Early Access
101

Is there any consideration for adding connection redundancy for this and other drivers? (I ask about this one since we rely heavily on it and it's one of the newest).

It would be great to have a way to target two DNP3 outstations representing a primary/backup or an A/B in a failover scheme.

Otherwise it looks like the best approach is to build some scripting that tests conditions on multiple DNP3 outstations and swaps all UDT instance opc_dnp3DeviceName string parameters based on certain conditions which would then remap all OPC Item Paths from one device to another.

102

You can make a feature request at https://ideas.inductiveautomation.com/, but no, there's not currently any plans to do redundancy for any of the drivers.

(there's actually product managers looking at the ideas portal now, rather than a random group of us looking out of curiosity or in the ramp up to ICC)

1 Like
103

When I search "DNP3" on the ideas portal, I see many suggestions/requests which appear to be fulfilled by your new DNP3 driver.

Late Friday afternoons are great for (cracking open a beer optional) finding a pile of tickets for work you've already done and closing them out. :wink:

104

Would system.device.setDeviceHostname work on this driver, from the looks of it, it should. If so, IMO it would be the easist solution to implement.

105

The problem with setDeviceHostname is I believe it only works on the primary server in a redundant setup (I actually wrote a UDT that just pings 2 IPs and switches a device to the other if one goes down). I believe in a redundant setup, changes aren't allowed on the backup server even if it's active, so even that won't work. (Again, I could be wrong, but I haven't tested it myself)

1 Like