OI-Gateway RDC: Monitor Active Device and Force Failover

Operators can use OI-Gateway Redundant Device Connection (RDC) attributes to see the active and standby devices and issue a forced failover; a GOOD ping quality alone does not prove the active PLC is controlling the process.

Does GOOD ping quality confirm the active PLC is healthy?

No. RDC uses the ping item to monitor connection quality, but that quality can remain GOOD after a PLC faults and the standby device takes control. Treat ping quality as a communications indication, not an application-level active/standby handshake.

Trace the symptom from the screen toward the controller:

1. Read the RDC ping item quality. If it is not GOOD, investigate the connection path and continue checking RDC status attributes. If it is GOOD, continue; do not conclude that the PLC is active.
2. Read the end-device seconds-clock handshake value and confirm that it changes continuously. If it changes, the observed device is responding to the handshake; if it stops changing while quality remains GOOD, the connection can be live while the PLC is faulted or no longer providing changing application data.
3. Compare the RDC active and standby device attributes with the controller's own active/standby state. If they disagree, the ping is not sufficient to select the controller that owns control; use the status and command attributes to manage selection.

Which RDC attributes expose device selection?

Create attributes in the DIObject used by the OPCClient or SuiteLinkClient, then bind I/O attributes to the corresponding RDC items. Example attribute names and bindings are shown below; use the exact item names configured in the installation.

Example I/O attribute bindings include RDC.Active.Device.InputSource for the active-device item and corresponding RDC.StandbyDevice.InputSource and RDC.ForceFailover.InputSource bindings. Check each I/O attribute's InputSource and confirm it resolves to the intended topic.RDC.ItemName. An incorrect or unresolved binding is a tag-path problem; a correctly resolved item with an unexpected active device is an RDC selection or controller-state problem.

Does a changing handshake distinguish a tag fault from a PLC fault?

Use the handshake value as an application-level liveness check. The recommended pattern described here monitors a seconds clock from every end device, checks both its value and quality, and detects whether the value continues to change. A GOOD quality with a frozen value is different from an invalid or bad-quality tag: the former can indicate that communications remain available while the PLC has faulted or stopped updating the handshake; the latter points first to the item path, driver, or communications quality.

Check the value at the controller and at the bound I/O attribute. If the controller's clock changes but the I/O attribute does not, inspect the tag binding and driver path. If both are frozen while the ping remains GOOD, investigate the controller's operating state and use RDC status to determine which device is active. Configure the failover decision around the handshake failure rather than ping quality alone.

When should code force failover or failback?

Use RDC.ForceFailover when the health logic determines that the active device is not providing the expected changing handshake, even if ping quality remains GOOD. RDC attributes can also support monitoring and selection logic based on active and standby status.

Failback is a separate decision. RDC does not necessarily return to the primary merely because the primary's ping item becomes GOOD while the backup remains active. For devices whose controller logic automatically makes the primary active when available, implement an explicit failback condition and verify it against the controller's active/standby state. Do not equate recovered ping quality with ownership of control.

How do you configure and verify the resolving branch?

1. Create DIObject attributes for the RDC status and command items required by the application, including active device, standby device, and force failover.
2. Bind each I/O attribute to the corresponding topic.RDC.ItemName and verify the resolved value for each item before relying on it in control logic.
3. Monitor the seconds-clock handshake and its quality for every end device. Confirm that the value changes during normal operation; use a stopped value with GOOD ping quality as a failover diagnostic condition.
4. When the health condition calls for a transfer, issue the force-failover command and read back the active and standby device attributes. Confirm that RDC reports the intended active device and that the controller handshake from that device continues changing.
5. If the application requires the primary to resume control, execute the explicit failback logic only when the controller state supports it; verify the active-device attribute and changing handshake again.

Verify the final active-device attribute matches the intended controller and its seconds-clock handshake continues to change.

What happens if the ping remains GOOD after a PLC fault?