Hello.

Thanks for the details. I was under impression that the event log entries are generated by the system somehow (which I would have liked to investigate). But if they were just your own ones, it is clear now.

If you share with me what you are trying to achieve in terms of these invalid items, I might be able to advise further.

Best regards
ZZ

Hi there,

Thank you for the information regarding the subscription model of QuickOPC and answering my questions. I think we need to develop some additional business logic around the "Activeness" of an OPC Item.

To quickly answer your quiestions:

Are you running under .NET Framework, or .NEt Core/.NEt 5+?

• We are running .NET 5.0

Can you obtain details of these events?...

• These events are thrown from within our own code via a logging adapter, if the EasyDAItemChangedEventArgs Succeeded property is False

Extra details regarding the errors/warnings can be seen in the XML code below.

Kind regards,

Brett.

Hello.

The fact that QuickOPC allows you to subscribe to "anything", and that the errors with subscriptions are reported through the notification channel only, is at the heart of QuickOPC design, quite intentionally. By making a subscription, you indicate an intent to subscribe and stay subscribe. QuickOPC does everything to fulfill that request - including periodic retries - which is what you are observing. You should be aware that an item that does not exist now can become available later...

QuickOPC does not "perform a read on all subscriptions every 60 seconds ". Instead, it tries to add OPC items to OPC groups for those items that have previously failed. Between the QuickOPC and the OPC server, the "failed" item is *not* subscribed, you do not have to be worried about that - doing so is actually impossible, given how the OPC specs are written. It only appears to be subscribed, between QuickOPC and your code.

The retrial period is configurable, and you can set it to very long values if you like, or to Timeout.Infinite to disable the behavior: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ameters~TopicRetrialDelay.html . This needs to be set in static EasyDAClient.SharedParameters.TopicParameters.

The only part that surprises me are the event log entries. I have some questions:
1. Are you running under .NET Framework, or .NEt Core/.NEt 5+?
2. Can you obtain details of these events? I believe that by double-clicking, there should be more info available.

Best regards

I am busy investigating edge cases within our subscription workflow and have noticed that one may Subscribe to an inactive OPC Item (Or even one that does not exist) and still receive a handle back from the EasyDAClient.

The ItemChanged method is then still called for this inactive/non-existent OPC Item, which then raises the error below from within our event handler system.

The ItemChanged method is then called every 60 seconds on the same inactive/non-existent OPC Item and the above error is raised, as can be seen in the image below.



Is this simply an internal default, where the EasyDAClient performs a read on all subscriptions every 60 seconds to compare against previous values?

Is this a known issue with subscribing to an inactive/non-existent OPC Item?

I would ideally like to handle this internally to not subscribe to an OPC Item if it does not exist or is inactive.

Any help with regard to the above issue would be extremely helpful.

Many thanks,

Brett.