[00:00] In Ignition we can set up what we call an alarm journal which allows us to log alarm events for any of the alarms we have set up to a database allowing us to go back and view a history of all of our alarms. Because we will be storing these events in a database before we get started we first need to make sure that we have a valid database connection. Once we have that valid database connection we then want to go into the configuration section of the gateway webpage, and scroll all the way down until we find the alarming section. We're going to want to click on the journal link to go to the alarm journal page. You can see I have no alarm journals set up so I'm going to click on the link that says Create new alarm journal profile. Here we can configure how our alarm journal is going to work. We first need to give it a name. I'm going to leave mine the default. And then we need to select a database connection that it's going to use.

[01:03] I'm going to leave mine as DB1. We can also set a minimum priority of events. By default this is set to low. Meaning any events that are of diagnostic priority are not going to be stored in the alarm journal. By default shelved events are also not stored in the journal but we can set them to do so here. The journal can also be configured to not use the store and forward system. This will free up your store and forward system for more important things but if your database connection ever goes down the journal doesn't store events through store and forward and so they won't be stored until the database connection comes back online. Which means you'll lose some alarm journal events. Next, we can scroll down a little bit more to the stored event data section. Here we can configure what type of data we want to be storing in the database tables. The configure values are any of the alarm's actual properties while the associated data values are any of the associated data properties that you set up on the alarm.

[02:07] By default all associated data properties are stored in the database as well as any dynamic or bound alarm properties are also stored. This means that static alarm properties or properties that just have one set value will not be stored in the database. However, you can change this just by checking this checkbox for static configuration. I'm going to leave mine at the default values and scroll on down to the next section. Here, we can set up data filters. We can filter by either source or display path. Or a mixture of both. For all of these filters you can use the wild card star symbol and you can also separate multiple entries with a comma. If these filters are left blank that means the alarm journal will store the alarm events of every single alarm that you have set up in your gateway. However, including a term in the filter doesn't mean that that value is going to be excluded, but included in the alarm journal.

[03:08] For example, if I was to enter in a value for a filter by display path, say motor, then only alarm events that have the display path of motor will store in this alarm journal and all others will be excluded. Because I didn't use the wildcard star symbol in my display path, then only display paths that exactly match the string motor are going to be stored in the journal. If I wanted to store all alarm events that contain the word motor in their display path then I would need to place the star symbol at both the front and back of the word motor to check for all display paths that contain the word motor. I'm just going to leave this blank because I want to store all events. In the last section we can set up data pruning. The alarm journal tables are essentially a history of alarms and as with all history, pruning is important because the history data tables can grow quite large if left unchecked.

[04:07] Clicking the checkbox will enable data pruning and then you can set up how often you want the data to be pruned in these properties here. Finally, if we click the checkbox to show advanced properties, we can see the last important properties that we have here. When you set up an alarm journal for the first time as soon as you click the button at the bottom to create the new alarm journal it will automatically go into your database and create two new tables for you. One that will store a list of alarm events and the other that will store a list of those events' data. These properties here are where we can specify the names of these tables. By default, the first one is just alarm events and the second one is alarm event data. However, you can change these to be whatever you would like. This may be important for some users who are creating multiple alarm journals to store different types of alarm events. That way each journal of events can be separated from each other into different database tables.

[05:06] I'm just creating the one journal, though, so I'm going to leave those table names the same. And go ahead and click the Create New Alarm Journal Profile button at the bottom of the screen. Here, we can see it successfully created our journal and now our alarm events are already storing to the database.