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.

What is the proper way to check connection failure with the OPC server?

More
27 Nov 2022 19:24 #11250 by support
I see.

If the code is not going on rely on the check, but is using it for informational purposes, then there is a value to it. In this sense I agree with you. However the OPC Classic part in QuickOPC does not expose the functionality, and you will need to do it the way you suggested.

Best regards

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

More
27 Nov 2022 17:36 #11249 by aris
I don't agree with you. I know that I can check if the operation was successful or not. This is what I do. But, I also want to be preemptive. I don't want to wait until the operation succeeds or fails to know there might be a problem. The operation may not be called for some time. I'm not saying that I'm making decisions based on a single Succeeded value. But, having a separate thread that probes the connection might give me an indication that something might be wrong. If it failed, for example, 5 times it might be a good indication that the OPC server is down and I can inform the user.

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

More
27 Nov 2022 16:49 #11248 by support
Thank for more info.

I think that you are looking at the issue from somehow improper perspective. Even without subscriptions, with just reads or writes, you do not need to check for anything upfront. You simply call the operation you want to perform, and it succeeds or fails, and your code logic then behaves depending on that result.

In fact, you *have* to it this way anyway. Think it through. There is absolutely no guarantee that if you "check" the connection at one moment, that a moment later it will still work and the operation you call will succeed. It is physically impossible to give such a guarantee. So, if we made it easy for users to check whether the connection is available or not, we will invite them to write code that is either incorrect (if they check it first but then are not quite ready to handle the failure during the actual operation), OR is inefficient (because, to make such code correct, you will end up effectively checking the connection twice, with the first being redundant, as I have just explained).

Regards

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

More
27 Nov 2022 15:40 #11247 by aris
My program controls a robot. So, I have to know if any tag item couldn't be written or read since it might be critical.

Also, what if I don't have any subscriptions? I have to know if something happened even if I don't subscribe to any tag items. And the only way I can think of doing this with EasyDAClient is to have a separate thread that's constantly trying to read any tag item and check the Connected property, right?

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

More
27 Nov 2022 11:22 #11246 by support
Hello.

The QuickOPC subscription model is such that all information that relates to an item is delivered to you through a single channel - that is, the ItemChanged event. There are many kinds of failures that can occur - and some affect just a single item, some affect a group of them (for example, all items that have the same update rate/precent deadband, and form an OPC group, may be affected), and some affect all items that "live" on the same OPC connection (this is the case you have described).

Can you explain what it is that your program is doing with the received data, and why you think you need just a "single" failure handler?

The callbacks and events are just two different ways of delivering the same data (although the callback can be set differently on each item subscription). In other words, there is no difference in having one handler for the ItemChanged event, or having the same callback handler on each item subscription. In both cases, when there is connection-wide failure, the handler will be called with each affected item, and with Succeeded=false.

We have a facility in OPC UA (EasyUAClient object) which gives a single event or callback for connection status changes, but a corresponding feature is not present for OPC Classic.

To your questions:

1. I am not 100% sure if I fully understood your approach, but in general what you wrote makes sense and will probably work. However, as I tried to explain, I do not actually see a reason for combining the events and callbacks, because they deliver the same information.

2. For each notification, the event fires first, then the callback. However this is not currently documented and should be considered an implementation detail on which your code should not rely (although we have absolutely no plans to change it). The events and callbacks on a single EasyDAClient are all serialized, i.e. the next one will not fire until the processing of the previous done is done (has returned). This part *is* guaranteed.

3. Not really - the range of errors is broad and it very difficult, close to impossible, to enumerate them (we could do it for errors they we detect ourselves, but there are errors from the underlying subsystems such as DCOM/RPC infrastructure over which we have no control, and the error Ids then combine their type with their numerical code, and while some codes are known and occur commonly, it is not a closed set of codes).

Best regards

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

More
27 Nov 2022 04:17 #11245 by aris
I use EasyDAClient::SubscribeItem to subscribe to a tag item. When there is a connection issue the EasyDAItemChangedEventArgs::Succeeded=false, which is expected and I can act accordingly in the callback method.
Since I have many subscriptions, I don't want to add the same handler in each callback (pseudo-code: if(EasyDAItemChangedEventArgs::Succeeded=false) CallOnConnectionFailed()). Is there a way that I can subscribe to something that I'll be able to check for Succeeded=false in one place?

I'm thinking to use EasyDAClient::ItemChanged, which is called for every OPC item subscribed, and check for Succeeded=false there.
  • Is this the proper way to do this?
  • Is it guaranteed that ItemChanged event will be fired before any other callback? If not, does it mean that callbacks could be fired simultaneously?
  • I noticed there is EasyDAItemChangedEventArgs::ErrorId. Is there a list of possible error ids?

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

Moderators: support
Time to create page: 0.094 seconds