Alarms, Alarms, Alarms...Dynamic Alarm Text and more!

Need some help/direction, working on my first Ignition project and am trying to replicate the same or similar methods that we use on other SCADA platforms to maintain the same philosophy, yet take advantage of features when we can.

For alarm messages, we typically keep all alarm messages in an SQL database for a number of reasons. So, anytime an alarm occurs the SQL database is queried and the proper alarm message is returned. This is typically accomplished using a data change script of some sort. The alarm code is generated, SQL is queried and the message is returned to a dedicated alarm tag.

I’m sure I can replicate this with Ignition, although I wouldn’t mind some pointers on the scripting required to query a SQL database an return the string text to a memory tag.

However, I really think the alarm trend would be very handy for some alarms. For that to work I feel like I would need to configure the alarm conditions directly on the tags as the Alarm Trend will need a tag reference to access the historical data. Which means I would somehow have to dynamically change the message text on the tag when the alarm occurs. Or, I would have to dynamically change a general alarm tag, tag data reference so that the trend can pull up the proper alarm history.

Not sure I’m expecting an answer, just need to “talk it out” since it’s a new platform.

what version of ignition are you on?

7.6.4, once 7.7 comes out I’ll be upgrading to that version.

I’ve got the SQL queries sorted out, but don’t think I’ll be able to link the data properly to utilize the trend.


I’m afraid I don’t quite follow all of the different dynamic parts in your description, especially in regards to the trend, but I wanted to make sure that you understood how properties could be dynamic, and even from the database.

The “name” of the alarm, which is part of its location, can’t be dynamic. But the messages, such as email or phone, or something like the display path (which is useful, because it is easily shown on the alarm status table) certainly can be. Or, you might choose to add your own fields as “associated data”. At any rate, with the dynamic properties, you can bind them to an expression, and that expression could be a function like “executeScalarQuery(…)” that looks up a value from the db.

The expressions will get executed each time the alarm changes state, and the data will be included with the event (and logged to the alarm journal, among other things).

If you still have something you’re trying to do and can’t figure out, please describe a bit more and maybe I can point you in the right direction.