Invalid Key warning - Parameter definition in template view in perspective

I am trying to create a template for a tank UDT in perspective. When I add a UDT as a parameter in the template,as an object and bind it with an instance of the tank UDT , to define the object and delete the binding after the tags are defined (as explained in IU course UDTs and Template Views - Views as Templates ( , I get Invalid key error for all the tags defined in the UDT as shown in the enclosed screen shot! What does it mean! How to get rid of it. Whats wrong with the parameter and binding ?


Is because the empty spaces between words.
Is a thing of PyObject keys I think, and since your forcing those names through a binding you have those warnings.

  • High Alarm Limit → Bad
  • High_Alarm_Limit → Good

oh! So will the binding not work because of this? Do I have to change the names?

TL/DR: Don’t use spaces in names. Anywhere.

The naming rule for tags and tag folders is pretty tolerant, including spaces and some special characters. At various points in your Ignition saga, you will want to deal with tag names and folders as properties of jython objects. That requires tag and folder names that conform to jython identifier rules. JSON, which is vital to Perspective, has basically the same identifier rules.

It would be an upgrade nightmare for IA to change the rule for tags, so you just have to enforce it yourself. If you keep forgetting, consider writing a script that will audit all of your tag names for this problem.

1 Like

That was a revelation to me! In vision everything worked fine with tag names/folder names with a blanks in between, but failed when tried the same on perspective!

Not difficult to remember the rule going forward, in fact its more intuitive to use valid coding variable names in tag names as well, but IA provided more generous and flexible rules for tag naming convention in vision! Sometimes when you give too many options and too much flexibility, things could be more confusing to end user!

However renaming tag names as per right convention worked for most of the vision screens except for few cases where indirect tag binding were used and alarms limits and alarm table with filters etc were used because of the expressions used there which can’t change to new names automatically.

But it could become a nightmare to change tag names in vision and perspective unless you test each and every screen! Perhaps a check list can be made where things can go wrong and we need to be careful and test screens again due to renaming of tags! (just a thought!).

However Its a practical issue that you may come across a need to rename some tags due to spelling errors or change of system names or anything like that, after you have completed the project!

Thanks a lot.