Filtering on Alarm status tables

Ignition
,
1

Hello,

I suspect the answer is that what I need isn’t possible based on my forum searches, but I’m trying to avoid making duplicate tags.

I have three gateways. All talking on gateway network and each has the other two set up as remote tag providers so that some data can be displayed on the other projects as there are some processes that crossover and information is needed by different operators.

I’m struggling with alarming though. On gateway A project I have an alarm status table filtered to its own Provider. But I want a few alarms from a gateway B to also appear. It looks like I can have both providers listed, but I don’t want all of them. And I can’t filter by display path to get the remote tags because that will get rid of the local alarms. I need some more sophisticated filter: “Provider = A OR (Provider = B and displayPath = “XXX”)”
Am I stuck creating the tags I need on gateway A just to get them to show on the alarm table?

2

Looking at the structure of the pyAlarmEvent object provided to the table's filterAlarm method, I see there is a sourcePath which is a qualified path object. Based on the Source Path filtering example in the docs, that qualified path should have the provider included in it.

Write a custom method in your library for filtering the alarm table and call it from the table's filterAlarm method. In that project library method, inspect the sourcePath and displayPath as per your expected logic to filter accordingly.

Something like

def myCustomAlarmTableFilter(self, alarmEvent):
    """ """
	provider = alarmEvent.source.firstPathComponent
	displayPath = alarmEvent.displayPath
	if provider == "SOURCE A":
		return True
	
	if provider == "SOURCE B" and "x/y/z" in displayPath:
		return True
	
	return false
1 Like
3

Thanks! I am so close to making it work. At first I was using alarmEvent.get(‘source’), but that seemed to return something that maybe wasn’t actually a string. but your “firstPathComponent': clue got that working. I had the same problem with .displayPath, but I got that one working by converting it to a string.

Is there a reason you recommend putting the method in a project library and not just putting these few lines on the table’s filterAlarm method directly?

4

It's going to be a QualifiedPath object, which you can just turn into a string, or you can use some of the richer methods available on it.

It's not a big deal in this case, but if you ever want to re-use your filtering logic in another place, it's a lot easier if it's in the project library. If you go all the way down the rabbit hole, there's also ways to edit project library scripts in external editors and some other niceties. In general power users on the forum will advise you to put all non-trivial logic into the project library.

2 Likes