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.
Questions:
- Should my application go straight to handling the subscription of all tags directly or ok to tune automatic subscription accordingly?
- Does the EasyDAClient.ReadMultipleItems() method also perform an automatic subscription as described in the post
Disabling automatic subscriptions made with OPC Reads
?
- Is it wise to call EasyDAClient.SubscribeMultipleItems() with a list of 10k tags?
- 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?
- 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.
