Hello.

In the remainder of my answer, I will assume that when we talk about “connecting/disconnecting” devices, it refers to the OPC UA communication between the QuickOPC application, and the OPC UA server in the device. I just want to be sure that it not a different kind of “disconnection”, for example, with permanent connection between QuickOPC and some OPC UA server, which *then* connects itself to the device, and there are disconnections of the communication link between the OPC UA server and the device. In such case let me know, because some of the answers may be different.

1.1: See
opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...onParameters~RetrialDelay.html
and
opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...meters~ReconnectionPeriod.html

1.2: So far I see no reason to modify them, but you have better knowledge about what your application needs, and whether the defaults are suitable.
1.3: There is no limit. As long as you are subscribed to at least one monitored item in the device, the reconnection attempts will continue.

2. No. Assuming that your code has subscribed to at least one monitored item in the device, you do not need to do anything. When there is a disconnect, you will receive an error through the DataChangeNotification event. When reconnects finally succeed, you will receive valid data through DataChangeNotification event again.

3. If the browse is needed for the application logic, then it is correct. If you are doing it “just in case”, it is unnecessary and should be removed.

4. The code is correct, if you are using one EasyUAClient instance per device. It is possible, but not necessary to split it this way. You can use one EasyUAClient for all devices, in which case this situation should be handled by calling UnsubscribeMultipleMonitoredItems instead, for the monitored items that reside in that particular device (and, no Dispose, in that case).

Best regards

Thank you for the answers. It's not, however, quite clear what is happening. If you are willing to help with (hopefully) finding the true cause of the issue. please revert the changes made to work around the issue, and then reproduce the issue while collecting the information as described here: kb.opclabs.com/Collecting_information_for_troubleshooting .

Yes, retrials are done automatically. When an error occurs, a DataChangeNotification is generated for *all* subscribed monitored items. When/if the retrials finally succeed, a DataChangeNotification without an error (and with the actual data) is generated.The timing of the retrial can be influenced by parameters on EasyUAClient.

Given the above, your code should not do things like unsubscribing when an error occurs, etc. - that would just duplicate the logic and create problems. But, it can, of course, have a logic that in case of errors does something differently regarding the functioning of your application. What that would entail, however, I cannot tell - it totally depends on the purpose of the application.

Best regards

Hello.

Of course this should not be happening. It looks like that one side (most likely server) things that the other has stopped communicating, and then disposes of the session and considers new registers with the old session ID as invalid.

Questions:

1. Are you saying that making a browse every minute "resolves" the issue?
2. When you see this error, are you running under debugger, or without a debugger?
3. If possible, try the opposite method - run without the debugger if you were running with it before. Or run under the debugger (if available) if you were runnin g outside of debugger before. What are the results? The reason I want to test this out is because we have a separate, quite different set of timing parameters under the debugger - to see if it has an influence. The settings under the debugger are designed to allow setting breakpoints etc. without breaking the comms.
4. What is the OPC UA server you are connecting to?

Thank you

Thank you for the additional information.

We do not have experience with running under Docker, and we do not test with it as part of our development procedure. But if e did, it is unlikely that we would be able to resolve any issues that only appear under Docker; they most likely have to do with the environment that we cannot influence.

As I wrote, this looks like like server-side or communication issue. You can try:
1. Modify some QuickOPC parameters to be more "forgiving", to see if it helps. For example, it is possible that the additional 5000 milliseconds mentioned in the earlier post was simply not enough a wait, and if we have waited a bit more, the communication would proceed well. All in all I do not think this is going to really help, because the problems will still be there and even if the comm does not break, it would "pause" until resolved, anyway.
2. Deploy network analysis tool in the container (not sure how - or possibly on the host) - we intend to analyze the communication using WireShark and determine "who is to blame".

Best regards

Hello.

First, it is very good that you are testing the e.Exception first. And, it is very good that you re-tested with the recent version - because we had some updates in a related area.

There seem to be two basically two issues, but they are likely to have common cause. It looks like either a communication problem (network), or server-side problem. In both cases, it is the client side (QuickOPC), detecting that the responses from the server do not come as expected. For example. in the case of the first error you have reported, the server is expected to reply to a publish request at least in 10,000 milliseconds (10*1000), we gave it additional 5000 milliseconds (accounts for scheduling/processing/transport delays), but then, in total of 16,533 milliseconds, no response had arrived. This first error has to do with subscription-level checking. The other error is similar, but related to session-level checking.

I suggest that it take this to the server vendor. Which OPC server are you connecting to? Do you have a reliable network?

If necessary - that is, if the above finding is genuinely contested (there can still be a problem on QuickOPC side, too), it would be possible to take a Wireshark capture of the OPC UA communication, and see precisely what is happening and where the issue comes from. If it somes that far, I'd need to give you further instructions (do not do it right now).

Best regards