Ignition OPC UA Server Redundancy (Modbus TCP)

Ignition
1

modbus
modbus1479×409 64.1 KB

Like the attached file, I want to redundancy

If possible, please tell me how to do it.

2

As far as I know, Device has no redundancy.
But you can create duplicate tags and choose which set of values to use ,based on the connection state.

3

How should I do that?

can you tell me?

4

Here is a rough example. Get the device state and use it to build the real tag's path.
Using UDT will help a lot.
image
New Tag expression

image
image1252×636 52 KB

State tag
image
image1232×1130 110 KB

5

Thanks for letting me know

6

Another solution is to use 2 opc tag and a reference tag with the sourceTagPath according to the device connected.

1 Like
7

Yes, that's better.

8

I’ve submitted an idea to add support for redundant slaves to the Modbus TCP driver. If you’d like to see this supported added to Ignition, it would help if you up-voted the idea at the link below.
https://inductiveautomation.canny.io/ignition-features-and-ideas/p/modbus-tcp-driver-redundancy

9

I may just add this to my alternate modbus driver. I recently made it accept a separate hostname for Ignition redundancy. This would be similar.

2 Likes
10

It wasn't quite as easy as the last change, but relatively easy. Utterly untested, feedback welcome:

BETA for Ignition 8.1: v1.1.4.231931604

Some notes:

  • When active, the driver alternates between the live connections on a per-batch basis. For this driver, a "batch" is a memory area subset of a single system.opc.readValues() request, system.opc.writeValues() request, or subscription poll. (Coils with coils, discrete inputs with discretes, et cetera.) This is effectively load-balancing between the connections, though not deliberately so. (Batch sizes vary and are not considered in the toggling.)

  • When a single connection breakage occurs, the batches that were queued to the now-broken connection will fail. For subscriptions, bad quality will appear for one subscription cycle. Non-subscription reads and any writes should be monitored for error results and retried.

  • Only available for Modbus TCP, not any form of RTU.

  • Device status will include "Degraded" or "Recovering" if the two connection states differ.

I probably won't have a chance to properly test this until next week. I thought y'all might like this preview.

1 Like
11

Thanks very much - I’ll give it a test in the next day or so and let you know how I go

12

I just wanted to say that this works really well - thanks for making that a reality!

There was probably only 1 additional feature I found myself wanting whilst using this - and that was gateway device tags that showed the individual status of the 2 connections. This would allow people to diagnose which device was down during troubleshooting - and could even be shown on a diagnostic perspective page to help the operator when raising a support request.

To complete the complement sandwich :grin: - it was great that the main device "status" tag still included the work Connected before the rest of the status, since that is often used to test the health of the connection within scripts.

13

Actually, I think I may have found a bug when used with bit-level addressing and Modbus mask-write. Not sure if its new with this redundant BETA version or pre-existing.

My test setup (both the modbus server and client are using your advanced modbus driver):

  • Modbus Server listening on 0.0.0.0
  • Modbus Advanced Client connecting to 127.0.0.1 and 127.0.0.2

Setup a boolean OPC tag which uses the Modbus advanced client device.

Using this address works: ns=1;s=[client]1.C1
Using this address works intermittently: ns=1;s=[client]1.HR1.0

The failure mode is that the first time the tag is set to true, it seems to work. But then when trying to set it back to false, and on subsequent writes, it seems to fail for about 10 seconds or so before then working. Watching the loopback interface traffic in Wireshark, it looks like the modbus mask write commands are not being sent at all to any address until the 10 seconds has passed.

14

Hmm. Will investigate.

15

Hi @pturmel,

Not sure if you ever found/fixed the issue that was causing bit-level addressing to intermittently fault when I tested in July... but I tested it again today with the Advanced Client v1.1.6.241441839 and it seemed to be working fine.

That said, I was testing against a different modbus server this time (not the server in your module).

16

I did not.