|Name||The default name is Journal.|
|Enabled||By default the journal profile is enabled.|
This is the ONLY required setting which must be a valid database connection, events are stored to this datasource.
|Minimum Priority||Only events equal to or greater than the specified priority will be stored. The default is Low. You can set the priority to be: Diagnostic, Low, Medium, High, and Critical.|
|Store Shelved Events||Not enabled by default. If enabled, events generated by "shelved" alarms will still be written to the journal system.|
|Use Store and Forward||Enabled by default, which means the alarm journaled events will be stored through the Store and Forward system. If not enabled, they will be stored directly against the database. This system protects data from being lost due to temporary database connectivity issues.|
Stored Event Data
Alarm events consist of two main types of data: the primary information about the alarm, such as transition state, time, etc. , and the event data.
|Static Config||By default, it is not selected. If selected, will store the values of static alarm configuration. That is, the alarm properties that are not bound. These do not change during evaluation, only when a user modifies them in the Designer, and so they are not stored by default.|
|Dynamic Config||If selected, will store the values of dynamically bound alarm configuration properties. The value of these properties can change at any time, and the values at the time of the alarm are captured on the alarm event.|
|Static Associated Data||If selected, will store the values of non-bound associated data (properties created by the user) properties on alarm that do not change during execution.|
|Dynamic Associated Data||If selected, will store the values of dynamically bound associated data (properties created by the user) properties.|
The following three properties interact via logical AND, meaning an alarm must meet the criteria for all three for it to be logged in the Journal. Thus, if you supply values for all three Data Filer properties, then an alarm must match the Filter by Alarm Source, Filter by Display Path, and Filter by Display Path or Source properties.
Example: if a Journal has values for all three properties, and an alarm only meets the requirements for Filter by Alarm Source and Filter by Display Path or Source, but not Filter by Display Path, then the alarm will not be logged to the Journal!
If you want to filter on both the Display Path and Source Path, you would want to use only one of the two following approaches:
It is recommended to avoid using all three properties simultaneously on the same Journal.
|Filter by Alarm Source||Only events matching the source will be stored. Multiple sources to match can be comma separated. Leave blank to store events from all sources.|
|Filter by Display Path||Only events matching the display path will be stored. Multiple display paths to match can be comma separated. Leave blank to store events from all display paths.|
|Filter by Display Path or Source||Only events matching the display path, if defined, will be stored. Multiple matches can be comma separated. If no display path is defined, only events matching the source will be stored. Leave blank to store all events.|
|Enable Data Pruning||Default is not enabled. If selected, data will be deleted after the specified time period as set by the Prune Age and Units below. Note that since the data is stored directly in a database, an administrator is free to manually delete data at any time.|
|Prune Age||The number of Prune Age Units to store data for. IE: 1 year, 5 hours, etc. The default is 1.|
|Prune Age Units||The default is YEAR. You can choose the unit to be MS, SEC, MIN, HOUR, DAY, WEEK, MONTH, and YEAR.|
These settings let you specify your own table names. This is especially useful when trying to use multiple alarm profiles within a single database (not common, but can happen, especially with multiple systems sharing a single database).
|Table Name||The default is |
|Event Data Table Name|
The default is
The alarm journal system will automatically create the necessary tables for you, and scripting functions can be used to query the system without having to know about the table structure. However, understanding the structure of the alarm journal tables can be useful for accessing the data in situations where SQL queries are more convenient.
Alarm Events (
This table stores the core data for each event that occurs. An event is a transition for an alarm between active, cleared, or acknowledged. Additionally, other events may be stored in this table that aren't directly related to an alarm, such as a system shutdown event. This table defines a primary key "id", that is used as a foreign key by the Alarm Event Data table, which stores additional information for each event.
|id||integer||A unique integer id for each event entry event|
|eventid||string||The UUID of the alarm event that this individual event is related to. Each |
The qualified path of the entity that generated the alarm event. See below for more information about qualified paths.
The value set for the "Display Path" of the alarm. Generally a user defined, friendlier version of the source.
The priority or severity of the alarm:
The type of transition represented by this event:
A numeric bitmask flag field providing additional information about the event.
Bit 0: System Event - One of the designated system events. (System Startup, System Shutdown)
|eventtime||datetime||The time of the event.|
Alarm Event Data (alarm_event_data)
This table stores the properties associated with an alarm event. The individual event is referenced through the
ID column, against the alarm event table.
|id||integer||The id that corresponds to the alarm event in the alarm_events table.|
|propname||string||The name of the property. May be one of the common alarm properties (a configuration setting), or the name of an associated data property.|
|dtype||integer||The data type of the property, indicating which data column should be used:|
The corresponding value columns for the property. Unused columns will
A qualified path in Ignition is a path to an object, described by various annotated components. Each component has a type identifier and a value, separated by a colon (
:), and each component is separated by colon-forward slash (
:/). For example, an alarm is identified by
alm:Alarm Name. It usually exists under a Tag, in which case its fuller path would be
tag:Path/To/Tag:/alm:Alarm Name. Paths can be built up further depending on the level of specificity required by the situation.