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.

Issues connecting to DeltaV servers.

More
23 Jan 2019 21:25 - 23 Jan 2019 21:26 #7030 by support
I really appreciate your efforts. In fact, we might finally be getting somewhere. It is now likely that the there is server registration problem, but not on machine A as I thought, but on machine B.

I have made an improved version of the test tools. I would like to make you one more test. This time, the tools are capable of specifying whether they want DCOM to activate 32-bit or 64-bit server on the remote end (machine B ). Since the 64-bit registration appears to be broken (and 64-bit server activation is the default for 64-bit clients), we want to instruct the DCOM (in some of the tests) to explicitly activate the 32-bit server on the remote end. If that succeeds, we will know for sure what the problem is.

Can you please unpack and use the tools from the attached ZIP file, and then run following 4 commands, and post the output? All on machine A. Thank you.
ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F} CLSCTX_ALL,CLSCTX_ACTIVATE_32_BIT_SERVER
ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F} CLSCTX_ALL,CLSCTX_ACTIVATE_64_BIT_SERVER
ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F} CLSCTX_ALL,CLSCTX_ACTIVATE_32_BIT_SERVER
ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F} CLSCTX_ALL,CLSCTX_ACTIVATE_64_BIT_SERVER
Best regards
Attachments:
Last edit: 23 Jan 2019 21:26 by support.

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

More
23 Jan 2019 19:45 #7029 by MPick
Sorry for the delay, I had to coordinate the disconnect with our client as the system is running live (previous tests weren't as invasive).

I'm not able to physically disconnect the machine, so I created firewall rules blocking all traffic to/from other machines that either host the deltav server or have a mirror of it similar to the one we've been working on.

Here are the results:
C:\Users\[companyname]\Desktop\[companyname]\BuildOutput>ping 192.168.2.220
 
Pinging 192.168.2.220 with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
 
Ping statistics for 192.168.2.220:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
 
C:\Users\[companyname]\Desktop\[companyname]\BuildOutput>ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
CLSID: c3b72ab1-6b33-11d0-9007-0020afb6cf9f
Bitness: 32
*** Error: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
 
C:\Users\[companyname]\Desktop\[companyname]\BuildOutput>ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
CLSID: c3b72ab1-6b33-11d0-9007-0020afb6cf9f
Bitness: 64
*** Error: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
 
C:\Users\[companyname]\Desktop\[companyname]\BuildOutput>

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

More
22 Jan 2019 06:47 - 22 Jan 2019 06:48 #7015 by support
Thank you for the results and explanation.

In my view, the results now make it 100% clear that there is nothing wrong on the QuickOPC side. It is simply that the 64-bit processes cannot instantiate the DeltaV OPC server's main COM object; any OPC Classic client running in a 64-bit process would have the same issue.

This does not stop the investigation, but it rules out one area of options. It is a mystery, however, because the registry settings appear correct to me. And, when the server is "redirected" to machine B in this way, it should not matter whether on machine B it is a 32-bit or 64-bit server. But, because everything looks OK on machine A, and I am running out of ideas, I'd like to rule a somewhat far-stretched possibility that DCOM is attempting to activate the (probably non-existing) 64-bit server on machine B.

Would it be possible, for a short test, to shut-down machine B, or break the network connection between machine A and machine B? And then re-run ComCreateTest32 and ComCreateTest64? The intent here is to determine whether the "class not registered" comes from machine A (in which case the results will be the same as we had already), or whether the problem comes from machine B (in which case, breaking the connection should result in a different error - probably one of the RPC errors).

If you could do this, please also re-start machine A just before performing the ComCreateTest32/ComCreateTest64 tests. This is to assure that machine A won't use cached information from the time the connection to machine B was still fine.

Best regards
Last edit: 22 Jan 2019 06:48 by support.

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

More
21 Jan 2019 16:45 #7013 by MPick
Here's the request result:
C:\ ... \BuildOutput>ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
CLSID: c3b72ab1-6b33-11d0-9007-0020afb6cf9f
Bitness: 32
Success
 
C:\ ... \BuildOutput>ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
CLSID: c3b72ab1-6b33-11d0-9007-0020afb6cf9f
Bitness: 64
*** Error: Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
 
C:\ ... \BuildOutput>

Unfortunately I do not have access to Machine B.

The dependency is an SDK provided to us by another vendor for one of the instruments our system connects to. We have the source code for it, so we could in principle rewrite it, but the linking settings etc for the project have only been set-up for x64. It's not impossible but it wouldn't be a small task.

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

More
20 Jan 2019 11:24 #7007 by support
Hello,

I have created the little tool(s) I have mentioned. They are in the attachment.

Can you please open the command line prompt on machine A (the client machine) and run

ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}

and let me know what the results were. If you could do it on machine B (the server machine), then that would be a plus.

Can you also elaborate on the fact that is preventing you from switching the project to 32 bits - you wrote that you had a 64bit-only dependency. Those are pretty rare - is that some commercial product, or what is it, if I may know?

Best regards
Attachments:

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

More
18 Jan 2019 11:10 #6999 by support
Thanks again.

Actually, the registry settings indicate that on machine A, references to DeltaV server are simply forwarded to machine B by DCOM. So there appears to be no "synchronization", or a copy of the DeltaV server on machine A. Breaking the link to machine B should result in loss of connectivity right away.

But with that being the case, it is even more mysterious why 32 bits work and 64 bits don't, because the DCOM infrastructure in between fully hides these differences from the client, normally. And the registry appears OK.

Next step: I'd like to prepare two small programs, one 32-bit and one 64-bit, that would simply create an instance of the DeltaV OPC Server - that is, no QuickOPC involved, just plain C# or C++ code. And I will ask you test them out. The reason I want to do it is that I want to be absolutely sure whether the issue is something specific to QuickOPC, or can simply be attributed to the client program being 64-bits. Knowing that for sure, I would be able to direct the further steps without risking that I am going the wrong way. I will most likely prepare these programs over the weekend.

I have no reply from Emerson yet.

Best regards

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

More
17 Jan 2019 14:27 - 17 Jan 2019 20:48 #6994 by MPick
Correct. I do not have direct access to the 192.168.2.220 machine. Everything we've collected so far has been on machine A.

All fair points, still remote sessions are available if it comes to that.

Edit: Please let me know if there is any other information I can provide to help debug this.
Last edit: 17 Jan 2019 20:48 by MPick.

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

More
17 Jan 2019 06:30 #6993 by support
Can you confirm that this is how you understand your setup:

- You have machine A, where the QuickOPC client test resides, where you have performed the two tests (32/64 bits), and where you have made the registry exploration and registry exports. At the same machine, there is "one part" of the DeltaV OPC server.
- You then have machine B (192.168.2.220) where "the other part" of the DeltaV OPC Server resides.

Remote session is an option, but our own local system would be much much better. Locally I can install development tools like Visual Studio, and make small programs and experiments easily. That would have to be somehow prepared upfront, and still I cannot foresee what will be needed in the next step - likely resulting in multiple remote sessions etc.

Thank you

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

More
16 Jan 2019 21:06 #6992 by MPick
Ah right yes, one of the features of DeltaV is that you can install a sort of 'mirror server' locally on one machine that keeps itself sync'd with the remote 'real' server. I believe that they do this to avoid a more complicated DCOM configuration, but I haven't worked with it much. We've tried directly connecting to the remote server in addition to connecting to the local server to no avail.

Would remote access or running a version of the demo app with more verbose logging be useful? I would need to supervise a remote session as this is an active installation of our product, and could do it during normal business hours, Eastern Standard Time.

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

More
16 Jan 2019 20:08 #6991 by support
Thank you again.

I am now confused: The registry entries from Step 11 and Step 12 indicate that the server is configured to run remotely, on 192.168.2.220 (this is the kind of configuration where the client does not have to specify the remote machine - it "looks" like that it is local, and DCOM redirects the server activation and calls elsewhere).

Can you comment on that? I thought that we were troubleshooting the situation where the server and client resided on the same computer. If it is set up differently, please describe how.

Besides this open part, I have not yet discovered a problem with the server registration, so I still do not know the cause.

Best regards

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

Moderators: support
Time to create page: 0.164 seconds