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!
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.
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.
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.
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?
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?
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.
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?
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?
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.
I'm not sure that I follow and I think I have thoroughly confused myself.
In CODESYS, I have the following alarm
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
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?