Clearing and Acknowledging Alarms in InTouch Distributed Alarm

In InTouch HMI applications that combine a live Distributed Alarm Display with a historical AlarmDBViewCtrl, operators routinely need to know the difference between acknowledging, suppressing, and clearing an alarm. The three operations look similar in the Summary window but produce fundamentally different results in the alarm database. This reference walks through the underlying state model, the scripting functions (almQuery(), almSuppressAll), the typical PB (Pushbutton) Action script pattern, the PLC-side handshake used to silence horns, and the color/state conventions that let a single Alarm page show current and historical conditions at a glance.

1. Overview: The InTouch Distributed Alarm Model

The InTouch Distributed Alarm system categorizes every alarm into one of five general conditions as published by AVEVA: Discrete, Value, Deviation, Rate-of-Change, and SPC. Each of these conditions follows the same lifecycle: the alarm is raised when its triggering expression becomes true, it is acknowledged by an operator action, and it is cleared (returned to normal) when the triggering expression becomes false. The state machine is enforced by the InTouch alarm engine and recorded in the alarm database that backs AlarmDBViewCtrl.

Two UI surfaces expose this state machine to operators:

• Distributed Alarm Display (Summary mode) — shows only currently active alarms. Lines disappear automatically when the source condition clears.
• AlarmDBViewCtrl — shows the persistent alarm database. Lines remain visible for the configured retention period even after the alarm has returned to normal.

Because the Summary window removes lines automatically on return-to-normal, the operator cannot manually "clear" a Summary line. The two real actions available from script are acknowledge (changes the visual state and writes a timestamp) and suppress (hides further display of alarms matching a filter until the suppression is released).

2. Distributed Alarm Display vs AlarmDBViewCtrl

The two controls are complementary, not interchangeable. Mixing them up is the most common reason operators complain that an alarm "won't clear."

For an operator screen that needs to show both current and historical alarms, the typical layout is a split screen: an Alarm History (AlarmDBViewCtrl) on top and a Alarm Summary (Distributed Alarm Display) on the bottom. This is the configuration most field-tested applications adopt because it gives operators a single page for both live triage and after-the-fact review.

3. The Alarm State Lifecycle and Color Model

InTouch supports three primary alarm states, each with a configurable display color. The widely deployed convention is:

When the Summary window sees a transition from red to orange, the line stays visible because the underlying condition is still active. When the line transitions off-screen (or is removed from the Summary view), the underlying condition has returned to normal — the line has not been "cleared" by the operator, it has been resolved by the process. This distinction matters: an operator can acknowledge a still-active alarm, but only the process can clear it.

4. Acknowledging Alarms with PB Action Scripts

Acknowledgment is the only operator action that produces a visible state change (red → orange) on a still-active alarm line. The standard pattern is a Pushbutton Action script on the “Acknowledge” button that performs three things on key down:

1. Sets the Wonderware acknowledgment tag for the alarm group to 1.
2. Pulses an IO tag to the PLC to silence the physical alarm horn.
3. On key up, refreshes both the Summary and History displays and releases the PLC horn-silence tag.

4.1 Reference Acknowledge PB Action Script

// =========================================
// PB Action script on "Acknowledge" button
// Alarm Group: V21-Alarms
// PLC Horn Silence tag: V21-WWAlarmAck
// =========================================

ON KEY DOWN
  V21-Alarms.Ack = 1;                          // Wonderware WW command to
                                                // acknowledge all alarms
                                                // in the "V21-Alarms" group
  V21-WWAlarmAck = 1;                          // IO tag to PLC: silence horn

ON KEY UP
  almQuery( "ALMOBJ_1",                        // Refresh Summary window
            "\Intouch!V21-Alarms",
            0, 999,
            "ALL",
            "Summ" );
  #AlmDbViewCtrl1.Refresh();                   // Refresh History (DB) window
  V21-WWAlarmAck = 0;                          // Reset horn-silence pulse to PLC

4.2 Anatomy of the almQuery() call

The almQuery() built-in forces the alarm engine to re-evaluate the visible window. Its arguments are:

Pairing almQuery() with #AlmDbViewCtrl1.Refresh() guarantees that both the live summary list and the persistent database view are in sync with the new acknowledgment state at the moment the operator releases the button.

5. Suppressing vs Clearing Alarms

The InTouch scripting API does not expose a function that deletes a row from the Summary window or the alarm database. Two operations are available that approximate "clearing":

5.1 almSuppressAll — global suppression

The almSuppressAll function blocks new entries from being displayed in the Summary window for a specified alarm group. Existing rows are not removed; they remain visible until they return to normal. When suppression is released, previously suppressed rows may reappear in the view. This is the correct tool when a maintenance activity will produce a known burst of nuisance alarms.

5.2 Acknowledgment — the only state change available to the operator

For a single alarm, the operator can only change its state from unacknowledged to acknowledged. The alarm will only leave the Summary window when the source condition returns to normal. This is by design: an alarm that is acknowledged while the condition is still active is a known and unaddressed abnormal condition; suppressing it from view would defeat the purpose of the HMI.

5.3 Decision matrix: which action to take

6. PLC Integration for Horn Silence

Most installations wire the Acknowledge button to two destinations: the InTouch alarm engine (for state change) and a discrete output to the PLC (to silence the physical horn or strobe). A typical IO tag convention is:

The PLC should treat V21-WWAlarmAck as a momentary pulse: latch the horn silence for the duration the bit is high, or use a rising-edge detection to silence the horn for a fixed minimum time (e.g. 2 seconds) to avoid chatter. On the InTouch side, releasing the button (KEY UP) clears the bit so the PLC horn can re-arm on the next unacknowledged alarm.

7. Configuring the Acknowledge Button on a Window

The Acknowledge button is normally a Pushbutton (not a Switch) so the KEY DOWN and KEY UP events both fire on the same physical press. The minimum steps are:

1. On the Alarm window, draw a Pushbutton and label it Acknowledge.
2. Open “Pushbutton Properties → Action” and select Discrete → On Key Down / On Key Up scripting.
3. Paste the script from Section 4.1, substituting the real alarm group name and PLC tag.
4. Verify the AlarmDbViewCtrl1 control name on the window (case-sensitive) and update #AlmDbViewCtrl1.Refresh() if it differs.
5. Save the window, register WindowViewer, and trigger a test alarm.

8. Building a Split-Screen Alarm Page

For a single-page view of current and historical alarms, the recommended geometry at 1024×768 is:

• Top half: AlarmDBViewCtrl (Historical) — shows 10+ rows with scroll arrows.
• Bottom half: Distributed Alarm Display in Summary mode — shows current active alarms.
• Footer: Acknowledge button (left), Silence Horn button (center, optional), Filter selector (right).

With this layout, an operator sees three timestamps in the History view for any single alarm: when it was raised (red), when it was acknowledged (orange), and when it returned to normal (green). The Summary view shows whether the condition is still active right now.

9. Using Distributed Alarm History Instead of AlarmDBViewCtrl

If the goal is to give the operator a way to clear the visual display of a historical line, an alternative is the Distributed Alarm History display inserted from Wizards → Alarm Displays. This control can be configured for History or Summary mode and shares the same color/state model. It is often a better fit than AlarmDBViewCtrl when the application does not need the full alarm database semantics (e.g. filtering by tag, date range, priority).

Use the Distributed Alarm History control when:

• You want a single wizard-based configuration.
• You do not need persistent DB-backed history (no long-term reporting).
• You want the operator's acknowledgment actions to flow through the same V21-Alarms.Ack path automatically.

Use AlarmDBViewCtrl when:

• You need long-term alarm archival for regulatory or shift-report purposes.
• You need to display alarm rows in the DB that predate the current InTouch session.
• You need to surface alarm data to external reports (Excel, SQL) via the alarm DB.

10. Step-by-Step: Implementing a Clear-Style Acknowledge Button

10.1 Prerequisites

• InTouch development license with the Distributed Alarm option enabled.
• An Alarm Group defined in the AlarmGroups dictionary (e.g. V21-Alarms).
• At least one Distributed Alarm object (ALMOBJ_1) placed on the Alarm window.
• An AlarmDBViewCtrl ActiveX control on the same window, named AlarmDbViewCtrl1.
• Two IO tags defined: the alarm-acknowledge system tag and the PLC horn-silence BOOL.

10.2 Procedure

1. Open the Alarm window in WindowMaker.
2. Place a Pushbutton on the window. Name it AckPB.
3. Right-click → Animation Links → Touch Pushbutton → Discrete.
4. In the Action script, paste the reference script from Section 4.1.
5. Replace V21-Alarms with the actual alarm group name.
6. Replace V21-WWAlarmAck with the actual PLC tag.
7. Save the window and run WindowViewer.

10.3 Verification

1. Force a Discrete alarm — confirm a red line appears in Summary and a red row in AlarmDBViewCtrl.
2. Press the Acknowledge button — the line should turn orange in Summary, and a new orange timestamp should appear in the History row.
3. Confirm the PLC horn-silence bit pulsed (use PLC online monitor; expect a 1 for the duration of the press, 0 after release).
4. Clear the alarm source — the line should leave the Summary window, and the History row should turn green with an RTN timestamp.
5. Refresh AlarmDBViewCtrl manually (or wait for the next refresh cycle) — the row should remain green for the configured retention period.

11. Troubleshooting Matrix

12. Best Practices

• Use a single alarm group per equipment — simplifies the Acknowledge tag and keeps the PLC handshake consistent (e.g. V21-Alarms for equipment V21).
• Always pair almQuery() with a History refresh — the Summary update is automatic, but AlarmDBViewCtrl must be explicitly refreshed.
• Configure Acknowledge as a momentary pushbutton, not a maintained switch. This prevents the operator from accidentally leaving the system in a state where all alarms are permanently acknowledged.
• Reserve suppression for planned maintenance and always release it as part of the maintenance closeout procedure. Log the suppression start/stop times in the alarm DB for traceability.
• Document the five alarm condition types (Discrete, Value, Deviation, Rate-of-Change, SPC) per the AVEVA reference and choose the correct type for each tag. See the AVEVA InTouch alarm types documentation for selection criteria.
• Test the full lifecycle — raise → acknowledge → return-to-normal — on every alarm source before commissioning. A red row that never turns orange or green is almost always a script or PLC handshake bug, not an InTouch engine bug.