Bridge an OPC DA 1.0 client to a 2.0 server

Why does an OPC DA 1.0 client never see a 2.0-only server?

The two generations of the OPC Data Access specification expose different COM interfaces, and a 1.0 client asks for the older set: a server that registered only the 2.0 interfaces never answers, so the connection fails and the server stays out of the browse list.

The split sits at the COM interface level. For asynchronous updates, a DA 1.0 server uses the older OLE data-advise mechanism, and a DA 2.0 server calls the client through COM connection points; the 1.0 specification did not implement the callback interfaces that 2.0 and later clients expect. Discovery differs as well: a 1.0-era server registers by name, and a 2.0 server also registers under the OPC component category for its version, which is how a 2.0 client finds it. The classic DA line runs 1.0, 2.0 and 3.0, and 3.0 is the latest of the classic versions. No interface substitutes for another, so software that links the two sides has to speak both.

What symptoms point to a version mismatch instead of a DCOM problem?

The signature is one-sided: the client cannot browse or attach to a server that other clients on the same network reach fine, and nothing in the client's own settings changes it, because the client asks for interface set 1.0 while the server registered only 2.0.

Match your case against this list:

• The server never appears in the client's browse list while other tools on the network see it: points to a version or component-category mismatch, so check the client's supported DA version first.
• The server appears and the connection fails when the client asks for the interface: points to the client requesting the 1.0 set the server never registered.
• The server's own test client reads values fine on the same node: points to the client side, and it clears DCOM as the first suspect.
• The link worked until a server upgrade: a newer release is often stricter about versions, so read its documentation before you reconfigure anything.
• Reinstalling the client or re-registering the server changes nothing: a reinstall changes neither side's interface version, so stop spending downtime on it.

Which DA version does your server actually support?

Read the server's documentation for the supported Data Access specification versions before you buy or install anything, because many servers register both the 1.0 and 2.0 interface sets, and a dual-version server needs no new software at all.

Three places carry the answer. The product documentation states the supported versions. The registration itself carries it: a server registers under the OPC component category for each DA version it supports, so a category-aware browse on any client machine shows what is on offer. The vendor confirms both in one sentence when the documentation is silent.

Do the same for the client. An older client states its supported DA version in its documentation or release notes, and that number decides everything downstream. Check the upgrade path too: a newer server from the same vendor is usually stricter about versions, so an upgrade can turn a working link into this exact failure.

Which fix do you pick: dual-version server, a bridge, or a migration?

Pick in this order: a server that already registers both interface sets needs no new software, a bridge on the legacy client's own machine gets data back the same day and adds one DCOM hop, and a platform migration is the permanent answer, scheduled as its own project.

A server that registers both interface sets wins outright: no new software, no new failure point, no extra license. When the server is 2.0-only, the bridge is the repair. It reads from the real server as a 2.0 client and registers downstream as a 1.0 server, the legacy client attaches to the bridge, and the client's own version never changes.

Migration replaces the legacy client with a current platform and removes the version problem at the root. It is a project: confirm the new platform's documented DA support, rebuild the screens and alarms, test on live data, and cut over with a rollback point.

Recommendation: Check for dual-version support first. If the server is 2.0-only, install a bridge on the legacy client's own machine, configured as a 2.0 client upstream and a registered 1.0 server downstream, and keep the legacy client at its current release. Schedule the platform migration as a separate project with its own test and rollback plan, and treat it as the permanent answer when the legacy platform is no longer supported.

How do you install the bridge on the legacy client's machine?

Install the bridge on the same machine as the legacy client, add the 2.0 server as its upstream connection, then point the client at the bridge's registered 1.0 server name. That keeps the 1.0 side local and leaves exactly one DCOM hop on the network.

Work in this order:

1. Record the versions: the legacy client release and its documented DA version, the server product and its documented DA version, and the Windows build on both machines.
2. Install the bridge on the legacy client's machine, following the bridge's own documentation.
3. Add the real server as the upstream connection, speaking DA 2.0. If that server sits on another machine, configure DCOM launch, access and authentication on that hop only.
4. Browse the upstream server from the bridge and map the items the client needs. Keep item IDs and data types identical to the upstream server so existing tag references stay valid.
5. Choose the update rate and deadband on purpose. State the process need first, then set the bridge below it; the example below shows the arithmetic.
6. Confirm in the bridge's documentation and configuration that the exposed server side registers as DA 1.0, and note the registered server name.
7. In the legacy client, add an OPC connection and select the bridge's registered 1.0 server name, not the original server.
8. Bind one tag first and confirm value, quality and update before you bind the full list.

Example: a 1.0-era client needs 30 tags from a 2.0-only server, so what do you install?

A packing-line PC runs a supervisory client released in the DA 1.0 era and needs 30 tags from a 2.0-only server on another machine; the server's documentation lists 2.0 only, so you install a bridge on the client PC and map the same 30 item IDs.

The tag count and update rate here are illustrative. The line needs 24 process values and 6 alarm flags: 24 + 6 = 30 tags. The process tolerates a 2,000 ms update, so the bridge update rate is set to 1,000 ms, half the tolerance. That leaves room for one missed cycle and still lands inside the window.

The server runs on a separate machine, so the hop count decides the install location. With the bridge on the client PC, the client-to-bridge connection is local COM and crosses no network, and the bridge-to-server connection crosses one: 0 + 1 = 1 DCOM hop. With the bridge on a third machine, both legs cross the network: 1 + 1 = 2 hops, plus a second authentication surface to maintain. The decision: install on the client PC, map the 30 item IDs with unchanged names and types, and the client sees a registered 1.0 server on its own node.

How do you prove the bridge before you release it?

Run 5 checks and compare the same item in 3 places, because a bridge that shows a value is not yet a bridge that shows the right value at the right time with the right quality.

1. Read the same item in the upstream server's own test client, in the bridge, and in the legacy client. All three must agree in value and quality.
2. Force a change at the source and time how long the client takes to show it; on the example layout the measured delay must stay under the 2,000 ms process tolerance. Pick an item that moves nothing, or wait for a safe state on the line.
3. If the client writes back to the PLC, test a write on a non-critical item and confirm the write arrives at the device, not just at the bridge.
4. Break the link on purpose: stop the upstream server or pull the network cable. The client must show bad quality within 500 ms of the break instead of a stale good value, and the link must recover without a manual restart.
5. Reboot the client node and walk away for 15 minutes. The bridge must start before the client connects, and the connection must come back unattended within 60 s of both services starting.

What goes wrong on OPC bridge installs?

Most bridge failures trace to 6 recurring mistakes: the bridge sits on a third machine, the exposed side speaks 2.0, item paths get renamed, quality codes get restamped, the DCOM hop went untested on the target Windows build, or the service runs unwatched.

Each has a direct fix:

• Bridge on a third machine: adds a second DCOM hop and a second authentication surface. Keep it on the client node unless a documented reason moves it.
• Exposed server side speaks 2.0 only: the legacy client still sees nothing. Verify the exposed interface version in the bridge's documentation before you buy.
• Renamed or re-rooted item paths: some bridges restructure the address space. Compare item IDs one-to-one against the client's existing tag references.
• Restamped timestamps or remapped quality codes: check what the client receives when the upstream device is offline, because that is what operators will see.
• Untested DCOM on the target Windows build: newer Windows tightens DCOM authentication defaults, so test the remote hop on the machines you actually run.
• An unwatched service: the bridge is one more link between the process and the operator, so set it to start automatically and monitor it like the server it is.

When is replacing the client the better answer?

Replace the client when the bridge would outlive its welcome: the legacy platform is unsupported, the tag list keeps growing, or the site already runs clients that speak OPC UA. Then you schedule the cutover as a project with a tested rollback point.

Confirm the new platform's documented DA support before you commit, because the version it supports is in its documentation. Rebuild and test the screens, alarms and any legacy driver behavior before cutover. Keep the bridge running as the fallback until the new client has run on live data long enough to trust, then remove it. If the debate includes writing your own data client, Write a Modbus client or use an OPC server for a small HMI covers that choice. Before you retire the old panel, check the PLC serial protocol before replacing a legacy HMI. If the new supervisory layer speaks OPC UA, set up an OPC UA server in CODESYS for HMI clients shows the server side. If the cutover also adds a shop-floor status screen showing the same values to the line, our industrial displays present data from your own Android app; they are notice screens, not HMIs, and they take no video input.

Questions