Using Tag Parameter in UDT

I have a UDT that I generated by browsing the tags in the PLC. I’ve added a parameter that is named idx it’s datatype is Integer.

The AGITATOR tag has the OPC Item Path set to

ns=1;s=[PLC]Formulas[{idx}].HEADER.AGITATOR

The INGR_CALCTYPE tag has the OPC Item Path set to

ns=1;s=[PLC]Formulas[{idx}].STEP[1].INGR_CalcType

When I create a new tag from the UDT and set the idx the tags under the HEADER folder have the {idx} replaced with the value of the parameter. However none of the tags under STEP\STEP_1_ get the paramter replaced. The tag in the browser shows {idx}.

Is there a limit to the number of levels that Ignition traverses when a tag is created?

no limits afaik.

Does the instance of the UDT show any errors if you right click the tag and choose View Tag Diagnostics?

Can you show us screenshots of the UDT properties and then the UDT instance that is showing this?

From the PLC side looks like you have nested arrays of UDTs. Formula is an array of one UDT that contains another array of STEP UDT. What is the Calc_Type? Is that a supported datatype and not another root UDT type?

One test, go to the OPC browser and drag that one tag into the tag provider and make sure the generated syntax matches what you’re using.

CalcType is a string tag. The UDT was created by browsing to the PLC and creating the structure from tag in the PLC.

The PLC Tag is an array type of a UDT Formula.

The Formula UDT has a 2nd UDT with tag members of Integer, Boolean, Float, String datatypes

Step is an array of a 3rd UDT with tag members of Integer, Boolean, Float, String datatypes

Formula[1..99].HEADER.TagA
...
Formula[1..99].HEADER.TagF

Formula[1..99].STEP[1..99].TagA
...
Formula[1..99].STEP[1..99].TagF

I’m not sure why the Step

You can when the tag was created the system did not replace with parameter placeholder {idx} with the value of the parameter.

Can you show how the OPC Item Path is configured for the STEP UDT?

Digging a bit deeper I found an issue but not sure how to fix it.

The tags under HEADER show up that they are linked with a parameter

For the Step tags it doesn’t recognize the paramter no blue link

if you go to the UDT definition, locate the tag in the tag browser, and right click on the INGR_CalcType and select Edit (raw). Do you see opcItemPath as an object or a value?

It should be something like this

{
  "opcItemPath": {
    "bindType": "parameter",
    "binding": "..."
  }
}

if it’s just a string value, then the binding might not be active.

That usually means that setting (including curly braces) was created by writing that bare string to the tag property, via scripting or JSON import. As @vtran points out, the effective binding has bindType and binding keys in the JSON.

(somewhat off topic)
i retain that this is a really really weird design choice by ignition and that bare string values containing brackets should automatically default to having bindType parameter

1 Like

I'm pretty sure the interpretation of curly braces as parameters is done strictly in the designer tag editor, for human-entered strings. I suspect it doesn't actually exist elsewhere. Other interactions with the tag configuration are expected to supply properly parsed objects.

(If so, this is unlikely to be conveniently changed as you desire.)

1 Like

The only place that it actually matters for me is human entered strings, if I’m producing OPC definitions from a script I can just set them all to default bindtype

(By human entered i mean human copy pasted)

I don't recall any repeatable demonstration of this particular situation that came from a string entered into the tag editor by a human.

edited to clarify i meant ‘human copy pasted json’, which is a footgun i’ve seen people run into a few times on this forum and elsewhere.

Meaning JSON that was hand-edited to include a curly-brace parameter without the bindtype? If so, yes, that is operator error.

You mean when I use Notepad++ to search for Formulas\[[0-9]+\] and replace with {idx}?

Thank you. Now I under that there needs to be another step to set up the binding as I sheepishly thought the system was keying off the existence of {}. The syntax highlighting in the editor was “lying” to me.

That is exactly what happened. I’ll go back and fix it.

Knowing is half the battle©

1 Like

if you’re using Notepad++, probably can use Regular Expression to change it to binding real quick

you can find

"opcItemPath": "(.*{.+}.*)"

and replace with

"opcItemPath": {"bindType": "parameter", "binding": "$1"}

That will find anything opcItemPath with curly braces in their value string and convert to the binding object format

As always, make a backup of the UDT just in case.

3 Likes