• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 7 subscribers
  • Views 96 views
  • Users 0 members are here
Options
Related

Control “REDUNDANT DEVICE Connection” in OI-Gateway with code?

Ulrik Asp

Hi,
It’s my understanding that the “REDUNDANT DEVICE Connection” in OI-Gateway does look at the quality of the ping item to make selection of which device to connect with.
If the devices have internal logic that sets one device to active and the other to standby, there is a need for controlling the selection with code. I haven’t found anything that says this is possible today.
I think it is a very useful feature to add to the functionality, like a selection to enable this in the configuration combined with a system item where you can write which device to use (primary or secondary).
Is there plans to implement something like this?

Best regards
Ulrik

  • 0

    Ulrik, this is absolutely available.  The Redundant Device Connection (RDC) has several readable attributes that can be monitored for status and a command that can be issued to force a failover.  You can create attributes in your DIObject (OPCClient or SuiteLinkClient) to monitor these attributes.  Example DIObject Attribute names: RDC.ActiveDevice, RDC.StandbyDevice, RDC.ForceFailover, etc. (there are a lot).  You can then set the I/O attributes to a topic.RDC.ItemName.  Example:  RDC.Active.Device.InputSource = Me.Fast.RDC.$Sys$ActiveDevice, RDC.StandbyDevice.InputSource = Me.Fast.RDC.$Sys$StandbyDevice, RDC.ForceFailover.InputSource = Me.Fast.RDC.$Sys$ForceFailover.  You can then monitor which OIServer the RDC is using as its active device.  You can force a failover at any time.  Although we do use the Ping item, it only monitors the Quality.  Note that the Quality can remain GOOD even if the PLC is faulted and the standby has taken control.  Because of this, we add a handshake with the seconds clock of every end device.  That way we can monitor its Quality and ensure we are seeing a constantly changing value.  We use this to force a failover if the Quality is GOOD but the handshake fails.  We also force a failback to the primary on certain devices where the primary always takes control when it is available.  The RDC will not track back to the primary if it takes over but the Active Device (which would be the backup at that time) still shows the Ping Item with GOOD quality.

  • 0 in reply to Lonnie Purvis

    Thank you Lonnie :-)

    This is what I'm looking for, I'll try this.

© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.