Troubleshooting Ignition OPC UA Tag NodeId Lookup Errors

The Ignition connection reached the server, but the first monitored item failed with BadNodeIdUnknown because the tag NodeId was case-mismatched. In this setup, matching the tag’s case to the spelling shown by Ignition’s Quick Client resolved the issue; the endpoint URL and the NodeId are separate inputs to an OPC UA client.

Separate endpoint selection from the tag NodeId

An OPC UA endpoint identifies where and how a client connects to a server. A NodeId identifies an addressable node within that server’s address space. A client may display both values together, but they are not one path, and a tag’s NodeId does not belong after the endpoint URL as though it were a web resource path.

The attempted value combines an endpoint-like string, opc.tcp://10.40.120.205:49320/iaopcua/None/, with a tag reference. Do not infer the correct endpoint path from the tag name. Select the endpoint exposed by the Ignition server through the client’s endpoint discovery or configured server endpoint, then enter the NodeId in the client’s item or subscription field. Endpoint discovery and NodeId entry are separate checks.

For the reported tag, the candidate NodeId form was ns=1;s=[Device1]PROGRAM:SFX0908_HMI_01.L_MACHINENR. Here, ns=1 identifies a namespace index, s indicates a string identifier, and the text after it is the identifier. The client library may require this standard NodeId notation, a browse path, or a library-specific item string. Use the format expected by the C#/.NET client API; do not assume that another server’s item syntax is interchangeable.

Check the selected Ignition endpoint first

Read the endpoint URL selected by the client and compare it with the endpoint offered by Ignition. If the client cannot connect, or reports endpoint, security, or session errors before creating a monitored item, resolve that connection layer first. A valid endpoint connection does not prove that the requested NodeId exists. If the session is established and the error appears while creating the monitored item, continue to NodeId validation.

1. Use the client’s endpoint discovery or configured endpoint list to select the Ignition server at the intended host and port. The reported server address was 10.40.120.205:49320; verify the actual endpoint in the running client and server configuration rather than appending a guessed tag path.
2. Connect and confirm that the client has an active session to Ignition. If connection or session establishment fails, inspect endpoint selection and the security/authentication settings before changing the tag identifier.
3. Once connected, browse the server address space or inspect the tag in Quick Client, then use its exact NodeId for the monitored item.

Read the monitored-item StatusCode

The text “creation of data monitored item failed” is not a diagnosis by itself. Read the accompanying StatusCode. In this case it was BadNodeIdUnknown, directing the investigation toward the supplied NodeId: the server could not resolve that identifier as a node in the address space. That differs from an endpoint connection failure, which happens before a valid monitored item request can be processed.

Use the full StatusCode rather than the exception headline. If it is not BadNodeIdUnknown, follow the actual code’s meaning; a rejected NodeId and a rejected monitoring configuration require different corrections.

Compare the complete NodeId character by character

OPC UA NodeIds are exact identifiers, and string identifiers are case-sensitive. A difference between uppercase and lowercase characters can name a different node. The reported C# client initially used ns=1;s=[Device1]PROGRAM:SFX0908_HMI_01.L_MACHINENR; the operator then matched the case shown in Quick Client, after which the first monitored item stopped raising the exception. The final resolution confirmed that case sensitivity was the cause.

Copy or transcribe the NodeId from the connected Ignition address space rather than reconstructing it from a PLC tag label. Compare every character, including the device name, program name, punctuation, underscores, and capitalization. The source configuration text supplied for the guessed identifier may not show the exact case used by Ignition, so the live browse result is the deciding reference.

Do not copy the namespace index from another OPC UA server. The Siemens client configuration used namespace index 6, while the KEPServerEX connection used index 2; those values belong to their respective servers and do not establish Ignition’s index. For the Ignition tag under investigation, ns=1 was the reported candidate. Confirm the namespace index against Ignition’s current NodeId or namespace table when browsing, connecting to another server, or rebuilding the configuration.

Resolve each tag from the Ignition browse result

Use this decision sequence for the C#/.NET client. Keep endpoint selection, node identification, and subscription creation distinct so each failure points to a specific layer.

1. Read the connection state. If the client has no session, return to endpoint discovery and connection settings. If it has a session to Ignition, continue.
2. Read the item’s full StatusCode. If item creation reports BadNodeIdUnknown, treat the NodeId as unresolved and continue to the address-space browse. If another StatusCode appears, diagnose that specific service result instead of changing capitalization blindly.
3. Browse to the target tag in Ignition. Record the complete NodeId and its namespace. If the displayed node differs from the supplied item string, replace the string with the exact browsed value in the format required by the client library.
4. Compare casing and identifier type. Confirm that the identifier is a string NodeId if the client notation uses ns=1;s=, and compare the entire identifier text character by character. Correct case, punctuation, or namespace only where the browse result shows a mismatch.
5. Create one monitored item. Test a single known tag before loading the remaining items. If that item is accepted, test each additional tag independently; a success for one item does not validate the others.

The Siemens and KEPServerEX connections already worked in the same application, but their endpoint and item naming conventions were different. Preserve the client’s server-specific configuration instead of applying another server’s namespace index or item-path pattern to Ignition.

Verify accepted items and live values

Acceptance of a monitored item confirms that the server resolved the requested node, but it does not by itself prove that every intended tag was addressed or that values are arriving correctly. Validate the endpoint, item result, and returned data for each tag. The source reports that matching case fixed the first item; a second item still failed at that point, so it required its own exact-case correction and retest.

1. Session check: the client shows an active connection to the intended Ignition endpoint, not merely a formatted URL.
2. Node resolution check: monitored-item creation for the browsed NodeId succeeds without BadNodeIdUnknown.
3. Identity check: the item’s complete NodeId, namespace, and case match the live Ignition browse result.
4. Data check: the client receives the expected tag value and reports a good data status while the monitored item is active. If item creation succeeds but data quality is not good, inspect the returned status and tag state separately.
5. Per-tag check: repeat the browse-to-subscription comparison for every tag. The final verification is a successful monitored item and expected value/status for the last tag tested.

Ignition OPC UA NodeId FAQ