OK, thank you for letting us know.

OPC UA requires that the client and server times are synchronized, but I cannot tell immediately if a failure such this can be related. I would say that probably not. I know that times being out of sync sometimes create problems with freshly created application certificates, but that's clearly a different problem here.

Best regards

Hello,
thank you for the additional information.

Unfortunately I have not instructed you to also collect the corresponding event from the QuickOPC, and to capture the whole communication (the instructions that we normally use are here: kb.opclabs.com/Collecting_information_for_troubleshooting - mainly under Assets to Collect).

But still, from what you have sent, assuming that this time the subscription ID in the error message was 53416, and the time values in the error message were roughly the same as in your report, I can tell:
- the client is deleting subscription ID 53416 in packet #73, roughly at 29.9 seconds.
- there is no PublishResponse with that subscription ID from the beginning of the capture until packet #73 - which means, for 29.9 seconds at least.

So, it appears that the client is probably right in claiming that the publishing on that subscription has stopped - either due to network issues, or because of a problem on the server side. Assuming that you are operating on a reasonably reliable network, this leaves the "fault" on the server side only. I cannot tell with absolute certainty though, because I do not see the calls that had set up the session and the subscription, and the timing parameters that the client and the server have negotiated. However, they are most likely the same that can be seen in packets #98 and #99 (around 37.5 seconds into the capture). Which would imply (revised) update rate of 50 milliseconds, and (revised) max keep alive count 250. Which means that the server should send a PublishResponse for that subscription at least each 7500 milliseconds. But it appears that it is not doing that.

OK, now when I am writing I actually realized there is not just this first instance of the problem in the capture, but probably more. So, let's have a look at some later one, and there we will not only find the problem occurrence, but also the setup phase of the subscription. There seems to be problem e.g. at packet #6405; the subscription ID being deleted is 53459. Going backwards form that packet, the latest PublishResponse for that subscription ID is in packet #6353, which is approx. 20 seconds earlier. The way that subscription was set up can be seen in packet #6286: yes, it has the same timing parameters as before. So the PublishResponse should have come in less than 7.5 seconds, but the server has not sent it in 20 seconds or more.

As far as I can tell this is a server bug then. I suggest you send the trace file and this analysis to the server vendor to resolve. Which server is this?

Best regards

Hello,

this could be a server problem, a client problem, or a network problem. In order to find out which part is "to blame", it would be necessary to take a network trace (by Wireshark - we have instructions for that if need be: kb.opclabs.com/Collecting_information_for_troubleshooting ).

The error is basically telling you that the client has not received a message (PublishResponse) during an extended "keep-alive" period - this is a mechanism defined by OPC UA which requires servers to send *some* response even if there is no new data to publish. So, either the client (QuickOPC) is receiving the responses but is mistakenly reporting the error, or it has not actually received the response - in which case it would a network or server problem. Some more subtle reasons are also imaginable, such as a problem on client or serer side in properly understanding the keep-alive parameters that come out of the negotiation between the client and the server.

In either case, the issue may or may not cause an unwanted delay of data delivery to you, or a loss of some updates - this depends on what precisely is causing the problem.

I understand that you are not seeing the issue under Windows so it seems to be more likely a client issue, but it is not possible possible to tell for sure without having the more details logs/traces (Wireshark).


Note: Do not use prerelease versions unless instructed to; they are for our internal use and may contain serious errors. But I understand you get the same with the latest released version.

Best regards