OPC server shows "No data available" or "Not connected"

Hi,

I am running an Ignition 7.2.5 server connected to a single AB ControlLogix PLC.
After running fine for a few weeks, the OPC server recently stopped working, showing “No data available” or “Not connected” for the tags it is reading off the PLC.

I reason it is an OPC server problem because the PLC is still operating. Also, if I restart the OPC-UA module from the Ignition Gateway webpage, the problem is resolved.

This most recent incident has happened around the same time as a power interruption. The server that Ignition is running on is on UPS, but not the PLC, so that may have gone offline. I have a 60s timeout alarm set for a 30s heartbeat signal coming from the PLC and looking back through the records, it seems like it has also triggered several times over the past month, most of those times coming back online within a minute or two. This suggests that there may have been several power interruptions, however the OPC connection has remained working after those other events.

I had assumed that the OPC connection to the PLC would simply be re-established when it comes back online after a power interruption. Is it possible that the Ignition OPC-UA server will not be able to manage it if this happens too frequently?

If not, what else might cause this problem?


It may be related to a bug in the driver reconnection present in 7.2.5. Is there any chance you could call into support if it happens again?

Otherwise, the latest beta version of 7.2.6 contains a fix for this. Not quite sure on a non-beta release date yet.

This problem has occurred again two days ago and unfortunately it was not possible to call in at the time. The OPC module has already been reset. Are there any logs or messages that I can look at to find out more about what caused it?

Also, can we have an estimate on when 7.2.6 will be released? This is a production system so we really need to give our client a timeframe for when we can patch this, assuming it is the Allen-Bradley driver issue.

[quote=“czliaw”]This problem has occurred again two days ago and unfortunately it was not possible to call in at the time. The OPC module has already been reset. Are there any logs or messages that I can look at to find out more about what caused it?

Also, can we have an estimate on when 7.2.6 will be released? This is a production system so we really need to give our client a timeframe for when we can patch this, assuming it is the Allen-Bradley driver issue.[/quote]

7.2.6 was released today and was heavily tested for things like network service/power dropouts and subsequent reconnections. Please, give this a try and let us know if it solves your problems.

Sorry to throw this on the pile but have just experienced this issue on OPC-UA 9.1.16 and am curious what method could be used to restart the server when tag values go bad.

The event occurred after a transient network interruption and the server connection needed to be reset manually (OPC UA Server - edit/save), performed as advised.

You can toggle it off and on with system.opc.setServerEnabled, but you should really figure out why it’s not reconnecting or recovering on its own.

Is it a third party server?

We are using the Ignition OPC-UA server (primary functions) along with Kepware for Open Protocol purposes (secondary not affected).

This event has never occurred before but production was taken down, where we would like to find a solution to help the system automatically recover should this happen again.

There was an “outside” network service provider connection damaged, which interrupted the plant operations.

There’s not much troubleshooting that can be done after the fact, but if you can reproduce it or it happens again it would be useful to call support before you reset it.

I appreciate the response with the information provided.

Thanks

Consider having your IT department deliberately break comms for a few minutes in the same fashion at a time convenient to production. Run wireshark to capture it all, including any failure to reconnect. Restart the connection to complete the test with minimal downtime.