Split an OPC DA URL into remote server and server name

Where each portion of the URL goes

Classic OPC DA URLs follow one documented shape, the opcda://[Hostname]/[ProgID] form published by the OPC Foundation. Three parts, two slashes:

• The scheme before ://, here OPCDA, selects classic DA. It is never entered in either field.
• The host between :// and the next / identifies the computer. An IP address or a Windows computer name works.
• The ProgID after the host slash is the name the server software registers under Windows on that computer. OpcEnum or a registry read on the host lists the exact string; copy it from there when in doubt.

Drop the trailing slash when you enter the ProgID. It closes the URL and belongs to neither value. Clients label the fields differently: some say Host or Node for the remote server, some say ProgID for the server name, and the mapping holds either way. If the client you are configuring is a dedicated panel, HMI panel as OPC client: can it read tags without a PLC covers what a panel client asks of the server it connects to.

What each symptom points to

• The web page loads but the OPC connection times out. The page rides HTTP on one port. OPC DA rides DCOM and RPC: TCP 135 reaches the RPC endpoint mapper on the host, and the data connection then lands on a dynamic port, 49152 to 65535 by default on current Windows. OPC DA has no single port to forward, so a firewall that passes the page can still block the client. Serving tags to a browser over HTTP is a separate route again; reading PLC tag values from an HMI panel web server covers that route.
• A standalone test client connects but your client refuses. Re-split the endpoint and compare the two fields first. Then compare the Windows account each client runs under, because DCOM checks the account of the process asking for the server.
• The browse list comes back empty. Browsing asks the host's OpcEnum service and DCOM to list registered servers before any connection exists, a path that can fail while a direct ProgID connection still works. Enter the ProgID by hand and test.
• The connection opens but items read zero or fail. Activation is done and item access is the blocker. Take an item identifier that read in the test client and enter it character for character.

All four symptoms assume OPC DA is the right route for the job. If that choice is still open, writing a Modbus client or using an OPC server for a small HMI compares the two routes.

Checks to run first

1. From the client PC, open the module's web page at 192.168.0.110. If it will not load, the fault is the network path, the subnet, or an address conflict, and no OPC setting will fix it.
2. On the same PC, under the same Windows account, run the standalone OPC test client the module supplier recommended. Connect with host 192.168.0.110 and ProgID Bender.OPC.Server.FTC470XET.DA.1, then read one item whose value you can watch move.
3. Write down the exact item identifier and the endpoint string the test client reports. The endpoint is what you split into the two fields, and the item is the acceptance test for your own client.

Worked example: split OPCDA://192.168.0.110/Bender.OPC.Server.FTC470XET.DA.1/

Inputs:

• Endpoint as the standalone test client reports it: OPCDA://192.168.0.110/Bender.OPC.Server.FTC470XET.DA.1/
• Device address on the plant LAN: 192.168.0.110
• Format rule: opcda://[Hostname]/[ProgID], the documented classic DA shape

Rule in words: cut the string at ://, then cut again at the first / after that. What sits between the two cuts is the host. What runs from that cut to the trailing slash is the ProgID.

Arithmetic, one cut at a time:

1. Before ://: OPCDA, 5 characters. Scheme, selects classic DA, entered nowhere.
2. Between :// and the first /: 192.168.0.110, 13 characters, matching the device address that answers on the LAN. This is the Remote Server.
3. Between the first / and the trailing /: Bender.OPC.Server.FTC470XET.DA.1, 32 characters, one dotted name. This is the ServerName.

Cross-check: 5 + 3 for :// + 13 + 1 for the host slash + 32 + 1 for the trailing slash = 55 characters, the length of the endpoint as reported.

Result:

• Remote Server: 192.168.0.110
• ServerName: Bender.OPC.Server.FTC470XET.DA.1

Decision: one host segment plus one ProgID segment is the clean case, so enter the two values, connect directly by ProgID, and call the job done when a live item reads and its value tracks the process. If your endpoint carries extra segments after the ProgID, the two-field split above stops applying: read the exact ProgID from the host with OpcEnum or the registry there, and ask the server vendor what their extra path adds.

After the fields are set

Keep the test client open beside your client while you work through the rows; the comparison between the two is the diagnostic.

The decision

Recommendation: Enter the host from the first segment and the ProgID from the second segment of the endpoint in their two fields, exactly as the table above shows, and connect directly by ProgID. Judge success by one live item read whose value changes with the process, made on the same PC and Windows account where the standalone test client already works. Change DCOM or firewall settings only after the test client connects on that PC and your client still refuses, then compare the two clients' accounts and launch permissions, and take the exact endpoint, the error text and both versions to the software vendor's support channel if they match.

Questions