OPC UA Endpoints: Troubleshooting an Empty Client List

Jason IP2 min read
OPC / OPC UAOther ManufacturerTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Separate Discovery Failure from Endpoint Validation

An empty endpoint list can result from two distinct failures. The client may query the wrong discovery port and receive no servers, or it may discover a server but reject the returned endpoint URL as invalid. Diagnose these stages separately.

Observed result Evidence-supported cause Action
Dropdown finishes loading with an empty list The discovery URL omits the server port, so the client falls back to port 4840; no Local Discovery Server (LDS) is running there. Enter the target server's actual TCP port, or provide discovery through an LDS on port 4840.
FindServers returns a server, but GetEndpoints reports an invalid URL The returned URL contains an unencoded space in its path. Remove spaces from the server name/path or override the invalid returned URL.

Construct the OPC UA Discovery URL

The discovery URL requires a protocol-binding prefix, hostname or IP address, and the TCP port used by the target server. Its supported form is:

opc.tcp://<hostname-or-IP>:<TCP-port>/<optional-path>

If the port is omitted, the client falls back to the OPC UA discovery port 4840. For opc.tcp://srvdev, therefore, first determine whether an LDS is listening on port 4840. If not, discover the server directly by including its configured port.

Correct an Invalid Returned Endpoint URL

In the reported case, FindServers returned opc.tcp://SRVDEV:4981/In house Siemens. The space makes the returned text noncompliant with URL encoding syntax, so rejection by GetEndpoints is expected. Renaming the UA server so the returned path contained no spaces allowed the Full Demo Client to work.

If changing the server-generated URL is not practical, the SDK provides an override path: implement its callback and enable UseDnsNameAndPortFromDiscoveryURL so the client replaces the invalid returned address with the DNS name and port from the discovery URL.

Apply and Verify the Fix

  1. Identify the TCP port on which the target UA server is running.
  2. Enter a complete discovery URL containing the hostname or IP address and that port. Use port 4840 without an explicit port only when an LDS or the sole intended server is actually listening there.
  3. If FindServers succeeds but GetEndpoints rejects the result, inspect the returned URL for spaces. Remove spaces from the server name/path, or configure the callback override with UseDnsNameAndPortFromDiscoveryURL.
  4. Open the endpoint dropdown again and verify that it contains endpoints rather than completing with an empty list or an invalid-URL result.

FAQ

Why does opc.tcp://srvdev return no OPC UA endpoints?

Because no port is specified, the client falls back to port 4840. If no LDS or target server is listening there, discovery times out and returns no results.

Why does GetEndpoints reject opc.tcp://SRVDEV:4981/In house Siemens?

The path contains an unencoded space and is therefore invalid URL syntax. Remove spaces from the server-generated name/path or override the returned address through the SDK callback.

What does UseDnsNameAndPortFromDiscoveryURL do?

It lets the client replace invalid server-returned addressing information with the DNS name and port supplied in the discovery URL. Use it when the server's returned endpoint URL cannot be corrected directly.

Back to blog