There has been no specific resolution for this. We would need a copy of the server here for analysis and possible resolution.

If you are on QuickOPC 2020.3 or later, you can *try* to set .InstanceParameters.EnableNativeClient on your EasyDAClient object to 'false' (right after constructing the EasyDAClient object). There is absolutely no guarantee it will fix the problem; but what it does is that it switches the internal implementation to a quite different one, which uses different techniques, so there is some chance it would work. I would be interested in knowing the outcome.

Regards

Thank you.

In case your app is already 32-bit, I really do not know what the cause could be. I think it is probably something simple, but there are so many things to check that it cannot be done via "I ask you to check this, the customer checks that and explains the result" in a loop - that would take incredibly long.

Can't we get a temporary remote access to the machine, under their supervision (VNC or similar), to look around and investigate? Or, of course, if there is a way to install the server on our computer and it would exhibit the same behavior, we can do it as well - but need to get an operational server software for that.

Regards

Michael,

I do not understand how this reply relates to the problem reported. In fact, I hardly understand any piece of it.

This is my understanding of the issue we had: We were trying to address was the fact that QuickOPC could see the server, but was not able to browse its items or do read/writes etc. - it always ended up with "Class not registered".

My suggestion was to build your app for 32-bits only (x86 target CPU), because there is a high chance the server does not register itself well for the 64-bit world. There was no reply to this from your side, so I assume you have not tried.

I do not know what is the cache file they are referring to, or what they mean by "...the DeltaV server address, type and name had to be added manually to the cache.". Also it somewhat weird that the XML file refers to things like "XiServer" and "http://10.122.150.170:58080/xiservices/serverdiscovery". This seems to be related to the so-called OPC Express interfaces, latter dubbed Xi and latter dubbed OPC.NET, which is completely different from any other OPC spec, and was, at one time, forced by a big player onto OPC Foundation standardization committee and that, besides Emerson, practically nobody is using. QuickOPC does *not* support OPC Xi at all, and never will. It is a dead thing. But it is possible that the server supports OPC Xi and OPC DA at the same time. It is then, however, important not to mix their connection info. OPC Xi is basically a Web service interface (hence the "http:..." URL in their cache), while OPC DA is COM based and servers are identified by the (machine name and) ProgId/CLSID.

Best regards

I am not saying it should not be able to browse at all. I just want to get the facts first, and so far it does look the problem may have to do with the 64-bit-ness of your app - because it is, in fact, running in 64-bit process, and I have no indication that other servers are.

Before we start thinking about other possibilities, it is important to verify that the hypothesis (that is, it is the 64-bitness of the client that causes it) is correct. To do so, can you re-build your project to be strictly 32-bits (target x86 and not AnyCPU or x64), OR use the CORFLAGS on the EXE you already have to force it to 32 bits, and then retest to see whether the problem has disappeared?

Best regards