Oops.

OK, in this situation I suggest that we obtain more information about the communication. This can be done on various levels - with more and more effort. I suggest to start gradually: Can you please add an event handler for the static event EasyUAClient.LogEntry, and store all information (mainly, the time and the message, but the more the better) into a text file or similar? And, if the server has some kind of diagnostics, capture that as well. Then send the diagnostics back to us. This should at least tell us what the final timing parameters in use are, and how significantly are they getting exceeded. From that we should see whether it is meaningful to try "tuning" the parameters and how, or whether there is a deeper problem that the parameter changes cannot resolve.

Best regards

Thank you for letting me know, and I am glad that the problem is resolved.

I should note that in general, this problem *cannot* be avoided with 100% guarantee. Because OPC UA is not a real-time protocol, and Windows is not a real-time OS, there is no upper bound on how long things can take - and this error is an indication of a keep-live mechanism kicking in, detecting the situation and attempting to resolve it. Obviously by setting the various parameters cleverly (which is what the updated version does better), and making sure that the computer and the network are not overloaded, one can get the probability to almost zero.

Best regards