Resolving Ignition Bad_NotFound in Custom Tag Properties

Ignition 8.3.8 can display Bad_NotFound on custom internal tag properties while the parent Siemens S7-1500 tag continues to return the correct process value. This separates a custom-property registration fault from PLC communication, OPC UA subscription, and tag-value quality.

Symptom and ownership boundary

The term here means that Ignition cannot resolve a property requested from the tag model. It does not mean that the PLC item itself is missing. The same symptom occurred through both an OPC UA connection using a Siemens server and Siemens Enhanced Driver 1.3.9-SNAPSHOT (b2026070114). It also appeared across multiple data types, including DTL data, floating-point values, and arrays.

Check 1: Read the parent tag and expand its internal properties. Expect a correct parent value with Bad_NotFound limited to custom properties. If the parent is also bad, diagnose the device connection and item path as a separate fault before continuing.

Custom-property identification

The affected entries were added by Integration Toolkit 2.1.5 (b261812214); they are not native Ignition tag properties and are not defined by either Siemens connection method. The module declared Boolean controls such as republishEnabled, bulkScriptEnabled, divertEngWriteEnabled, and divertRawWriteEnabled, plus String destination or function properties.

Boolean properties were declared with Boolean.FALSE defaults. String properties such as republishToServer, republishToItem, and divertRawWriteToItem were declared with null defaults. A browser should therefore show an unchecked false value for a resolved Boolean default and a null or unset value for a resolved String default—not Bad_NotFound.

Do not remove the Siemens driver merely because the affected tags originate in an S7-1500. For isolation, disable or remove third-party modules one at a time in a controlled test system, then repeat the same property inspection. The property names disappearing with the declaring module identifies ownership; it does not repair registration.

Check 2: Match each bad property name to its module declaration. Expect the affected names to match the Integration Toolkit definitions rather than built-in Ignition or Siemens properties.

Property-directory registration

A property-model contributor controls when a property participates in a model. The property directory supplies the definitions by which Ignition resolves those properties. Registering definitions only through tag actor factory property-model contributor calls leaves the model able to reference a property that the fetching scope cannot resolve.

Register the module's static list of property definitions with the tag property directory as well as with the applicable PropertyModelContributor. The required directory call uses this pattern:

TagPropertyDirector.getInstance().register(<static list of properties>);

The static list must contain the same property instances used by the contributor. Audit the programmatic name, data class, default, translation keys, and list membership together. For example, the declaration shown for BulkScriptFunction uses the programmatic property name bulkScriptToServer; preserve that only if it is the intended persisted identifier. Renaming a programmatic property can disconnect existing tag configuration from the new definition.

Check 3: Fetch a tag model after directory registration. Expect every contributed property to resolve to its declared type and default rather than Bad_NotFound.

Gateway and Designer scope registration

Register the property definitions in both Gateway and Designer scopes. The Gateway owns runtime tag execution, while the Designer fetches and renders the editable tag model. A Gateway-only registration can leave the Designer unable to interpret properties that runtime code recognizes; a Designer-only registration leaves runtime consumers without the same definition set.

1. Build one authoritative static list containing all custom properties.
2. During Gateway module startup, register that list through TagPropertyDirector.getInstance().register(...) and install the Gateway-side property-model contributor.
3. During Designer module startup, perform the corresponding directory registration and install the Designer-side contributor.
4. Restart or reload the affected scopes according to the module deployment workflow, reconnect the Designer, and fetch the tag model again.

Re-registering a property is supported: the next tag-model fetch considers the new registration because the model is regenerated whenever it is fetched. There is no unregister operation. Avoid using repeated registration as a substitute for deterministic startup placement, since stale module code cannot remove definitions during the same running session.

Check 4: Open the same tag from a newly connected Designer and inspect it through Gateway-side access. Expect the same property names, types, and defaults in both scopes.

Defaults and dependent properties

Default resolution and conditional visibility are separate concerns. The module used dependent-property rules such as adding BulkScriptEnabled when WellKnownTagProps.TagType equals TagObjectType.AtomicTag, then adding BulkScriptFunction when BulkScriptEnabled equals Boolean.TRUE. These rules decide whether a property belongs in the current model; they do not replace directory registration.

Testing showed unresolved defaults as null in Ignition 8.3.2 and 8.1.47, while 8.3.8 displayed Bad_NotFound for properties that were not explicitly set. No property-model or default-resolution change was identified as the required correction. Treat the display difference as a diagnostic signal that exposed incomplete registration.

1. Inspect an atomic tag with no explicit custom-property values. Expect each applicable Boolean default to read false.
2. Set bulkScriptEnabled true. Expect its dependent function property to become part of the fetched model.
3. Set the control false again and refetch the model. Expect the contributor's dependency rules to control visibility without producing Bad_NotFound.
4. Repeat for engineering-write and raw-write diversion properties, checking each declared String destination as null or explicitly configured.

Check 5: Toggle each controlling Boolean and refetch after every change. Expect only its intended dependent properties to appear, with resolved quality and the declared default or configured value.

End-to-end commissioning verification

1. Check 6: Read representative scalar, DTL, floating-point, and array tags through the original connection. Expect their live values and parent qualities to remain correct.
2. Check 7: Expand each representative tag in the Designer. Expect no registered custom property to report Bad_NotFound.
3. Check 8: Compare an unset Boolean, an unset String, and an explicitly configured String. Expect false, null or unset, and the configured text respectively.
4. Check 9: Restart the Gateway module and reconnect the Designer. Expect the definitions to resolve without requiring a tag edit, proving registration occurs during startup in both scopes.
5. Check 10: Fetch the model after re-registering the same definitions. Expect the regenerated model to use the current registration, with no attempt to call an unregister operation.

Frequently asked questions