UDT parameter names containing special characters

Can anyone help me with the correct way to ensure the correct parameter name (with period “.”) is passed/parsed through a system.tag.readBlocking /.writeBlocking command so I can update the parameter individually?

Background…

I inherited an Ignition 8.1 Perspective-based system where the UDT parameter names include a period (“.”) character of the format “Z.9 Some Name”. I need to update a particular parameter for several UDT instances and had been unsuccessful implementing system.tag.readBlocking and .writeBlocking. I implemented system.tag.getConfiguration and system.tag.configure successfully in a script however as @nminchin wrote here, this is A Bad Idea (confirmed) as it has decoupled all those instances’ parameters (all 33 of them, when I only want 1 to change) from the UDT parameters.

The issue I was having with path (copied from the parameter in the tag browser by right-clicking and selecting “Copy Path”) is that the period (“.”) acts as a property delimiter and I get complaints about having more than one…

(note these are running in the Designer Script Console scope)

system.tag.readBlocking("[default]someTag/Parameters.Z.9 Some Name")

Traceback (most recent call last):
  File "<input>", line 1, in <module>
ValueError: Invalid path element '[default]someTag/Parameters.Z.9 Some Name': Token PROPERTY_SEPARATOR found after property name.

Trying to escape the second period with a backslash (“\”) results in complaints about out-of-place path elements. I’ve tried various iterations of escaping and also in various quote configurations…

system.tag.readBlocking("[default]someTag/Parameters.Z\.9 Some Name")

Traceback (most recent call last):
  File "<input>", line 1, in <module>
ValueError: Invalid path element '[default]someTag/Parameters.A\.4 Some Name': Token PATH_SEPARATOR found after property name.

The couple of solutions I have are:

  1. Redefine all the UDT parameters without special characters. I don’t wish to do this as that will break (I have 33 Parameters to rename for that UDT) a whole lot of things I will then have to unbreak.
  2. Roll back (yay for backups :slight_smile:) and work out how to use system.tag.readBlocking and .writeBlocking so as to only disturb the 1 parameter I need.

So as stated at the top, it would be much appreciated if someone could assist with the correct configuration of the system.tag.readBlocking / .writeBlocking command format to cope with the period (“.”) in the name.

Thanks in advance,

Patrick.

P. S. and if it’s some absurdly simple solution staring me in the face that I should have seen, I also apologise in advance for missing it!

Do (1).

IA has been fixing bugs that allowed such situations to be created and your situation will only get worse.

Ideally, you should make all names in your project, including folder and atomic tag names, usable as programming identifiers. Letters and digits and underscores, not starting with a digit.

2 Likes

I agree with Phil. Break things and fix them now, not later when you have even more things to break.

1 Like

As others have said that’ll be your best way to go. Worth mentioning that some Regex search and replace likely can make quick work of converting things. Just be careful of course.

While I agree the right solution is to remove the dots, to answer the question itself about how to write to those params, I'm sure you can use system.tag.configure to do it. You just need to provide the skeleton json for the UDT instance, along with your UDT parameter, and ensure you use the merge option.

Firstly, thanks to all for your comments and sage advice, it is much appreciated.

I am working on something to do with this (‘cos I’m a stubborn $#!t) and will get back to you in due course.

Option 1 (remove the offending character(s)) as promulgated by all is looking more appropriate (and perhaps easier) by the minute!

Regarding the actual query :grin: , thanks nminchin, I did use the “merge” option. I used the lists/dictionary structure supplied by system.tag.getConfiguration which (for me) is a list with an single element, which is the configuration as a dict with a nested parameters dict. I changed the required parameter’s value in the nested dict and wrote the config back with system.tag.configure. I’m guessing the whole nested parameters dict may be classified as being the value changed for the tag so it wrote the whole parameters dict structure back and somehow that carries through to all of the parameters dict structure elements as being changed.

By this I meant bare bones skeleton. Too hard to produce with mobile, but I'll get you an example tomorrow. Literally just the name keys though

As in like this:

a = {
  "name": "New Instance",
  "tags": [
    {
      "name": "Folder A",
      "tags": [
      	{
      		"name": "New Tag",
      		"tooltip": "Hello World!"
      	}
      ]
    }
  ]
}
system.tag.configure('[default]', tags=a, collisionPolicy='m') # "m" is critical else you'll wipe the rest of the config

for a udt instance that looks like this:

You just need the name structure to get to the tag you want to edit

1 Like