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.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Browsing, Browse Dialogs and Controls
- After an unsuccessful BrowseBranches() (COM Timeout exception comes), the next one (good) needs a big time before succeeding.
After an unsuccessful BrowseBranches() (COM Timeout exception comes), the next one (good) needs a big time before succeeding.
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.
I will look at this-please wait till next week.
Please Log in or Create an account to join the conversation.
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.
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.
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.
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.
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.
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Browsing, Browse Dialogs and Controls
- After an unsuccessful BrowseBranches() (COM Timeout exception comes), the next one (good) needs a big time before succeeding.