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.

After an unsuccessful BrowseBranches() (COM Timeout exception comes), the next one (good) needs a big time before succeeding.

More
26 Aug 2014 09:33 #2178 by support
I am now back in office, and plan to look at this, ideally during this week. I think I can do it by using our own simulation server, and either block the execution by placing breakpoints in it, or adding "wait" commands to it at specific places.

Do you have an idea where precisely the problem occurs? It can be, for example
a) in the COM CreateInstance call for the OPCServer object
b) in some "ceremony calls" we do, for example, GetStatus on the OPCServer, or Advise (for the IOPCShutdown)
c) in the actual browsing call
Have you tried to put an OPC Analyzer in the middle, to figure out where it blocks? If not, can you do that, to reduce the number of things I have to try on my side?

Do you know whether the browsing method is OPC-DA 1.0, 2.x or 3.x?

Can you confirm that this happens:
1. Initial state - no EasyDAClient method have been called yet.
2. You start by calling BrowseBranches on the "bad" server
3. It times out after cca 20 seconds (please send me the exception message and details - it is really important)
4. You call BrowseBranches on a "good" server
5. It succeeds but it takes unnecessarily long (cca 20 seconds).

Best regards

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

More
19 Aug 2014 19:46 #2173 by support

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

More
18 Aug 2014 10:52 #2171 by Emilio
Back from holiday...

The point is that any OPC client hangs when trying to connect the bad OPC server. If I try with an other client and another server everything works fine.

The only way to reproduce this behaviour would be to code a bad server, which never returns from COM CreateInstance, and try.

When I have a bit of time I can try to quick develop such server and send it to you, unfortunately not at the moment. We do not have even a setup for our real bad server, sometime ago it came automatically within some installation.

Thank you,
emilio

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

More
23 Jul 2014 15:15 #2095 by support
OK, let's do it this way.

Before that - have you tried the same using some other simple OPC client? If they all do it, the problem may be somewhere in the system, and it would be pointless (although interesting) to try to hunt for it inside QuickOPC.

Best regards

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

More
23 Jul 2014 14:11 #2093 by Emilio
Yes both servers are on the same PC.
I think I can reproduce it in any machine easily, if I provide an OPC server (demo version quickly developed by us and easily installable) that never returns from connection attempt. In this way we can try to debug it.
The only thing is that I'm on holiday from this evening :-), therefore I would say hear you after the 18.08.

Thanks for the quick response.
Emilio.

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

More
23 Jul 2014 13:43 #2090 by support
Emilio,
I agree that it is weird.

Are both the good and the bad server on the same computer? If so, couldn't it be that there is something in the COM/DCOM which the "bad" server keeps locked or busy, and that affects the "good" server as well?

Can you try browsing the "bad" server, and then a "good" server on a different computer?

Obviously it can also be something inside QuickOPC, but it is difficult to tell without having a reproducible case. The idea of the browsing code is that once the first method is finished, the second execution (for the "good" server) should not be influenced by previous operations.

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

More
22 Jul 2014 10:36 - 22 Jul 2014 10:37 #2085 by Emilio
We have a bad OPC Server, a connection from any client hangs until the COM timeout exception comes. We implemented a recursive way to read the whole Address Space, by using BrowseBranches() and BrowseLeaves() recursively, and this works very fine.
If we try to browse the bad server, then a (caught) COM Timeout exception comes, after circa 20 seconds (default COM timeout) and this is expected. The next BrowseBranches() on a valid server succeeds, but only after a long time, also 20 seconds or more. From the next one everything works fine.
It seems that only the first BrowseBranches() after the failure due to the COM timeout exception does not work properly, after that everything works as expected.
This might not be a big problem, actually the OPC server is "guilty", but the customer who is working might think that suddenly nothing works anymore, actually he has only to wait, and just once after such a failure.
Last edit: 22 Jul 2014 10:37 by Emilio.

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

Moderators: support
Time to create page: 0.065 seconds