Reading alarm Display Path in script console

I have a bunch of UDT tags as well as a bunch that are non-UDT. Many of these tags have alarms, and I have set values for the Label and Display Path on those alarms using the properties available in the Expression builder, such as “{fullItemPath}” or “{displayPath}”.

I want to be able to check my work and verify all alarms are labeled the way I want, so I have this script that I run in the Script Console to tell me.

tags = system.tag.browseTags("Folder1/Miscellaneous",sort="ASC",recursive=1)
for tag in tags:
	if tag.isFolder() == False:
		tagDefs = system.tag.getAlarmStates(tag.fullPath)
		for tagDef in tagDefs:
			if tagDef.alarm != '':
				for prop in tagDef.getAlarmProperties():
					if prop.property == 'name':
						alarmname = prop.value
					if prop.property == 'label':
						alarmlabel = prop.value
					if prop.property == 'displayPath':
						alarmdisplay = prop.value
				
				print "Tag:		", tag.fullPath
				print "Label:		", alarmlabel
	  			print "Display Path:	", alarmdisplay

This works great for the alarms on tags in a UDT, and it prints out the actual paths that are represented by “{fullItemPath}” and “{displayPath}”. But on the non-UDT tags, it just prints “{fullItemPath}” and “{displayPath}” instead of the values they represent.

What syntax do I need to use to view the actual paths that are being represented in the Label and Display Path, instead of just the variable name? I have tried using quotes, no quotes, [.], and [~], but all just print the same string I typed in (or selected).

Where do you define those values on non-UDT tags? As far as I know, only UDT tags can have custom parameters. So for loose tags, you need to define the displaypath directly.

I am not defining the values, they are available in the tag editor. I select the binding icon next to Label or Display Path, then I select Expression. There is a curly braces icon you can click which will give you these options. I assumed these were built in to Ignition, is it more likely that someone else in my environment created these options?

Can you show what you have the displayPath bound to or set to on an non UDT alarm tag?
Also you should set your variables to blank in the beginning of your loop or you will just keep printing the last value of the last found value.

		for tagDef in tagDefs:
			alarmlabel = ''
			alarmdisplay = ''
			alarmname = ''

Here is a screenshot of the configuration for this alarm. You can ignore Label, I haven't tried fixing that yet. Display Path has one of the available selections from the Expression editor.

Here is what the Script Console prints . The first line is tag.fullPath and the second line is the value of displayPath in getAlarmProperties().
image

Yeah I am seeing the same thing trying to use those dynamic properties in the displayPath field of an alarm.
Might be a bug as it looks like the expression isn’t being evaluated when called like this.

@Paul.Scott

1 Like

Honestly ( and unfortunately), it looks like system.tag.getAlarmStates is working as intended. It’s returning configurations of alarms, which in this case means the literal text in the expression. The value attribute on one of those alarm properties should not give you an evaluated version of the property value

I’m uncertain how the script is getting evaluated versions for the expressions in UDTs, but not on non-UDT tags. I can’t seem to replicate that behavior.

Regardless, properties set to use those built-in alarm references like {displayPath} should correctly evaluate when an alarm event occurs (which, to my knowledge, is generally when we start evaluating those expressions).

1 Like

Thank you everyone for your help with this. Is there another way you can think of that would allow me to test the evaluated versions of these strings for all tag alarms?

Unfortunately not - the problem is we can't "know" what your expression is without parsing it...and we can't parse it without having the "context" of an actual alarm to evaluate within...and if we faked an alarm context, then you might get unexpected values on the evaluation. It's a real chicken and egg problem.

Someone else tried to do pretty much what you're trying to do and documented their efforts here:

And created a feature request:

1 Like

Got it, thank you!