Hello.
The short answer is: You do not have to do anything - the component takes care of it.
The detailed answer is:
In OPC Data Access 1.0 and 2.0, this is achieved by calling the OPC function IOPCServer::GetStatus. In OPC Data Access 3.0 (only supported by some servers), there is also a KeepAlive functionality: The server must report back to the client (by a callback) in certain time, periodically. In addition, the "dead" connection can also be detected when certain system-level errors are returned from other calls to the OPC server. Our component uses all available methods to check that the connection is live. For example, we call IOPCServer::GetStatus periodically (each 15 seconds by default), and verify that both the function has properly reached the server and returned, but also that the server (if reachable) itself is not reporting problems in the output arguments of that function.
If a problem is detected, the component disconnects from the OPC server.
After a server is disconnected in an unwanted way, our component reconnects - but not immediately, but after a delay. The delay depends on the kind of problem detected, and there are currently three of them:
ServerFailedReconnectDelay (defaults to 1 minute) - when the OPC Server indicates through OPC functions that it has failed.
ServerShutdownReconnectDelay (defaults to 1 minute) - when the OPC Server wants to shutdown and has asked its OPC clients to disconnect.
ClientReconnectDelay (defaults to 1 minute) - in all other cases, when the connection is detected "dead".
So, in default configuration, if the OPC server is live again, after 1 minute, you will get your live data back. The delays are configurable via properties on the object.
There is no separate event that indicates such problems. Instead, when the server is detected "dead", all method calls that reference such server will return an exception. Also, all subscribed items will receive an event notification (ItemChanged) where the Exception property is non-null and contains the error information. When the re-connection succeeds, method calls referencing the server will start succeeding, and all subscribed items will receive recent valid data through their normal even notification (ItemChanged).
We have different error codes for different kinds of problems.
