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.

Need to confirm OPC client/server connection (fails occasionally)

More
07 Oct 2014 13:40 #2402 by cdunlap
Thanks for the input. We will try that approach.

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

More
07 Oct 2014 13:38 #2401 by support
QuickOPC already obtains server status periodocally, and if a problem is detected, all subscriptions are notified. For what you have asked for originally, I think that adding a timer-based check is what is needed.

Regards

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

More
07 Oct 2014 13:09 #2399 by cdunlap
Thanks for your input on this. As you put it, the main concern would be to ensure that we have some kind of information at a certain point in time. I don't believe it is a critical need, but I think it could be a nice feature to have.

As long as you add it to your list of considerations for the future, that would be good with me.

For now, it may be best for us to try to implement our own timer that considers the subscription call to be timed out, even though it technically has not completed or given an error yet. The main thing for this application was that it subscribes on startup but the user can still interact with the UI for other reasons. We wanted to give them some update as to the status of the subscription if it is taking too long.

Do you think that having a function that wraps GetStatus method so that we can kind of "ping" the server and see if it is available be of use?

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

More
07 Oct 2014 08:57 #2394 by support
After some more thinking about it, the requirement appears to me as more reasonable than I originally thought, because it can provide a guarantee that by certain time from the subscription moment, there will be *some* kind of status update for it from the component.

The remaining question is still about the priority of this in the development plan - your input will be welcome.

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

More
07 Oct 2014 06:34 #2391 by support
To be precise, the QuickOPC's SubscribeXXXX method itself will not fail, but the failure will be reported by the ItemChanged event.

Yes you are right, currently this happens only after the actual error on the OPC level, we do not impose an additional timeout over it. It is actually first time I hear about such requirement. I will make a note for a possible future improvement, but I think it has to be considered carefully whether it is not better left to the developer to implement it on top of QuickOPC when needed. One of my concerns is that having this can easily create a (improper) "feeling of instability": Such timeout must not prevent the operation from a successful completion. Therefore if the timeout happens to be somewhat shorter than the actual time needed, there will be a period of "no data yet", followed by "timeout error", and then "valid data".

Best regards

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

More
06 Oct 2014 19:32 #2388 by cdunlap
Hi,

I am not the original poster, but I do have a question that is somewhat related to this issue. If you would like to move it to a separate thread, we can do so.

Is there any way to have influence on when the initial call to SubscribeItem times out? I am working with an application where the goal is to be as robust as possible, and one of the test cases involves removing the network connection between the client and server. Obviously, in this case, a call to SubscribeItem will fail, but it is taking a long time to do this - around a minute or so.

I know there are certain parameters for read and write timeouts. Is there something analogous to a connection timeout where we can say, after 10-15 seconds of trying to subscribe, the client will give up and throw an error? Or perhaps some method that we can call before trying to subscribe that gets the status of the server to see if it was running - maybe some wrapper around IOPCServer::GetStatus?

If it is at all possible, I would like to not have to wait for the entire subscription process to fail and return after a minute or so - or at least have some influence on when the failure is reported.

The obvious workaround is to try to read or write to a single tag and have that timeout set at a reasonable time to confirm that the connection to the server can be made, but it seems like there would be a better way to approach this.

Thank you for the advice.

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

More
27 Sep 2014 10:13 #2348 by support
Hello,
can you please elaborate on what the problem is?

Are you seeking for a way to troubleshoot the failed connections (i.e. figure out why they fail), or are you asking for a method to recognize and handle the situation in your program?

Thank you

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

More
27 Sep 2014 10:05 #2347 by support
From: OPC Labs Website
Sent: Friday, September 26, 2014 8:57 PM
To: Z.
Subject: QuickOPC Download Form - j.

Programming Language
VBA (e.g. Excel)

OPC Specifications
OPC Data Access

Note
Need to confirm OPC client/server connection (fails occasionally).

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

Moderators: support
Time to create page: 0.103 seconds