Disable a UDT Instance with system.tag.editTag attributes

Symptom and the Working Call

A tag value change script calls system.tag.editTag to disable a UDT instance in the Tag_Test folder. The script runs and raises no visible error, but the instance and its members stay enabled. The failing call was:

system.tag.editTag(tagPath="[default]Tag_Test/Tag1", overrides={"STATUS":{"Enabled":"false"}})

This call asks the tag system to override the Enabled property of a member tag named STATUS inside the instance at [default]Tag_Test/Tag1. If the UDT has no member called STATUS, the override has nothing to attach to and the instance itself is never touched. This is addressing, not logic. The call that disables the instance is:

system.tag.editTag(tagPath="[default]Tag_Test/Tag1", attributes={"Enabled":"False"})

The attributes argument edits the properties of the tag at tagPath. A UDT instance is a tag in its own right, so its Enabled property belongs in attributes.

Attributes Versus Overrides on a UDT Instance

editTag writes to two different layers of a UDT instance. The attributes dictionary applies to the tag named by tagPath. The overrides dictionary is keyed by member tag name, and each value is a dictionary of properties to override on that member only. The STATUS key in the manual example is the name of a member tag inside the example UDT. It is not a keyword and it does not mean "the status of the instance." Copying the example verbatim sends the edit to a member that most user-defined types do not contain.

For disabling the whole data type instance, use attributes. Reach for overrides only when the goal is a per-member change and you know the exact member name as it appears in the UDT definition.

Path, Key, and Value Checks

The number that matters here is not a rating but a string: the path and the keys have to match the tag browser exactly. The source contains one ambiguity to resolve before scripting. The script targets Tag1, while the instance the user wanted disabled is described as the data type Tag8. Decide which object is the UDT instance by reading the tag browser. If Tag8 is the instance, the path must end in Tag_Test/Tag8. If Tag1 is the instance built from a type called Tag8, the path is correct and only the argument was wrong.

Disable Procedure from a Value Change Script

1. Copy the instance path from the tag browser and paste it into the script so provider, folder, and name match character for character.
2. Put the value change script on a trigger tag that lives outside the instance being disabled. In the source setup the script sits on a separate tag, which is the correct arrangement.
3. Replace the overrides argument with attributes and pass the Enabled property directly.
4. Add a condition so the event disables on one trigger value and re-enables on the other, instead of disabling on every change.
5. Guard against the first execution when the tag subscription starts; tag change events fire on initialization, and an unguarded script disables the instance at every gateway or project restart.
6. Save, then write a test value to the trigger tag.

# Value change event on the trigger tag (outside the UDT instance)
target = "[default]Tag_Test/Tag1"

# Disable the whole instance
system.tag.editTag(tagPath=target, attributes={"Enabled":"False"})

# Re-enable the whole instance
# system.tag.editTag(tagPath=target, attributes={"Enabled":"True"})

# Disable one member only, leaving the instance running
# system.tag.editTag(tagPath=target, overrides={"MemberName":{"Enabled":"False"}})

Replace MemberName with the real member name from the UDT definition. A native Python boolean removes any doubt about string case; confirm your release accepts it before switching from the string form that worked.

Verification

1. Refresh the tag browser. A disabled instance shows its members with no live values and a disabled or bad quality indication.
2. Open the instance in the tag editor and confirm the Enabled checkbox is cleared on the instance, not on a member.
3. Check that no member shows an override marker if you used attributes. An override marker on a member means the edit went down one layer.
4. Toggle the trigger back and confirm the instance re-enables and values resume updating.
5. Read the gateway logs for script exceptions from the tag event during each toggle.

Recurring Pitfalls

• Script inside the instance it disables. A value change script on a member of the instance stops executing once the instance is disabled, so it cannot re-enable itself. Keep the trigger external.
• Editing the definition instead of the instance. Pointing tagPath at the UDT definition changes the type, which propagates to every instance built from it.
• Leftover member overrides. Earlier overrides attempts that did hit a real member stay stored on that member. Clear them in the tag editor so later instance-level edits behave predictably.
• Silent failures. A wrong key or path frequently produces no exception in the Designer. The gateway log and a tag browser refresh are the only reliable readback.
• Deprecated function. Check the scripting reference for your Ignition release; newer releases mark older tag-edit functions as deprecated in favor of a configuration-style call with its own argument structure.

FAQ