# Using ignition alarms when the PLC cycle time is faster than the alarm poll rate **URL:** \ **Category:** Ignition\ **Tags:** perspective, ignition81\ **Created:** [March 18, 2025, 9:15pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848 "2025-03-18T21:15:49Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![face\_plant](https://avatars.discourse-cdn.com/v4/letter/f/e495f1/32.png) [@face\_plant](https://forum.inductiveautomation.com/u/face_plant)\ **Post date:** [March 18, 2025, 9:15pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/1 "2025-03-18T21:15:49Z")
Hello! I am using ignition perspective and the alarm table, along with CODESYS v3.5. I have 2 types of alarms: faults and warnings. Faults will change the system’s state from active to offline. Warnings just notify the user that something is happening, they do not directly impact the system. I have implemented the faults (the mission critical alarms) in CODESYS and the warnings in ignition. I like implementing the alarms in ignition due to the ‘Event Value’ feature. However, I am having trouble implementing the faults as ignition alarms. Since my PLC’s cycle rate (~20ms) is much faster than the polling rate of the alarm table (~1s), when a fault is tripped in CODESYS and moves the system into offline mode, the alarm table will completely miss the fault, and not display anything. For example: | timestamp | event | | --- | --- | | 0.00 | the system is in active | | 1.00 | alarm table polls | | 1.02 | fault trips | | 1.04 | system is in offline | | ... | ... | | 2.00 | alarm table polls | In this example, the fault will not show up in ignition because the system is offline and the fault is not enabled anymore. The alarm table missed the fault! I feel like I have misunderstood how to use ignition alarms. How can I implement my faults correctly with the perspective alarm table? Please let me know if there is any information I can include. Thank you! ---
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [March 18, 2025, 9:23pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/2 "2025-03-18T21:23:27Z")
When you say go offline, do you just mean that the PLC switches an internal state to faulted mode, or does it power off completely? Have another register set on the PLC to capture 'First-out' alarms, or alarms that caused the system to go offline. In your alarm logic, after all of the alarms/faults have been inspected for their enable conditions, copy the active alarms over. Only perform this copy on the transition from running to faulted. Only clear this register on reset button press, and make it where the user cannot reset for the first 2 or 3 seconds after the transition to faulted to allow Ignition time to capture the fault. I normally just duplicate my alarm structure for this 'First-Out' set and copy it over on transition from no alarms to alarmed/faulted. Its also really nice for seeing what alarm started the entire cascade of other alarms. ---
**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\ **Post date:** [March 18, 2025, 9:28pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/3 "2025-03-18T21:28:14Z")
I think its more that you might not understand the purpose of alarms. An alarm is something that is actionable... meaning something an operator can take action on. Do a search for ISA 18.2. In your case, if an alarm is happening so fast that it can't be displayed, then it's not an alarm. ---
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [March 18, 2025, 9:33pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/4 "2025-03-18T21:33:49Z")
Building on what @jlandwerlen said, you should really be latching in your alarms on the PLC anyways. Only unlatch on user interaction, like a reset button. Combine that latch in with my approach and you get the ability to determine the first alarm (or alarms) that triggered the transition to offline, while still seeing what alarms are currently active. ---
**Author:** ![face\_plant](https://avatars.discourse-cdn.com/v4/letter/f/e495f1/32.png) [@face\_plant](https://forum.inductiveautomation.com/u/face_plant)\ **Post date:** [March 19, 2025, 12:48pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/5 "2025-03-19T12:48:31Z")
thank you both for your answers. Let me provide some answers to your questions and some more context **When you say go offline, do you just mean that the PLC switches an internal state to faulted mode, or does it power off completely?** The PLC just switches to an internal state. In the offline state it closes valves, stops pumps, opens contactors, etc. For more context, here are the way I setup the alarms. Each alarm has a trip condition and an enable condition. For example, the enable condition for faults is that the system is in the 'active' mode. The trip condition can be something like a pressure sensor's reading being higher than some set value. When the alarm has been tripped, the user must press a 'clear alarms' button or else the system will stay in 'offline' mode. I believe this is the latch that you describe. So the workflow is - system in offline - user puts system into active - after some time, the trip condition and enable condition is true for a fault, which puts the system into offline - user presses 'clear alarms' and then is able to put the system into 'active' @jlandwerlen Given what I said above, I believe this meets the ISA18.2 requirement that it is something actionable. The system was running, then hit a fault, and now is not running. The user now has to take action to start the system again. Any alarm that is a fault will require the user to do something (ex: empty a tank or replace a filter) before being able to clear the fault and start the system again. I will do more research into ISA18.2 though.However, even if this is not exactly to standard, this type of alarm setup (faults impact the state of the system, warnings only notify the user) is what my users asked for so I must keep this basic structure atleast. @ryan.white could you please tell me more about your 'first-out' alarm structure? Specifically about the register you mentioned, its an array of active alarms? And so the user cannot take the system out of 'offline' unless they clear the alarms and wait those 2-3 seconds? ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [March 19, 2025, 12:55pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/6 "2025-03-19T12:55:37Z")
I guess, I don't understand your problem exactly. I understand that the system goes into a faulted state, that all makes since, but why does that prevent you from reading the fault from ignition? It seems like the real issue you're trying to solve is that Ignition may not capture the exact time the fault occurred. Is an exact timestamp critical to your process in some way? ---
**Author:** ![face\_plant](https://avatars.discourse-cdn.com/v4/letter/f/e495f1/32.png) [@face\_plant](https://forum.inductiveautomation.com/u/face_plant)\ **Post date:** [March 19, 2025, 1:05pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/7 "2025-03-19T13:05:21Z")
Apologies, I don't think I am explaining this well. **I understand that the system goes into a faulted state, that all makes since, but why does that prevent you from reading the fault from ignition?** The issue is that the system is not in the fault state for long enough for ignition to pick it up. Since the fault state is only active for only ~20ms, ignition misses it with it's 1s polling rate. **Is an exact timestamp critical to your process in some way?** No, but within a second of the actual fault trigger timestamp would be ideal. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [March 19, 2025, 1:19pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/8 "2025-03-19T13:19:17Z")
> [@face\_plant](#): > > Since the fault state is only active for only ~20ms The fault state should remained latched until it is acknowledged by the operator, which I am certain takes far longer the 20ms. Is there some reason why the fault condition is not latched? ---
**Author:** ![face\_plant](https://avatars.discourse-cdn.com/v4/letter/f/e495f1/32.png) [@face\_plant](https://forum.inductiveautomation.com/u/face_plant)\ **Post date:** [March 19, 2025, 1:28pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/9 "2025-03-19T13:28:32Z")
hmm okay. I believe that the fault state is latched though. If a fault trips and brings the system into 'offline', then the user has to press 'clear alarms' on perspective to be able to get back into 'active'. Am I implementing this wrong on the ignition side then? I setup my setpoint correctly, and then I have the 'enable' condition in ignition be true if the system is in 'active', is that incorrect? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 19, 2025, 1:32pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/10 "2025-03-19T13:32:07Z")
> [@face\_plant](#): > > have the 'enable' condition in ignition be true if the system is in 'active', is that incorrect? Yes, that is incorrect. The PLC should apply any enable conditions for **setting** any fault and **latch** that in the PLC until clear. Ignition should simply alarm on that bit. For warnings that can clear themselves, simply pass that bit to Ignition, and have Ignition alarm (at lower priority) for that bit. ---
**Author:** ![face\_plant](https://avatars.discourse-cdn.com/v4/letter/f/e495f1/32.png) [@face\_plant](https://forum.inductiveautomation.com/u/face_plant)\ **Post date:** [March 19, 2025, 1:49pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/11 "2025-03-19T13:49:24Z")
I'm not sure that I follow and I think I have thoroughly confused myself. In CODESYS, I have the following alarm ```python FUNCTION_BLOCK Tank_Level_HIHI VAR tripped: bool := false; clear: bool := false; // set to true by the HMI when the user presses 'clear alarms' END_VAR if system.system_state = "active" and IO.LT101 >= 100 then tripped := true; system.system_state := "offline"; end_if if clear then tripped := false; clear := false; end_if END_FUNCTION_BLOCK ``` I setup the ignition alarm like this: - name: Tank Level HIHI - priority: High - enabled (expression): system/system\_state=="active" - setpoint : IO/LT101\>=100 Which but should the 'enable' of the ignition alarm look at in the PLC? if not `system.system_state=='active'`, then should it be looking at `system.system_state=='active' and IO.LT101>=100`? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 19, 2025, 1:57pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/12 "2025-03-19T13:57:09Z")
> [@face\_plant](#): > > should it be looking at It should be looking at `tripped`. ---
**Author:** ![face\_plant](https://avatars.discourse-cdn.com/v4/letter/f/e495f1/32.png) [@face\_plant](https://forum.inductiveautomation.com/u/face_plant)\ **Post date:** [March 19, 2025, 2:01pm UTC](https://forum.inductiveautomation.com/t/using-ignition-alarms-when-the-plc-cycle-time-is-faster-than-the-alarm-poll-rate/103848/13 "2025-03-19T14:01:20Z")
okay I see now, thank you!