Reset OPC UA Client Connection Programmatically

Hello all,

We have an OPC UA Client Connection to a PLC that hosts its own OPC UA server as a more efficient method of communication than using Ignition's built-in drivers. There are situations in which the server goes down and comes back up i.e. is temporarily disconnected. When the connection is faulted/disconnected, we have overlays on every related indicator in the HMI (Vision).

When the server spins back up, the connection is re-established automatically and the indicators that are driven by the PLC (i.e. the ones that are continuously updating) return to normal appearance with the overlays being removed.

Issue: Indicators that do not get continuously updated do not get refreshed/do not have their overlays removed. These indicators have changes that are either intermittent or driven by operator action. Operators will not interact with these values because they appear to have no communication. If I go into the Gateway Webpage > OPC Connections > Edit and toggled "Enabled" off and then on again, all indicators refresh and appear functional.

On various occasions, the persistence of overlays after communication has been restored has been confusing to operators. It is not optimal for an Ignition administrator to manually reset the connection when this occurs (separate from figuring out how to reduce intermittency on the PLC side). Is there some way to auto-refresh all tags upon re-established connection or to otherwise programmatically refresh connection status?

Thanks,

Chris

How are you controlling this? Ignition's leased tag functionality would fix this for anything displayed in a UI. If you've rolled your own "pseudo-lease" functionality, you will have to retrigger that stuff yourself.

Please elaborate.

What I mean is that the data is not changing value. I can only speculate that this is why the bad quality overlay remains. These are things like setpoints that remain at the same value until they change (as opposed to analog signals that always have some noise to keep them updating). This isn't an issue during continuous operation but specifically after the connection is re-initialized.

Compare the settings for the tags that recover properly with the settings for the tags that do not. If they are coming from the same PLC, they should be recovering the same, too, unless configured differently.

(It is possibly also a bug in that OPC server.)

Good thought. First, most obvious difference is that the tags that do not recover properly are Direct tags while the ones that do are Expression tags. No other settings (Deadband, Deaband Mode, Sample Mode, Rate) are different.

Derived*

Hmm. I suspect you will need to get support involved. (Psst. The pencil icon in a post's extra operations will let you edit something already posted.)

Thanks! And thanks for letting me know of that, too.

A post was split to a new topic: Programmatically enable/disable device connection