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.

Extreemly Slow in Browsing OPC servers on a machine

More
13 Sep 2014 05:22 #2284 by support
I am glad you have found it. I have inspected our code, and what we actually do is as follows: We first attempt to enumerate the servers using the OPCEnum service. We then also attempt to do the same using remote registry (which usually quickly fails, but is provided as a backup method). We then COMBINE the results from the two methods (there are reasons to do it this, especially locally with combined 32/64 bit environment, but that would be too complex to explain here).

It usually works fine, but as it turned out in your case, when the remote registry access is allowed and is slow, it can unnecessarily affect the whole browsing.

We will re-think this approach, and fix it in the next version. Thank you for finding the issue.

Besides disabling the remote registry on the computer(s), you can also disable it inside QuickOPC, which would make it behave like other OPC clients you have. To do, change the static property of EasyDAClient before you make calls to it, as follows:
EasyDAClient.SharedParameters.Machine.BrowseFromRegistry = false;
I hope this helps
Best regard
The following user(s) said Thank You: Vishweshwar_Kapse

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

More
12 Sep 2014 07:53 #2281 by Vishweshwar_Kapse
Ok i figured out why this was happening..!!

Yesterday I read that the OPC Client needs the Remote Registry service to be turned on so that it can access data from the server's Registry.

So I Started the Remote Registry Service from both the Client and the Server Machines..

I guess this was when the issue started..

Now I have the Remote Registry Service running on the Client Side and when I Stopped the Remote Registry Service at the Server Side The QuickOPC Client responded quickly enough (Less than a second earlier it took nearly 3 minutes)...

I dont know why this is happening..

But this fixed the Issue.

Probable Bug in the QuickOPC Client..

Maybe Someone should look into this.

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

More
12 Sep 2014 07:34 #2280 by Vishweshwar_Kapse
I am using the ASP.NET application but the QuickOPC Client is in my WCF. The WCF is working under the UserAccount to which I have all the Right Permissions. And If OPCenum is not accessible and if RemoteRegistry read was the only way read the OPC Servers then how is it that OPC Clients from other Companies are working so quickly??

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

More
12 Sep 2014 07:17 #2279 by support
It is hard to tell - it looks like there must have been some other changes as well, because if you say that disabling the firewall, i.e. reverting the changes does not help, then something else must have changed that you are not reverting.

Anyway, here are some notes:

- Opening port 135 is generally not enough for DCOM. A broad range of other ports need to be open, for RPC calls. See e.g. www.opclabs.com/resources/technology-opc/opc-videos/opc-dcom .

- Because the BrowseServers call finally succeeds, but much slowly, I suspect that what happens is that for some reason, OPCEnum is not used, and QuickOPC then resorts to attempting a browsing based on (remote) registry access, which is slower. Try to check the launch and access permissions on OPCEnum in DCOMCNFG, and correlate them with the user account that you use to run your app.

- Be aware that when running ASP.NET, the user account is not *your* account, but depends on various IIS settings. Therefore the situation with permissions and DCOM calls is very different. Try to experiment with the account that is used to run the Web app (normally it is the account configured for the "App Pool" to which the Web app is assigned to).

None of this explains (or fully explains) why other client works, but it is worth looking at.

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

More
12 Sep 2014 06:49 #2277 by Vishweshwar_Kapse
Hi

We intend to purchase the QuickOPC Client SDK for developing a client APP. It was working fine till today. We have recently made changes.
1. Enabled the Windows 7 firewall on both the client and the server machines.
2. Added the firewall exception to the port 135 on the client machine and also added the opcenum.exe to the firewall exception

Now we are having a problem, The QuickOPC client is taking TOO MUCH time more than 3 Minutes to return from the BrowseServers(OPCServerMachineName);(Verified in Debug mode of Visual Studio) but it does return the list of OPC servers on the Remote Windows 7 machine.

FYI: OnClick of a button on my asp.net page I am able to read the values of tags FINE.

I have tried disabling the firewall and tried to do the same, it still takes too much time. It never took so much time to return from this call. before i made the above mentioned changes

I have tried browsing servers on the DemoNet App that was installed when i installed the QuicOPC Client API. SAME ISSUE.

FYI: This problem does not occur with other OPC Clents the OPC ServerBrowse results come up immediately. Can some one tell me why this is happening.

I REALLY WANTED TO BUY THE QUICK OPC CAUSE ITS SO EASY TO USE.
I HOPE THIS ISSUES DOES NOT HAVE TO CHANGE MY DECISION.

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

Moderators: support
Time to create page: 0.047 seconds