The subscriber sends the acknowledge to the appropriate clients and historical databases.

7. The subscriber sends the acknowledge to the appropriate clients and historical databases.

Because timestamps occur at multiple places during normal alarm operation, it is important to coordinate the clocks of the controllers and workstations in the system. For more information on, see Different Methods of Synchronizing Clocks with ControlLogix Controllers, Knowledgebase document 40467 at http://www.rockwellautomation.custhelp.com .

98 Rockwell Automation Publication 1756-RM094H-EN-P - November 2012

FactoryTalk Alarms and Events System Chapter 8

Alarm Log

The alarm log holds 10,000 alarm state transitions in a circular log. This replaces the alarm buffer in controllers with firmware earlier than revision 21. The original 100 KB alarm buffer is now a 2 KB subscription service with no timeouts. The alarm log is stored in extended memory.

In controllers with firmware earlier than revision 21, the controller reserves 100 KB per subscriber to buffer alarm data in the event that the subscriber loses its connection to the controller. Typically, this buffer holds about 1000 events.

Guideline (Firmware Earlier Than Revision 21)

Description

If the subscriber loses its connection to the controller, re- The alarm buffer in the controller continues to buffer new alarms until either the buffer is full (100 KB) or the buffer times establish the connection as soon as possible.

out. You configure the buffer timeout from 0 min...2 hr (default is 20 min) when you configure the alarm server in RSLinx

Enterprise software. If the subscriber fails to reconnect by the end of this buffer time, the controller clears the buffer and reclaims the 100 KB of buffer space for normal controller operations.

You can check the status of a subscriber connection to the The Status tab on the alarm properties in the Logix Designer application identifies whether the controller is buffering controller by looking at the instruction faceplate.

alarm data. This value is updated at the next occurrence of the alarm event.

Programmatically Access

Each alarm instruction has an alarm structure that stores alarm configuration and

Alarm Information execution information. The alarm structure includes both control program

elements and operator elements. The alarm instructions do not use mode settings to determine whether program access or operator access is active, so these elements are always active.

There are three ways to perform actions on an alarm instruction.

Access

Alarm Structure Elements

Considerations

Control program

• ProgAck

Use controller logic to programmatically access elements of the alarming system. For

• ProgReset

example, the control program can determine whether to disable a series of alarms that

• ProgUnshelve

are related to a single root cause. Then control program could disable an alarm

• ProgSuppress

instruction, MyDigitalAlarm of data type DigitalAlarm, accesses a tag

• ProgDisable

MyDigitalAlarm.ProgDisable.

• ProgEnable

Custom HMI

• OperAck

Access a custom faceplate to access elements of the alarming system. For example, if the

• OperReset

operator needs to remove a tool, rather than manually disable or suppress alarms

• OperShelve

individually from the alarming screens, the operator can press a disable key that accesses

• OperUnshelve

a tag MyDigitalAlarm.OperDisable.

• OperSuppress • OperDisable • OperEnable

Standard HMI object

Not accessible

Normal operator interaction is through the alarm summary and alarm banner objects in the FactoryTalk View application. This interaction is similar to the custom HMI option described above, but there is no programmatic visibility or interaction.

Rockwell Automation Publication 1756-RM094H-EN-P - November 2012

Chapter 8 FactoryTalk Alarms and Events System

To perform global alarm operations, access the alarm elements via the relay ladder instructions. For example, assign a BOOL tag DisableToolA to all the ProgDisable fields on the alarm relay ladder faceplates in ToolA. Then use the DisableToolA tag to disable the operation of all the alarms that use this tag.

IMPORTANT

If you assign a tag to the ProgAck, ProgReset, ProgDisable, or ProgEnable functions on the alarm faceplate, do not use the alarm structure elements in the alarm data type to perform the same functions. For example, if you assign DisableToolA to disable an alarm MyDigitalAlarm, you should no longer programmatically access MyDigitalAlarm.ProgDisable. Doing so can cause a condition where the faceplate requests one operation and the alarm tag requests another.

If you want to use the alarm structure elements to programmatically change the alarming system, assign those elements to a faceplate. For example, on the alarm faceplate for ProgDisable, assign the tag from that alarm’s structure tag MyAlarmTag.ProgDisable. This lets you programmatically access MyAlarmsTag.ProgDisable in other code locations without conflict.

At the HMI and in the event log, any controller-driven events, either through the alarm structure or the alarm dialog, are logged in the historical database as Discrete Events. This includes any HMI interface that also accesses this same information via the operator elements (.OPERxxx). So while timestamps and events are tracked in the log, the log does not include identification of what caused the event. For example, an operator and workstation in this scenario is not tracked because they did not take action via a FactoryTalk alarm graphic object.