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.

Getting error: No method available to convert ProgID to CLSID

More
09 May 2022 20:44 #10845 by tblong
Results here of testing the remote OPC server using QuicOPC v5.63.183.1. As before, we adjusted our INI file with the same permutations of configuration changes. Instead of getting "No method available to convert ProgID to CLSID" consistently, we are now getting "The RPC server is unavailable." This occurs when we use the ProgID only or included both the ProgID and CLSID in the server descriptor. If we include only the CLSID in the server descriptor then again we revert back to getting the "No method available to convert ProgID to CLSID" error. We also noted seeing the following, as we also did with the old QuickOPC version, the following in the Windows System event logs:
DCOM got error "2147746131" from the computer <RemoteComputerName> when attempting to activate the server: {13486D51-4821-11D2-A494-3CB306C10000}


We also performed an additional test. Since the OPC Expert client is able to connect to this remote OPC server, and OPC Expert has a "mimic" mode in which it connects to remote servers and re-exposes them as a local DA server, we configured OPC Expert as such and it runs as a local DA server on the same machine as our application using QuickOPC. Before testing this setup with our QuickOPC based client, we first confirmed that the other OPC client from Integration Objects was working. The Integration Objects OPC client was able to connect to the local OPC Expert DA server and create a group with one item ID successfully. So from this standpoint, the local OPC Expert DA server is working as a proxy to the real remote ArchestrA DA server. We then attempted to point our QuickOPC based service to this now local DA server. No luck. In this setup, QuickOPC reports the new error "Class not registered (0x80040154)".

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

More
05 May 2022 06:01 #10843 by support
Hello.

Please rebuild your project with QuickOPC 5.63 build 183.1 or later (available on www.nuget.org, and as an installer on our Web page), and retest.

Best regards
The following user(s) said Thank You: tblong

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

More
03 May 2022 16:48 #10842 by tblong
For sure, trying to provide as much detail as I can since we all know OPC classic stuff can get spicy with all the unique environments encountered. You all truly do provide excellent support, one of the main reasons we went with QuickOPC.

Yes, I am using nuget to reference all the QuickOPC assemblies.

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

More
03 May 2022 16:42 #10841 by support
Thanks for clarifications.

No, I do not think that the web proxy can be related to this.

You might be facing a bug in QuickOPC 5.63. Let me do the changes/fixes I mentioned, and make a new build. I will post here again when it is ready. Possibly tomorrow, but I cannot promise that.

Are you referencing the assemblies from the Setup installer, or via NuGet packages?

Best regards
The following user(s) said Thank You: tblong

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

More
03 May 2022 11:40 #10840 by tblong

Have you tried running your Windows service (temporarily) under some regular user account (such as your own), or running the browsing code from "normal" app (not a Windows service|)?

We have attempted running our Windows service under the same user account used to remote into the system. This account did work with the OPC clients however not when used by the service. We did not test with this account though to the extent shown in my first post in the thread.

It can still be DCOM configuration/permissions issue if your Windows service was running under account different from what the other, working OPC clients are using.

We ran the two OPC clients using the same account as setup in the service. These two OPC clients were able to browse and subscribe to items successfully whereas the service was not able to do so with the same account.

A potential important detail I left out. The machine on which our service (and the two working OPC clients) resides also has a web proxy configured for all outbound http/s traffic leaving the local network. Is there any chance that QuickOPC would pick up and use a machine wide web proxy setting?

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

More
03 May 2022 06:44 #10839 by support
Hello,
thanks for the detailed problem description.

If you are connecting to a remote server, the OPCEnum on the client machine is not relevant/used. And it is also OK for it to be at Manual, because DCOM will start it when needed.

Have you tried running your Windows service (temporarily) under some regular user account (such as your own), or running the browsing code from "normal" app (not a Windows service|)? It can still be DCOM configuration/permissions issue if your Windows service was running under account different from what the other, working OPC clients are using.

Saying that, we have made recently improvement, but also bug fixes into this precise area of code in QuickOPC - but, releasing them is planned with QuickOPC 2022.2 which is not going to be soon. If the suggestions above fail to give resolution, I will look into back-porting these changes into the version your are using.

Best regards

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

More
02 May 2022 14:37 - 02 May 2022 14:40 #10838 by tblong
We have a Windows service application using QuickOPC v5.63.162 and are trying to connect to a remote OPC DA server which is the ArchestrA FSGateway product with its ProgID=ArchestrA.FSGateway.2 and CLSID={19d98a61-b3ca-4143-0088-35464d714ea0}. Our app supports the Intrinsic Component config within QuickOpc so below is our INI file showing the permutations of configuration changes attempted:

[OpcLabs.BaseLib.Runtime.InteropServices.ComManagement:Configuration:SecurityParameters]
TurnOffCallSecurity=false  # tried both true/false
EnsureDataIntegrity=false # tried both true/false
AllowImpersonateClient=false # tried both true/false
UseCustomSecurity=true # tried both true/false
 
[OpcLabs.EasyOpc.DataAccess.EasyDAClient:SharedParameters:MachineParameters]
BrowseViaCategories=true # tried both true/false
BrowseFromRegistry=true
 
[OpcLabs.EasyOpc.DataAccess.EasyDAClient:SharedParameters:MachineParameters:ComInstantiationParameters]
ExecutionContext=23 # tried both 23 & 21
 
[OpcLabs.EasyOpc.DataAccess.EasyDAClient:SharedParameters:ClientParameters:ComInstantiationParameters]
TurnOffActivationSecurity=false

Along with manipulating the settings above, we have also tried giving QuickOpc the server descriptor which includes the ProgID only, CLSID only, and both the ProgID and CLSID of the OPC server. All of these attempts have resulted in us seeing the error "No method available to convert ProgID to CLSID (E_FAIL.0xC0049039)" in the data change event handler following the initial subscription attempt. When we set BrowseViaCategories=false and used the CLSID only I would have expected a different error since OPCEnum should not be used in this scenario; instead forcing a registry search for the CLSID we provided. This was not the case, and we received the same error in the subject of this post. Another interesting thing about the host machine our application lives on, is that the OPCEnum Windows service is in Manual mode but not running. Since we are connecting to a remote OPC server here, should we care at all about the state of the OPCEnum Windows service on the local machine?

Weirdly enough, there are two OPC clients (OPC Expert and the other from Integration Objects) on the same machine as our application, both "run as" the same account as our Windows service application which are able to connect and subscribe to items on the remote OPC DA server. Not sure where to go next since two unrelated OPC clients are working leading me to believe firewall, DCOM, and associated permissions are all correct.
Last edit: 02 May 2022 14:40 by tblong.

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

Moderators: support
Time to create page: 0.081 seconds