Visual Indicators for Overridden Alarm Properties in UDT Instances
J
Jacque Trahan
Situation
We encountered an issue during tag imports from our PROD to DEV Ignition servers, where tag instances were not retaining their own property values. Instead, they were inheriting the corresponding properties from their UDT Definitions.
The situation occurs as follows:
A user creates a new UDT Definition.
The user then creates a UDT Instance based on that definition.
The alarm is overridden on the instance, but not all alarm properties are changed — for example, Priority remains the same as in the definition.
Later, the user updates the Priority in the UDT Definition.
After exporting and importing tags, the instance alarm now takes on the updated Priority from the definition instead of maintaining its intended instance-level behavior.
This has caused some of our alarm priorities to shift unexpectedly (e.g., from Low to Critical) because the Priority property was never written into the instance’s JSON.
This also impacts the WebDev module, as the missing property in the JSON results in a null value being returned, even though the actual property on the instance should be Low. The underlying issue is that when alarms are overridden, not all alarm properties are serialized into the instance JSON.
We will be updating all alarm configurations on our side moving forward to ensure that all relevant properties are explicitly set when overrides are applied.
Feature Request
We would like to request a feature that visually indicates which alarm properties are truly overridden at the instance level versus those still inherited from the UDT Definition.
This would help integrators clearly identify which properties will appear in the instance JSON and which will continue to reference the UDT Definition values, reducing confusion and preventing unintended configuration changes during export/import operations.
Photo Viewer
View photos in a modal
Log In
J
Jacque Trahan
Concern Regarding Alarm Setpoint Inheritance and Tag Import Behavior
This issue raises significant concerns regarding tag export and import behavior in Ignition, specifically in how instance-level alarm properties inherit values from their UDT Definitions.
If a client creates a UDT Definition with a default alarm setpoint value of 0, and subsequently instantiates tags based on that definition, those instances, and are overridden, will initially retain the default value sense they were not changed. However, if the UDT Definition’s default setpoint is later modified to 100, and the tag configurations are later exported and re-imported, all existing instances, specifically overwritten alarms, that previously held the default value of 0 will now automatically inherit the new default of 100.
This behavior can unintentionally propagate configuration changes to multiple instances, potentially altering alarm thresholds, masking critical alarm conditions, or generating false alarms. Such changes could have operational, safety, and compliance implications.
This situation raises an important question of accountability:
Who assumes liability for any damages, losses, or safety incidents resulting from default property values being implicitly updated during tag import operations?
To mitigate this risk, a clear mechanism should be implemented to differentiate and preserve instance-level alarm property overrides during export/import processes. Additionally, users would greatly benefit from visual indicators that identify which alarm properties are explicitly overridden versus those still inherited from the UDT Definition.