Minimize Alarm Conditions
- If a substantial number of alarms change state often, such as with every scan cycle, synchronization can be interrupted and the system can be stuck in a qualifying state until the alarms become stable. For more information, see the Knowledgebase Technote .
- For standard tasks, the alarm burst of many Logix tag-based alarms can lead to a significant increase of a task scan time on a synchronized redundant chassis pair. The scan time increase depends on the number of alarm conditions that change state during the alarm burst and their level of nesting.IMPORTANT: Each 1…25 tag-based alarm conditions established within one scope (each scope is determined by a separate identifier within the alarm fully qualified name) adds roughly 0.4 ms to the program scan time. Each level of nesting can add 0.4 ms in the worst case scenario.
- For the safety task, the alarm burst of many Logix tag-based alarms can impact the scan time in Logix SIS applications. However, this impact is mitigated because Logix SIS requires the safety task to be the highest priority task.
We recommend the following:
- Minimize the number of the alarm conditions that can change state during a potential alarm burst.
- Avoid excessive nesting of the conditions.
- For both standard tasks and the safety task, measure potential alarm bursts during system commissioning and change the project if measured scan times are not acceptable.
Provide Feedback