Professional OPC
Development Tools

logos

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.

errors raised before handles provided

More
10 Aug 2014 08:58 - 10 Aug 2014 09:03 #2148 by support
This behavior is by design.

It has to be this way, if we want the SubscribeXXXX methods (and UnsubscribeXXXX, ChangeXXXXSubscription) return without waiting for results. And it is one of our design goals, which is derived from real use-cases. For example, users want to write things such as simple HMIs etc,, where switching screens involves subscribing/unsubscribing. If these methods have blocked until the operation gives some results (for all items involved), the user experience would be bad.
And we would have to device some ADDITIONAL way of passing back to you the "first" result or waiting for your code, because the notifications can be fired at any time, and therefore even if we have returned from the call and gave back the handles, we would STILL not know for sure whether your code has proceeded to the point where it has properly stored/processed these handles.

But it is easy to overcome. Not only that, the right way of doing it is easier and safer to write, and more efficient to execute. Here is what you should do:

1. Do not use the handles returned by SubscribeXXXX for anything else than for calls to UnsubscribeXXXX or ChangeXXXXSubscription.

2. Instead, identify the items yourself. To do that, use a State argument that is passed BY YOU to the SubscribeXXXX method (depending on the overload, it may one of the method argument, or it may be encapsulated inside an "arguments" object). This way you can define the association BEFORE you even call SubscribeXXXX, and it can be an object of your wish. You will receive this object in a State argument with each notification, and you will already know what it is, and you will be able to directly use it, without looking up the handle in some kind of map or dictionary => better performance. The only thing you may need is to typecast if, because State is an 'object', but in your code it will be something more specific. In many cases, there is already something in your code that can be logically used as the State object - for example, in many UI apps, it may be directly a reference to a control on the form that should be updated by that notification.

Best regards
Last edit: 10 Aug 2014 09:03 by support.

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

More
09 Aug 2014 12:37 #2146 by giles
Hi when I am subscribing multiple items with

UAClient.SubscribeMultipleMonitoredItems

and one of those items has a bad address

I get a MonitoredItemChanged event with the handle of the bad item

error is

OPC-UA service result - An error specific to OPC-UA service occurred.
---- SERVICE RESULT ----
StatusCode: {BadAttributeIdInvalid} = 0x80350000 (2150957056)


this is all fine however I get the event before i get the handles returned from the subscribe call. - that's a pain because I can't map the handle to the subscription that caused the error.

No doubt I'll get round this but I think you might want to look at it

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

Moderators: support
Time to create page: 0.042 seconds