You are welcome. I am glad it works

Be not afraid to ask more questions. It is a useful feedback for us, too, to learn about where are the common stumbling blocks.

Best regards
Z.

If BrowseNodes does not throw an exception, the UAEndpointDescriptor is correct for sure.

What is likely incorrect is the UANodeDescriptor.

I suggest that you
- use BrowseDataNodes instead (that will save you from having to specify browse parameters which is not that easy), and
- start browsing from the "Objects" node, which is what you get when you pass UAObjectIds.ObjectsFolder (in OpcLabs.EasyOpc.UA.AddressSpace.Standard namespace) in place of the node descriptor.

Best regards

And more about the Node IDs:

opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2.../webframe.html#Node%20IDs.html

and other useful stuff:

opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...e.html#Server%20Endpoints.html

opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...me.html#OPC-UA%20Security.html

The first parameter is the target OPC UA server (endpoint URL).

The second parameter, though it may look like URL, is a Node ID - an equivalent of Item ID in OPC Classic. In OPC UA, it differs in two main things:
- it contains a namespace qualification - that's the "nsu=" part
- it may be a string (like Item ID in OPC Classic), or an integer, or a GUID, or opaque (byte array).

You best bet is to figure out the Node Id is by browsing, again. Interactively, you can use e.g. the Connectivity Explorer in QuickOPC, to connect to the Kepware Server and see which node IDs it has.

Typical OPC UA gotchas:
- I think OPC UA is by default disabled in KepServer - you need to explicitly enable it.
- Make sure the firewall does not block the port used for communication on either the server or client side.
- When secure communication is used, server uses a certificate provide by the client to authenticate the client. QuickOPC will generate its own certificate and KepServer will initially reject it. But you will find it in the OPC UA configuration of KepServer, and "trust" it - and it will work then.
- Conversely, client needs to tust the server certificate when secure comm. is used. More on that later if that becomes an issue.

I suggest you first try the Connectivity Explorer. That's easier than writing the code. When any issues are resolved, coding should not be such a big deal. The Connectivity Explorer will also help you in determining what the Node IDs are etc.

Regards

Assuming that you want to do roughly the same as you do now with OPC DA, then:

Browsing for nodes: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...%20for%20OPC%20UA%20Nodes.html

Reading values: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ing%20just%20the%20value2.html

Best regards

The error that's in the log (0x800706ba) is "The RPC server is unavailable.". So that's a good thing - it's now clear that all clients behave the same - resolving it for one would resolve them all.

The behavior you described with stopping the runtime is somewhat weird but I cannot reliably comment on it, since I do not have that much experience operating KepServerEX. I would also note that clients often have auto-reconnect capabilities, in which case if you stop the server, it can get started later again.

Here are your options as I see that:

a) Make sure everything is installed correctly on the OPC server side. If you run the OPC Quick Client directly there, does it work well? Things like OPC proxies/stubs might be corrupted - reinstall of the server, or of OPC Core Components (opcfoundation.org/developer-tools/developer-kits-classic/core-components/ ) would probably help in such case.

b) Contact Kepware support. You might be pleasantly surprised - AFAIK, these guys are quite responsive.

c) Do as (b), but with even more data in hand. That would involve collecting the OPC communication logs using so-called OPC Analyzer. It's a bit more work, but not really that much. See articles in our Knowledge Base:
kb.opclabs.com/How_to_use_OPC_Analyzer and
kb.opclabs.com/Collecting_information_for_troubleshooting

d) Give up on OPC Classic, switch to OPC Unified Architecture (OPC UA). This is a newer set of OPC specs that does not rely on Microsoft COM. KepServerEX supports it, and our QuickOPC supports it as well. You certainly won't get the problem you are getting now, with OPC UA - but that's not to say it's without problems of its own.

Best regards