Get Tag's Custom Parameter In Gateway Tag Change Script

Ignition
1

I am trying to read a UDT’s custom parameter in the Gateway Tag Change Script.

I have tried both

  • system.tag.getConfiguration(tagPath)[0][‘parameters’][‘CommandName’].value
  • system.tag.readBlocking(tagPath + “.Parameters/CommandName’)

Both return the UDT’s parameter but they do not substitute any values in the parameter, such as {InstanceName}

Example returned value = Parameter[CommandName]={datatype=String, value={bindType=parameter, binding={InstanceName}}}

Inside a specific tag change script, those parameters return the substituted parameters, not the raw parameter. Is there a way, from inside a global tag change script, to get the substituted parameter values?

2

  1. UDTs have parameters and custom properties. Which one are you using?

  2. What is the tagPath that you are trying to target? Is it the UDT instance or the UDT definition?

3

  1. I am trying to target the UDT’s parameters, as seen in the UDT definition below

    image
    image1722×936 51.7 KB

  2. I am targeting the UDT instance, each instance has their own parameter values (overridden at the instance)

4

Parameters cannot have bindings in the base definition. They can only have bindings when nested as instances in an outer UDT. In other words, parameters are expected to be independent of each other.

1 Like
5

Oh! That is odd, because what is shown in the screenshot above seems to work if I pull those parameters while inside the “Value” tag change script.

This works as I expect in the tag’s change script (not gateway change script), with the returned value having the substitutions.

cmdName = tag['parameters']['CommandName']
nodeName = tag['parameters']['NodeName']

I will rework my idea with the assumption the parameters are not supposed to return the substituted values

6

Try creating custom properties of the UDT with bindings to the parameters, and read those.

7

I’ve gotten into a habit of always making a “parameters” tag folder in my UDT that just has direct bindings to the UDT parameters rather than reading the parameter itself.

This also comes in handy when nesting UDTs because some parameters share names but have unique suffixes to avoid parameter conflicts when nesting, but scripts with relative tag paths can be used if the “parameter tag” is used instead.

2 Likes
8

Thanks for the suggestion! I went your route because it just makes it more apparent in the UDT structure verses using custom properties like pturmel suggested.

Both accomplishes the same result