Professional OPC
Development Tools


Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Design Question / Rely on automatic subscriptions or subscribe manually?

01 Dec 2020 20:43 #9229 by tblong
Thank you. From testing looks like setting these two to zero before the EasyDAClient.UnsubscribeAllItems() call did the trick:
- EasyDAClient.InstanceParameters.HoldPeriods.ItemDetach = 0
- EasyDAClient.InstanceParameters.HoldPeriods.ServerDetach = 0

Please Log in or Create an account to join the conversation.

01 Dec 2020 15:54 #9228 by support
With QuickOPC, the way to disconnect from the server is to stop making operations on it (such as Read, Write, etc.), and unsubscribe from all items. There is no other way.

You are absolutely right about the timing: the actual removal of all items from the server, and the disconnection, happens some time after your code calls the corresponding method. There are timing parameters that influence how long it may take before the client actually disconnects.

With the knowledge of the parameter values, your code can wait some time before the application fully exits, giving QuickOPC chance to make the finalization tasks.
It is also possible to change the parameters, to shorten the delays.


- EasyDAClient.SharedParameters.EngineParameters.GarbageCollectionPeriod
- EasyDAClient.SharedParameters.EngineParameters.MaxClientAge
- EasyDAClient.SharedParameters.EngineParameters.MaxTopicAge

- EasyDAClient.InstanceParameters.HoldPeriods.ItemDetach
- EasyDAClient.InstanceParameters.HoldPeriods.ServerDetach


Please Log in or Create an account to join the conversation.

30 Nov 2020 17:16 #9227 by tblong
All working well so far testing my app with prerelease v5.59.0-rev23 with explicit subscriptions. I have follow up questions once more and this time related to disposing of all connections and resources. I do realize though that one of the main design principles of QuickOPC is to give the client a connectionless API.

My app subscribes to a handful of items on a given server. The app needs to be restarted for some reason or another. The app, before closing, disposes of an internal class which manages a reference to EasyDAClient. During dispose, the app calls EasyDAClient.UnsubscribeAllItems() and EasyDAClient.Dispose(). On the server side, I can see that the connection is maintained and the group of items previously subscribed are still maintained.

I imagine that the EasyDAClient instance will still wait some time before actually removing items from the group it created due to either "chunk size" settings and some other internal delays. My questions are around situations where I'd like to force a disconnect. I am open to other ways I should be thinking of or handling this type of situation.

  1. Is there a direct method of synchronously forcing an unsubscribe, removal of groups created, and disconnecting from a server?
  2. Is there a better method of handling this situation?

Please Log in or Create an account to join the conversation.

18 Oct 2020 18:08 #9009 by support

as opposed to lower-level toolkits, QuickOPC does not give you direct control of OPC groups - they are largely "invisible" to you. And, in its default configuration, QuickOPC tries to put all items with the same subscription parameters into a single group.

If there is a limitation to the OPC group size on the server size, you currently need to manually "work around" this QuickOPC behavior; there are two approaches that can be used:

a) Use separate instances of EasyDAClient, and set their .Isolated property to 'true'. The downside of this is that not only separate OPC groups will be created, but also separate OPC server objects ("connections").
b) Trick QuickOPC into creating more groups by slightly varying the subscription parameters: For example, use 1000 milliseconds with one set of items, and 999 with other set of items. For this to work, the so-called "parameter bucketing" optimization needs to be reconfigured or turned off.

The workaround are kind of ugly, but that's how it is.
Best regards
The following user(s) said Thank You: tblong

Please Log in or Create an account to join the conversation.

15 Oct 2020 19:48 #9003 by tblong
Thanks for the great feedback, I'd rather head the right direction at the start than have to backtrack later. Depending on how soon the official release of QuickOPC 2020.3 is expected, I may just begin now with its prerelease. I expect my full production app to be needed in the next 30 days or so.

With our current OPC codebase which is not yet using the QuickOPC lib, we are chunking to limit the number of tags in each subscription request. There have been instances where the OPC server chokes if we send too many over at once. It appears that the chunk size is configurable in the QuickOPC 2020.3 release notes so that will be helpful.

Follow up question:
When subscribing to large set of tags, does QuickOPC make decisions on when to create another OPC group if the total tag set for a group is too large? I imagine certain OPC servers to have individual group size limitations but do not know if this might be handled automatically by QuickOPC or if it's something that could be configured.

Please Log in or Create an account to join the conversation.

15 Oct 2020 08:43 - 15 Oct 2020 08:44 #9001 by support
good questions, and I am glad that you have asked.

I will first provide the answers, and then some background explanation.

1. I suggest that you do the subscriptions explicitly, and turn off the automatic subscriptions.
2. Yes, it applies to all reads. In fact, ReadMultipleItems is *the* one and only true reading method on I/EasyDAClient. All other ReadXXXX methods just provide different forms of input arguments or outputs, and in the end they delegate (end up calling) ReadMultipleItems.
3. These are fairly high numbers, and it might be better to split into smaller chunks - more about it below.
4. These are "merged" into just one subscription (on OPC level) by QuickOPC.
5. See below.

Frankly, the automatic subscriptions have been designed mainly for one specific use case: A state-less, old-fashioned web application which shows OPC values on the page either on user demand, or by periodically refreshing the page. In such application it is impossible to explicitly subscribe and unsubscribe. But if you *can* subscribe and subscribe, you should do it.

In fact, we will be turning off the automatic subscriptions (by default) in the upcoming QuickOPC 2020.3, because except in cases like the one described above, it brings more problems than it resolves. And the whole area covered by your questions (things like merging the subscriptions etc.) gets a re-implement in QuickOPC 2020.3. See the preliminary What's New for 2020.3 here: . There is also ability to "chunk" the requests automatically.

I suggest that you create some "proof of concept" project. If you run into problems (which I suspect might happen due to large number of items), report them here. At that moment, however, I will kindly ask you to try out the new 2020.3 version (even if it's just pre-release at that moment), because due to the changes in the implementation, it would make no sense to try to resolved issues in the implementation that we are just discarding.

Best regards
Last edit: 15 Oct 2020 08:44 by support.

Please Log in or Create an account to join the conversation.

14 Oct 2020 20:33 #9000 by tblong
In reference to these two posts:
I actually like the idea of the EasyDAClient handling the creation of subscriptions for me in the background based on reads performed by my application. The last post above does suggest having a user's application handling the subscriptions directly. I would like to make sure that my use case below still leans toward the recommendation of handling the subscription directly.

Example use case:
My application has 10k tags which it needs an updated value for every 5 minutes. Roughly every 24 hours there may be tags added to or removed from the list to be updated. The application should only add/remove tags from subscription rather than incurring the cost of unsubscribing all and then resubscribing only the new tag set (not including getting disconnected from the OPC server here). Unlike the second post above, this application does not have the requirement of browsing recursively through the OPC server periodically, the application will either have a itemId that exists or does not in the OPC server.

  1. Should my application go straight to handling the subscription of all tags directly or ok to tune automatic subscription accordingly?
  2. Does the EasyDAClient.ReadMultipleItems() method also perform an automatic subscription as described in the post Disabling automatic subscriptions made with OPC Reads ?
  3. Is it wise to call EasyDAClient.SubscribeMultipleItems() with a list of 10k tags?
  4. What happens if my application were to resubscribe to the same item twice with EasyDaClient.SubscribeMultipleItems()? Is this duplication handled automatically by the the QuickOPC lib?
  5. I am new to the QuickOPC library, so what else have I not asked that may be helpful to know during my design phase here? I admit that I have not been able to make it through but 10% of the QuickOPC user guide.

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.087 seconds