Re-Alarming
Is there an AC800M Control Builder function block that will support re-alarming? For example, if an operator gets an alarm and acknowledges it, but the PV remains outside of the alarm threshold for a certain period of time then it would alarm again. For a normal alarm, once the operator acknowledges it then it won't alarm again unless it comes back within an acceptable range and then out of that range. However, if it stays out of that range then it won't ever alarm again.
Asked 1 year ago
Answers
0
Hello,
Any OPC AE behaves in such a way that Alarm generated from Controller-OPCAE-Alarm manager to display -once alarm ack-OPCAE-Controller FBD (to ensure ACk).
In general If PV crosses the limits then alarm will triggers and based on the Hysterisis, alarm will remain in active state and once crosses Hysterisis alarm will be normal.
Can you give bit more info. what you are expecting as re-alarming and what situation you need these things.
Any OPC AE behaves in such a way that Alarm generated from Controller-OPCAE-Alarm manager to display -once alarm ack-OPCAE-Controller FBD (to ensure ACk).
In general If PV crosses the limits then alarm will triggers and based on the Hysterisis, alarm will remain in active state and once crosses Hysterisis alarm will be normal.
Can you give bit more info. what you are expecting as re-alarming and what situation you need these things.
1
As far as I can tell, the standard AlarmCond blocks do not have any re-alarming feature.
The functionality can be achieved by creating a custom object type that embed a regular AlarmCond block and monitors its condition state (CondState) and if left at Active Acknowledged (state 4) for too long time (measured with a Timer and compared with a parameter like "MaximumAcknowledgedTime" defined by the custom type) cycles the Signal parameter of the AlarmCond block to fire a new Active Unacknowledged alarm (state 5).
The default action in the 800xA HMI alarm lists is to remove the previous alarm and replace it with the new. Event lists, however would tell that the block briefly entered Inactive, Acknowledged (state 2) and in the next split second goto Active, Unacknowledged. This temporary "return to inactive" transition is not completely true from a pure process perspective since it was your "Re-Alarm" block that cycled the trigger signal to force a new alarm.
The functionality can be achieved by creating a custom object type that embed a regular AlarmCond block and monitors its condition state (CondState) and if left at Active Acknowledged (state 4) for too long time (measured with a Timer and compared with a parameter like "MaximumAcknowledgedTime" defined by the custom type) cycles the Signal parameter of the AlarmCond block to fire a new Active Unacknowledged alarm (state 5).
The default action in the 800xA HMI alarm lists is to remove the previous alarm and replace it with the new. Event lists, however would tell that the block briefly entered Inactive, Acknowledged (state 2) and in the next split second goto Active, Unacknowledged. This temporary "return to inactive" transition is not completely true from a pure process perspective since it was your "Re-Alarm" block that cycled the trigger signal to force a new alarm.
by RickW Rank: 29 on 6/5/2020 9:05:53 AM | Like (0) | Report
In my experience, an operator should know what alarms they have at anytime and some level of importance. The alarm priorities are used as a measure of the importance of an alarm. The priorities are then used by the operator to filter the alarms in importance or the urgency of action. Alarm lists helps them to see and filter alarms quickly and continuously. If the need to 'alarm again' is desired it makes me wonder if the operator has too many tags in alarm at any time.
Add new comment