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.

Browse Dialogs - OpcEnum oddity

More
27 Mar 2015 15:35 #3014 by arstorey
Thanks very much for the explanation. Your hypothesis was correct. Something had added added an InprocHandler32 key to the registry under the OPCEnum CLSID. This was the case on all the client machines I tested! We must have installed something in the past on all of them which added the key to each.

The work-around is fine. Thanks again!

Alan

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

More
27 Mar 2015 09:38 - 27 Mar 2015 09:41 #3013 by support
Thank you for detailed description.

The reason why the browsing dialog takes long is clear - when the OPCEnum fails, the browsing from registry is used, and that is slow, especially remotely, because it requires going through many registry keys one by one.

The OPCEnum as distributed by the OPC Foundation is implemented as "Local Server" (which can also be remoted), and nothing else. Therefore, when we allow all possible execution context, it is the local OPCEnum as "Local Server", or a proxy of a remote OPCEnum (which is considered "Remote Server") that should be chosen and work. And it does work - except in your situation; we haven't seen this problem before. Which Windows version are you using?

A hypothesis is that somebody has installed and registered a (non-functional) "inproc handler" for OPCEnum on your machine. This handler gets chosen, because it is allowed by our default execution context, and inproc servers and inproc handlers are generally faster so I would expect Windows to prefer them when it has the choice; and the handler fails.

Since it would be very unusual for OPCEnum to actually be anything else than "Local Server" or "Remote Server" anyway, based on this report we will probably change the default execution context for OPCEnum in some future QuickOPC version/build, in order to prevent possible problems.

Can you live with the workaround you found for now?
Last edit: 27 Mar 2015 09:41 by support.
The following user(s) said Thank You: arstorey

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

More
26 Mar 2015 21:37 #3012 by arstorey
I am having issues with several of the OPC browse dialogs (with both QuickOPC 5.31 and the latest - QuickOpc 5.33).

When trying to browse for OPC servers on remote machines, the browser dialogs are taking an extremely long time to return anything.

I checked the forums for possible answers and have tried the following:

1. I verified that OPCEnum was working on the remote server and that DCOM configuration was correct on both client and server machines. Other OPC browsing software works fine.

2. I set EasyDAClient.SharedParameters.Machine.BrowseFromRegistry to "false". This caused nothing to be returned (usage of OPCEnum is failing).

3. I set my project up for 32-bit (x86) output and had the same results.

Wireshark showed that there was no network traffic between my local client machine and the remote server node I was attempting to contact so the failure occurs in OpcEnum locally, without interaction with the remote server at all.

I played around with settings until I found that as long as EasyDAClient.SharedParameters.Machine.ExecutionContext has the CLSCTX.CLSCTX_INPROC_HANDLER flag set the failure occurs. QuickOPC doesn't give me any specific error code useful stack trace so I can't track down the root cuase.


The following code (with the default ExecutionContext of 23 set) fails:

EasyDAClient.SharedParameters.Machine.BrowseFromRegistry = false;
EasyDAClient.SharedParameters.Machine.BrowseViaCategories = true;
opcServerDialog1.Location = "GTNAHOUAPP941";
opcServerDialog1.ServerFamilies = ServerFamilies.OpcDataAccess;
opcServerDialog1.Technologies = OpcTechnologies.Com;
opcServerDialog1.ShowDialog();


The following code (with ExecutionContext set to 21) succeeds and returns everything OK:

EasyDAClient.SharedParameters.Machine.BrowseFromRegistry = false;
EasyDAClient.SharedParameters.Machine.BrowseViaCategories = true;
EasyDAClient.SharedParameters.Machine.ExecutionContext =
(long)(CLSCTX.CLSCTX_INPROC_SERVER | CLSCTX.CLSCTX_LOCAL_SERVER |
CLSCTX.CLSCTX_REMOTE_SERVER);
opcServerDialog1.Location = "GTNAHOUAPP941";
opcServerDialog1.ServerFamilies = ServerFamilies.OpcDataAccess;
opcServerDialog1.Technologies = OpcTechnologies.Com;
opcServerDialog1.ShowDialog();

Any idea why the default ExecutionContext using CLSCTX_INPROC_HANDLER is causing a problem?

Thanks!

Alan

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

Moderators: support
Time to create page: 0.050 seconds