Access UDT parameter in script

pturmel · September 2, 2019, 6:22pm

A job for a derived tag, perhaps, if the member node ID is available? Basically a different write path.

Gaurav.Shitole · December 9, 2020, 6:04am

Regarding this,

I have a UDT instance called T103 (basically I have them from T101 to T120) and under UDT members are as follows:
T103
-ID
-Name
-Status

I tried this approch, reading T103.value in tagPath and later used tagPath=system.util.jsonDecode(str(tagPath)). However when I print this, I get blank dictionary. hence tagPath.keys() doesn’t work either. Am I doing something wrong here?

Also tried eval() instead of jsonDecode its the same {} output. Thanks in advance

Kevin.Herron · December 9, 2020, 12:12pm

@Gaurav.Shitole

This thread is specifically about reading structured values over OPC from the built-in Siemens server. I can’t tell from the information you’ve provided if that’s what you’re trying to do or if you should be starting a new topic with more details.

Gaurav.Shitole · December 15, 2020, 5:03pm

Hi Kevin,

No I was trying to read a Memory parameter (which will later be converted into OPC) present inside UDT.

tyler.bennett · December 20, 2023, 10:56pm

I came across this thread while considering the same question but on v8.1.35. though I'd add some v8.1 relevant detail.

One oddity I observed is that you can use {ABC} style parameter references in a "value changed" script on a member tag in a UDT instance but that appears to resolve the the value of the parameter the last time the UDT instance was restarted, not its current value.

Update: Looks like this documented behavior. Still adding my comment here as a breadcrumb for the next person who forgets the right place in the documentation to find this info.
(Tag Event Scripts - Ignition User Manual 8.1 - Ignition Documentation)

Modern Approach

Parameters values can be accessed as dictionary values. The benefit of this approach is that value changes to UDT parameters will be reflected in subsequent calls. In most cases, this modern approach is preferable. Thus, if the script needs to access the most recent parameter values on a UDT, and the parameters can change through a means other than editing the UDT (which would restart the tag), then this approach should be used.

If trying to access the value of a parameter named "myParam" from a Tag Event Script within the UDT, the script would look like:

# Reminder: "tag" is a built-in argument on all Tag Event Scripts. Accessing the "parameters" key on the tag argument will

# provide access to all UDT parameters.

paramValue = tag[ 'parameters' ][ 'myParam' ]

Legacy Approach

In Ignition release 7.9 and prior, UDT parameters could be access in Tag Event Scripts with the familiar curly brackets approach. Thus, if trying to access the value of a parameter named "myParam" from a Tag Event Script within the UDT, the script would look like:

paramValue = {myParam}

A large caveat with this approach is that value changes made to the parameter ("myParam", in the example above) would not be reflected in scripts until the UDT was restarted. UDT parameters are pre-compiled, which in this case means value changes are mostly ignored until the UDT is restarted.

In all cases, the modern approach above is preferred.

tyler.bennett · December 20, 2023, 11:42pm

I rediscovered this bug/behavior today in v8.1.35. Cross-posting here as it has some relevance. It seems Ignition attempts parameter resolution even on commented lines and will fail silently if there is something in curly brackets that is not a valid parameter.