Thanks for letting me know!

Note that we have kind of "hidden" the problem that may still exist between QuickOPC and the Beckhoff, when multiple connections are made (by using a single connection, which is better anyway - but using more shouldn't be problem too).

Try to keep it in mind if something similar pops up in the future.

Best regards
ZZ

Ganesh,

yes indeed, the Live Binding basically has its own EasyUAClient object, so when combined with "traditional" coding and "new EasyUAClient()" (even if it is with Isolated = False), it will end up using separate session.

And, we can see that this is somehow problematic with the target OPC server (Beckhoff).

So, the customer can remove the Live Binding - but that's not really necessary. Here is an alternative: He can keep the Live Binding and also his own code, BUT he nends to refrain from allocating new EasyUAClient objects. Instead, he should use the same object that Live Binding is using. He can access that object by calling the GetClient() method on the DAConnectivity component he already has (for the Live Binding). This will return an IEasyUAClient interface which can be used to perform all necessary operations.

I suggest that the customer does this, then re-test, and with the results we will go forward.

Best regards

To the Visual Studio hangs: Unfortunately, it is going to be hard, because here I miss the means to obtain more information about what is happening.

Is the customer using Live Binding in WPF or Windows Forms? (I think it is WPF, but need to verify that).

Regards

This is a reply to the "Issue #1" from the PDF - that is, the increasing session/subscription/monitored item counts in the server. Yes, as the customer has already figured out, the connection appears to "break" from time to time, and that causes the counts to increase. According to the WireShark trace, however, the servers "knows" about the problems (it sends ServiceFault messages, e.g. in packet #1716), and therefore it should, either immediately or at some later time, decrease the counts. The fact that it does not do it should be reported to Beckhoff, but that's not the main issue here.

The question is, what is causing the disconnections in the first place. I do not know yet. Basically, the server seems to stop sending publish responses for quite a time, and then starts sending the ServiceFault messages. I suspect this may be a server problem and can provide more detailed analysis with references to the Wireshark trace, but there is one more thing going on which I do not understand, and that can be related, and I want to clarify it before we blame the server. It is the fact that for some reason, QuickOPC starts with one session to the server, but after cca 6 seconds, it creates a second one - and it is roughly at this time when the first session starts having problems. I do not understand why this second session is being created.

Explanation might be e.g. that either 1) the customer has used EasyUAClient with setting Isolated = true, or 2) he is using two, functionally equivalent but still different ways to address the server. Can you please ask the customer whether he is absolutely sure that he always uses the same endpoint URL string in his program? Including upper/lowercase, and seemingly unimportant things like the slash at the end? For example, is he always stating the host name as "CONVBELT", and not sometimes as "convbelt"?

If the answers to the above questions are negative, I would like to ask the customer to collect yet more information. I will provide the necessary instructions in such case.

Regards

Ganesh,
thanks for all the info.

I will start with what is labeled as "Issue #2" in the PDF - that is, the UAException with service result 'BadSessionIdInvalid'. First, I contest the claim that try-catch does catch the exception. Please have the client send the related part of the code for review. Actually, ideally all the code (could be through a private channel, not here), because there might be other place in the code where it is coming from and does not have the try-catch.

As to the exception itself, I think it is very likely that it is related to debugging, as he suggested. There is a session timeout which defaults to 1 minute. Blocking the client process (by breaking into a debugger and then pondering about the status) for a longer period can cause the server to discard the session, which would result precisely in this status code. If this is seen as a problem, the customer can increase the session timeout by setting a property - see opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User's...Parameters~SessionTimeout.html .

For a bunch of subscription-related parameters, we already have special handling in the code so that we set these parameters to much longer values when a debugger is detected. But we do not currently do this with the session timeout. I have made a note to possibly improve it in the future.

The remaining issues will be addressed in separate posts.