Read Blocking Function with Special Characters in the Alarm Name

Ignition
,
1

Hello,

I am trying to read a property of ana alarm however the alarm name has a special character in it.
Like, if an alarm is called Speed > 10 and I want to read the enabled property of this alarm using the readBlocking() function, I get an error stating Illegal character '>'.
How do I tackle this?

Thanks

2

Don't use special characters in names.

While you can argue that the designer doesn't stop you from using such names, so it should Just Work™, there are so many corner cases that you are just asking for trouble.

Make tag and object names compliant with java/jython method/attribute names for uniformly reliable results throughout Ignition.

3

AFAIK the only solution in this case is to read the entire configuration of the tag and then index into the alarm you want.

Which is another way of saying 'do what Phil suggests'.

4

system.alarm.queryStatus() will handle alarm names with special characters and can retrieve the runtime value of alarm properties.

Example code:

def get_alarm_property_value(alarm_path):
	provider_name, tag_path = alarm_path.split("]",1)
	provider_name = provider_name[1:]
	tag_path, alarm_name = tag_path.split("/Alarms/")
	alarm_name, property_name = alarm_name.split(".")
	source = "prov:{}:/tag:{}:/alm:{}".format(provider_name, tag_path, alarm_name)
	
	response = system.alarm.queryStatus(source=source)
	alarm_event = response[0]
	property_value = alarm_event.get(property_name)
	return property_value
	
path = "[default]_TEST_/Boolean/Alarms/PV > 80%.Enabled"
value = get_alarm_property_value(path)
print "path: ", path
print "value:", value

Solid advice considering built-in functions, like system.tag.readBlocking(), will outright fail when special characters are encountered... as identified by the OP above. However, I fall into the school of thought that the software should either prevent, actively warn against, or universally handle special characters without error.

As the software does not prevent the use of special characters in alarm names, someone will use special characters. So we should gracefully handle them if possible.

Unfortunately, reading tag configuration does not provide access to alarm runtime values, including resolved values for any properties with bindings. For that I think system.tag.read* and system.alarm.queryStatus are the only options. And the first will fail with special characters.

NOTE: As word of caution with retrieval of the runtime value for alarm properties with bindings. It is my observation that Ignition uses the "lazy" approach to resolving alarm property bindings. Bindings on properties not critical to determination of whether the alarm is active or not (e.g. label) only get resolved/updated when they are needed (e.g. on active, clear, ack events).
.

5

I don't precisely disagree, in principle, but do you have magic wand to loan to IA? In practice?

:man_shrugging:

6

I suggest the built-in functions that fail with special characters could/should be fixed by IA to gracefully handle special characters. Which seems entirely possible as an outside observer. IA seems oddly content to just let it be.
Other than that, we (integrators) are left to discover work-arounds by trial and error... like using system.alarm.queryStatus instead of system.tag.read* to read alarm property runtime values.

On a general note... Ignition best practices, and practices to avoid, are not always obvious to new users or even long-time users. I appreciate the the software is not too restrictive (allows enough rope to hang yourself with) but have thought from time to time that some sort of tunable analyzer that would detect and warn of discouraged practices (like special characters in alarm names), while advising of best/better practice would be handy. Leaving compliance optional.