Configuring Ignition OPC UA Endpoints per Deployment Mode

A Dev deployment mode that points an OPC UA connection at a simulated PLC server while Prod points the same connection at the real PLC's server needs one thing: a mode-specific definition of that connection with a different Endpoint. The gateway runtime resolves per-mode endpoints. What failed is the Gateway web UI. Builds before 8.3.1 did not allow editing the endpoint of OPC connections configured in other deployment modes. 8.3.1 fixed that, and the fix exposed a second bug: the Endpoint menu item is hidden whenever the active definition is anything other than core. That second bug is fixed in 8.3.4. On affected builds, the config API or direct edits to the on-disk resource files produce a working per-mode endpoint.

Which gateway build decides whether the Endpoint override is editable?

Read the version and build string from the gateway's status overview before planning anything. The build determines whether you configure this in the UI or go around it.

Check: record the exact build string. If it is 8.3.4 or later, go to the UI procedure. Otherwise, use the workaround sections.

How does the gateway pick which endpoint the OPC UA client dials?

In Ignition 8.3, each OPC UA connection is a configuration resource. It has a core definition and optional definitions for each deployment mode. The gateway's configured deployment mode selects the active definition. Fields not defined in the mode definition inherit from core. The request path runs as follows:

1. A tag subscribes through a named OPC connection. The tag stores the connection name and the OPC item path (node ID), not the server address.
2. The gateway resolves that connection name against the active definition for its current deployment mode.
3. The gateway's OPC UA client opens TCP to the host and port in that definition's endpoint URL.
4. The client negotiates the secure channel (security policy, message mode, certificate exchange) and opens a session.
5. The client creates monitored items for every tag path using that connection. Values flow back on the same session.

The connection name must be identical across core, Dev, and Prod definitions. Only the endpoint, and the security settings tied to it, should differ. Tags then need no change between modes. They follow whichever server the active definition dials. This design only works if the simulated server exposes the same node IDs as the real one; that pitfall is covered later.

Check: open the connection in the Gateway web UI and identify which definition is marked active. On an affected build, an active Dev definition is exactly the condition that hides the Endpoint menu.

Is each OPC UA server reachable from the gateway host?

Prove the physical and transport path before touching configuration. A mode override pointed at an unreachable host looks identical to a misconfigured override.

1. Collect the full opc.tcp:// endpoint URL for each server from that server's own configuration.
2. From the gateway host, test TCP reachability to each host and port. On Windows, use Test-NetConnection -ComputerName <host> -Port <port>. On Linux, use nc -vz <host> <port>.
3. Confirm that the hostname each server advertises in its GetEndpoints response resolves from the gateway host. A server that answers discovery with an internal hostname the gateway cannot resolve fails after discovery, even when the IP in your URL is reachable.
4. Note which security policies and message modes each server offers. The simulator and the real server often differ, and the mode definitions must reflect that.

Check: both TCP tests succeed from the gateway host itself, not from an engineering laptop, and both advertised hostnames resolve.

How do you set the Endpoint override in the Gateway UI on 8.3.4?

1. Open the OPC UA connection in the Gateway web UI. Keep the connection name as the tags already reference it.
2. Leave core pointed at whichever server you treat as the default. Many sites point core at production so an unconfigured mode never talks to a simulator.
3. Select the Dev definition, or create it if the connection has no Dev definition yet.
4. Open the connection's menu and select Endpoint. On 8.3.4 this item appears even while the gateway runs in a non-core mode.
5. Enter or discover the simulator's endpoint URL. Pick the security policy and message mode the simulator offers.
6. Save. Repeat for any other mode, such as QA or Prod, that must differ from core.

Check: reopen the Dev definition and confirm the endpoint shows the simulator URL while core still shows the production URL.

What are the workarounds on 8.3.1 through 8.3.3?

The runtime honors a per-mode endpoint on these builds. Only the UI path is blocked when the active definition is non-core.

Check: pick one option per gateway and record it. Mixing UI edits and file edits on the same resource makes the effective definition hard to trace.

How do you duplicate the core connection into a mode via the API or on disk?

1. Take a gateway backup before any direct edit.
2. Read the full core definition of the OPC UA connection. Use the config API, with resource paths taken from the API documentation served by your gateway build, or the resource file under the core configuration directory.
3. Create the Dev definition with the same resource name. Via the API, post the copied configuration to the Dev mode. On disk, copy the resource into the Dev mode's resource directory at the same relative path it occupies under core.
4. Change only the endpoint URL, plus the security policy and message mode if the simulator's differ. Leave the connection name untouched.
5. Restart or reload the gateway configuration as your build requires, so the file-system change is picked up.

Check: the Gateway UI lists a Dev definition for the connection whose stored endpoint is the simulator URL, even if the UI will not let you edit it on this build.

Why do tags fault or go bad after the endpoint changes between modes?

Check: the connection reports Connected in Dev, and a sample tag from each area of the tag tree shows good quality against the simulator.

How do you prove Dev and Prod each reach their own server?

1. On the Dev gateway, confirm the configured deployment mode is Dev and the OPC UA connection shows Connected.
2. On the simulator, force a distinctive value on one simulated tag. Confirm the matching Ignition tag shows that value with good quality.
3. On the simulator's session or diagnostics view, confirm a client session exists from the Dev gateway's IP address.
4. On the Prod gateway, confirm the configured deployment mode is Prod, or core if Prod inherits. Confirm the connection's effective endpoint is the real PLC server.
5. On the real PLC's OPC UA server, confirm a session exists from the Prod gateway's IP address, and none from the Dev gateway.
6. Compare one live PLC value, read from the controller's programming software, against the same tag on the Prod gateway. Matching values and timestamps prove Prod dials the real PLC while Dev stays on the simulator.

Frequently asked questions