- Posts: 5
- Thank you received: 1
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.
Various questions regarding Subscription
Oh, I see, you were scared by the word "asynchronous", which perhaps needs more qualification from my side.
Do not worry, both scenarios you described are guaranteed to work the way you want them to work. This is because although all subscription-related operations on a EasyXXClient may run asynchronously, subscription-related operations on the same EasyXXClient instance never run in parallel, and although they are executed in a queued manner, the order is preserved - i.e. they execute in a sequence in which they have been called.
I will make a note to check the documentation and if the above is not explained there, then improve it in the next version.
thanks for your fast response. You've asked: "There is currently no way for your code to know that the items have been fully unsubscribed. ... why do you think you need that?"
We use the same EasyUaClient instance to configure/reconfigure our subscriptions, calling UnsubscribeAllMonitoredItems() and then SubscribeMultipleMonitoredItems(...) without any delay.
We think there could be 2 critical situations:
Step1: We have no subscriptions and subscribe to the nodes "NodeA, NodeB,... Node Z". Everthing works fine.
Step2: Then we reconfigure the EasyUaClient instance and UnsubscribeAllMonitoredItems starts unsubscribing the nodes "NodeA, NodeB,... Node Z".
As next statement we start SubscribeMultipleMonitoredItems with the node "NodeZ" without any delay.
Now these 2 operations may overlap, the first nodes are unsubscribed (NodeA and NodeB) and in the meanwhile, the new subscription subscribes the node "NodeZ".
"NodeZ" was already subscribed before, so what happens?
Do we get the expected result, that all previous nodes are unsubscribed and "NodeZ" is the only subscription? And is this behaviour guaranteed?
We use your EasyUaClient to connect to a Programmable Logic Controller (PLC) via OPC UA.
On this PLC, there exists a total maximum count for all subscriptions (all instances, all users) let's say of 1000.
Step1: We have no subscriptions and subscribe to the nodes "Node1, Node2,... Node 1000" (1000 nodes). Everthing works fine, because we have 1000 subscriptions available
Step2: Then we reconfigure the EasyUaClient instance and UnsubscribeAllMonitoredItems starts unsubscribing the nodes "Node1, Node2,... Node 1000".
As next statement we start SubscribeMultipleMonitoredItems with the nodes "Node1001, Node1002,... Node 2000" (again 1000 nodes) without any delay.
What happens now?
Do we get the expected result, that all previous nodes are unsubscribed and all new nodes are subscribed, without exceeding the maximum limit of 1000 nodes during this process?
(Note: The PubSub category used to post this isn’t really appropriate. PubSub is an OPC UA communication model different from Client-Server - which is what your post is about, Client-Server. Due to technical problem I currently cannot move the topic elsewhere, though).
All methods that have something to do with subscriptions (subscribe, unsubscribe, change subscription) work asynchronously. This annotation was missing from some methods/method overloads, thank you for pointing it out; we will fix the documentation in the next version. There are no fully synchronous versions of these.
What the EasyUAClient component really understands and performs are the methods defined on the IEasyUAClient interface. The extension methods in EasyUAClientExtension and EasyUAClientExtension2 just manipulate the input arguments (and sometimes the results) to either make it look that there are multiple overloads of the methods available on the interface, or provide functionality tailored at data access or alarms&conditions - but again, simply by having code to properly construct the arguments for the "true" methods IEasyUAClient interface. All in all, this allows the developer to write shorter code by choosing the proper method (or extension method)&overload, but it does not change the execution model - the extension methods behave the same, in this respect.
The code in the examples that waits after unsubscribe is not strictly necessary. Is it there just to 1) show the developer how it works, and 2) if there are events or callbacks hooked, it prevents notifications (that may still be coming) from spoiling the output when the user is already doing something else at that point. We could, for example, unhook the event, to prevent the unwanted notifications from arriving.
There is currently no way for your code to know that the items have been fully unsubscribed. I would like to know the use case, i.e. why do you think you need that.
The code that does the communication is *not* in the EasyUAClient. There is a shared "engine" object that actually performs the operations for all EasyUAClient-s in the background. It is therefore possible to dispose of the EasyUAClient safely. Doing so triggers UnsusbcribeAllMonitoredItems (asynchrously, again), which can then be performed even after the EasyUAClient object is disposed. Sothis is not a problem. The real problem can happen when the whole process wants to shut down while there are operations pending - that is a complicated issue, which we also try to handle but it still has some rough edges.
Yes. Being subscribed from your code denotes a permanent intent to become and stay subscribed. So, it does not even have to succeed the first time (the method won't return any error - but there will be error notification). There are automatic reconnects in place to fulfill that goal. The number of retries is not limited. You will receive at least one error notification when things go wrong. Usually there are more of these as the reconnections keep failing. You will start receiving calid data when it reconnects.
we have some questions regarding your OPC-UA implementation (C# NuGet package "OpcLabs.QuickOpc" Version="5.63.162").
We are using client server UnsubscribeAllMonitoredItems/SubscribeMultipleMonitoredItems together with PullMultipleDataChangeNotifications.
1. UnsubscribeAllMonitoredItems and SubscribeMultipleMonitoredItems.
a) your documentations contains the following remark for UnsubscribeAllMonitoredItems and SubscribeMultipleMonitoredItems: "This method operates (at least in part) asynchronously". What exactly does that mean?
b) is there a complete synchronous version of your methods UnsubscribeAllMonitoredItems and SubscribeMultipleMonitoredItems?
c) in this version of SubscribeMultipleMonitoredItems your documentation doesn't show the remark, that the method ist partly asynchronous:
I) Is this version synchronous or is just the remark missing?
II) What's the diffence between the SubscribeMultipleMonitoredItems methods on UaClient, EasyUAClientExtension and EasyUAClientExtension2?
d) if UnsubscribeAllMonitoredItems is always asynchronous, how can we safely determine, that all items are really unsubscribed, before subscribing new items? In your examples, your're waiting for 5 seconds after UnsubscribeAllMonitoredItems,
but that's not really a safe option for production code.
e) SubscribeMultipleMonitoredItems: how can we safely determine, that all items are really subscribed?
f) if UnsubscribeAllMonitoredItems is always asynchronous, calling a Dispose() directly after UnsubscribeAllMonitoredItems() as in your documentation shouldn't work. The object will be disposed during unusbscribing? opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ce-QuickOPC/Unsubscribing.html
Is this really correct?
2. In case of problems, is the uaClient automatically reconnecting the the OPC-UAServer? Could you tell us some details about this behavior (number of retries, retry interval, status change information,...)
Please, could you help us with our questions?
ps: I sent this message on behalf of a colleague