Thank you.

Regarding the license: Most likely you have QuickOPC 5.3x on your invoice, and therefore you are licensed to use the current version (5.35) as well. The only case in which you would be license to 5.30 and not to 5.35 would be if you have purchased an earlier version (5.2x) and a maintenance contract, and the maintenance contract (which is time-limited) would then only cover the versions released during that time. If you are not sure, use the contact form (www.opclabs.com/company/contact/form/3-contact-form ) to identify yourself (with reference to this forum post), and we will look up the license information for you.

The code you have sent appears correct for most part, but there is one omission that is particularly relevant to the problem at hand. The issue is that you do not test for (and do not log) the .Exception property of the incoming event arguments. Please study the best Practices section of the documentation (Concepts), and especially this chapter: "Always test the Exception property before accessing the actual result (Value, Vtq, or AttributeData property)". The .Exception is the main channel through which you receive an indication that something went wrong, and the fact that you are not logging it means that we are missing the primary source of information about the problem. In addition, by properly testing for non-nullness of .Exception, you can get rid of the issue with accessing a null AttributeData - for which you have an unnecessary try/catch block. When .Exception is non-null, the AttributeData is always null. And vice versa: When .Exception is null (i.e. "No Error"), the AttributeData is always non-null.

My suggestion is therefore to 1) change the code as indicated, 2) rebuild with 5.35, 3) retest.

Best regards

OK, here are two things: 1) What and why causes the issue, and 2) what happens afterwards.

ad 1) The log itself does not give enough information. What kind of error do you receive in the event subscription handler?

If possible, please provide a code (or skeleton of it) that you use to handle the incoming data changes.

ad 2) The expected behavior of the component is to automatically restore the connection after it has failed - in this case, after 10 seconds, as indicated in the log entries. Are you saying that it does not happen?


Note that we no longer support version 5.30. For any more involved investigation, an upgrade to current version (5.35) would be required. Besides a chance that it could resolve the problem, it would probably provide better diagnostics output.

Best regards