Breadcrumbs and descritive alerts

I’ve seen in few latest Ignition videos on Youtube talking about breadcrumbs and more descriptive alarms/alerts…

Can somebody please explain, how can that be done in Ignition?
I’ve seen this one post about breadcrumbs, but…
And I didn’t find anything about more descriptive alarms. How are you guys doing it?

I handle descriptive alerts with a predictable tag structure and relative pathing on my alarms.


Here you can see the overall site 1-35-48-20w3 has a folder called metadata with long and short (descriptions) and the individual di/channel 7 has it’s own metadata folder. We want a descriptive alarm like 1-35-48-20w3 Transfer Pump Faulted. So we set up the alarm display path like so:

A refers to the site’s metadata folder and B to the metadata folder of the value itself.
As long as we maintain the structure, we can move this pattern around and always end up with a descriptive alarm.
Does that help?

Thank you for the response.
I see (I think) what you’re doing there. You do this for every input/tag for which you want the alarm.
OK, I do that also, but without expressions or metadata. I just put desired text in the Display path (long description) and Alarm name (short description).
But what I don’t understand is how you put this alarm text generated by expression (in you case) for example in the left down corner (like in the picture I posted from the Ignition video).
Especially when there is more than one alarm active for more that one device… :interrobang:

Ahh I understand, but can you provide the link to the video? You’ve just got an image.

https://youtu.be/KANiXgw-Q5s?t=3m26s
Here it is one…
They are talking about it (descriptive alarms & breadcrumbs) in this video series, but they don’t show/tell how to do it.

I attended this webinar and it was said that this demo would be available to attendees but it was not…
Maybe someone from Ignition team knows something about it?

1 Like

Bump… :punch:

What we do is assign a custom property on each alarm called AlarmGroup, this is filled in for every alarm
It is normally a 3 letter designation of the PLC followed by a longer descriptive text like
WM1_WetAdditives
WM1_DryAdditives
WM1_Devices
TK1_Devices
ST1_Devices
ST1_Loops

etc.

Then on the alarm status page we use the filter builtin function to filter the alarm based on either the short part or the entire thing depending on the level you want to display.
You can also use the custom property to filter for alarm counts too.

1 Like

I understand all that. I’m also doing it in a similar way.
But what I don’t get it is how they manage to put the alarm text in the left down corner…
It looks that they aren’t using alarm status component?
I’m just interested in that red square in the left down corner, with descriptive text, a button to dismiss and button to go to details…
Maybe someone can provide a sample that I can dive in and dissect myself?

It looks like they are querying against active alarms using the filter property I mentioned above.
We do something similar but we only show counts of active/acked and flash the background of the area red if alarms are active.

I have an expression tag in each area of the plant using an expression similar to this:

toInt(runScript("len(system.alarm.queryStatus(state=['ActiveUnacked'],source=['*PLAS/Board/*']))",2000))

That gives me a count of Active alarms in that area.
I then filter the small alarm display depending on the area of the plant it is part of.

2 Likes

Yeah, well… :confused:
It’s interesting, that they show it on the video.
Maybe someone from Ignition team will respond…

I agree. It would be great to have the project shown in the demo available for download.

1 Like

I wonder if someone tags an IA employee if they would respond?

@KathyApplebaum, Who would know more about this?

@zxcslo, I couldn’t tell who was conducting the webinar, you could try tagging them in a post.

1 Like

The demo project is actually a non-functional mockup, but the best way to implement something like this would be to use the runScript() expression function to call the system.alarm.queryStatus() scripting function, as @MMaynard suggested.

You rang? lol

I’d try someone in training, like @Robert.McKenzie, @paulscott or @Paolo.Mariani, since that’s the department that makes the videos. (And a great job they do!)

Haha Training didn’t actually make that video, it was done by the marketing team. Despite the run-around, Adam is correct. That particular video was just a mock-up but using runscript and the system.alarm.queryStatus() function will get your alarm information. You can modify the runScript expression above to get the first alarm name this way:

try(runScript("system.alarm.queryStatus(state=['ActiveUnacked'],source=['*'])[0].getName()",2000),'')
3 Likes

You still do a great job. :slight_smile:

1 Like

Does runScript still have a significant overhead? Or are you suggesting it’s use here just because it’s a single element?

Both runScript() and my alternative objectScript() (part of the free Simulation Aids module) are very computationally expensive if you change the string that is executed, as it then has to be recompiled. Prior to v7.8, that was the only way to get dynamic data into runScript, which is why objectScript exists (-:
Anyways, Robert’s suggestion doesn’t have a dynamic string, and can be expected to run as fast as any internal service.