I thought you were subscribing to the monitored items.

Are you instead invoking a Read periodically?

If it were under the debugger, then it would be, in principle, a behavior as expected. What happens is that in OPC UA, the "broken connection" is detected by in-band mechanism in the protocol itself. The client uses a so-called keep-alive count, and the server the so-called lifetime interval, to detect interruptions. These mechanism collide with using a debugger when the user sets breakpoints, and for this reason we try to negotiate a high keep-alive count and a long lifetime interval, when a debugger is detected. Consequently, interruptions are only detected after very long time (days), under the debugger.

Without a debugger, normally the time to detect an interruption should be much shorter, because that's what we, as client, "propose" (but in the client-server negotiation, the server has the final word).

I could not reproduce the issue here, and without having it reproduced I cannot help much further.

What kind of publishing interval are you using for monitoring the values? Something in milliseconds/seconds range, or something considerably longer? (the detection interval is derived from that).

Sorry, one more question: Are you testing while running under a debugger (e.g. from Visual Studio, the typical "F5" or green arrow toolbar button), or standalone (e.g. from command line, or launching from Windows Explorer)?

Thank you. I have some more questions

1) is the protocol opc.tcp:, or http: ?
2) Do I understand it correctly that the PLCs your are connecting to have an embedded OPC UA server. That is, that there isn't a separate PC box in the middle with the OPC UA server that would in turn communicate with the PLCs?

Best regards

I will try to reproduce this here. Which version and build are you using please? (best way to find out is from the Details tab when right-clicking on one of OpcLabs.* assemblies and doing Properties).