Siemens HMI Discrete Alarm Displays Twice: Root Cause and Solution

A discrete alarm configured in WinCC TIA Portal and triggered by a single PLC bit commonly appears twice on the HMI panel: once when the bit goes high, and again when the bit returns low. The duplicate is not a PLC or tag problem; it is the intended behavior of the alarm state model combined with the default alarm view filter. This reference explains the state machine, identifies the exact filter property that causes the duplication, and provides a step-by-step TIA Portal procedure to make each alarm appear once per activation cycle.

1. Problem Description

Engineers configure a discrete alarm and bind it to a Boolean tag (e.g., "DB_HMI".Alarm_Bit_01) inside a WinCC HMI tag table. On the panel:

1. When the bit transitions from 0 → 1, the configured alarm text appears on the alarm view.
2. When the bit transitions from 1 → 0, the same alarm text appears a second time before disappearing.

If the same bit toggles rapidly, the operator sees a continuous list of identical messages and concludes the system is generating duplicate alarms. The PLC program is correct; the HMI alarm view is doing exactly what it has been told to do, but the configuration does not match the operator's expectation of "one message per fault condition."

2. How the Siemens HMI Alarm State Model Works

Every discrete alarm in WinCC TIA Portal transitions through a defined set of states. The states are stored on the HMI and are visible in the alarm view and the alarm log. Understanding the state machine is required to fix the duplicate behavior.

The Outgoing (O) state is what produces the apparent duplicate. The alarm view treats the O transition as a new event to log and display, because from the historian's perspective it is a state change. The operator, however, reads the alarm view as a "current fault list" and perceives the O state as a repeat of the I state.

3. Alarm View Filter Types in WinCC TIA Portal

The alarm view control on the HMI screen has a property called Filter (or Alarm filter) that determines which subset of the alarm buffer the operator sees. The default depends on the HMI template, but most "out-of-the-box" templates use Pending alarms or Unacknowledged alarms. Selecting the wrong filter is the root cause of the duplicate display.

The Alarm events filter is the filter that causes the second message to appear as if it were a new alarm. It is designed for the alarm log screen, not for the operator's "current fault" view.

4. Root Cause Analysis

The duplicate row on the operator panel is the result of one of the following configuration choices. Walk through them in order; only one is usually present, but multiple can stack on a single screen.

1. Alarm view filter is set to "Alarm events" or "All." Both transitions (I and O) are listed as separate rows with identical alarm text. This is the most common cause.
2. Acknowledgment is disabled on the alarm class. Without acknowledgment, the O row remains visible in "Pending alarms" until the operator manually clears it; combined with a second trigger it looks like duplication.
3. The PLC bit is being toggled twice in the same cycle (e.g., set in OB1, reset in OB35 within the same scan). Check the PLC logic with a watch table before changing the HMI configuration.
4. Two separate discrete alarms share the same text string and the same trigger tag because of copy-paste in the HMI alarms editor. Open the alarms editor and confirm that only one alarm row references the trigger tag.
5. The tag used for triggering is a non-retentive HMI tag that toggles during HMI startup or runtime restart. Switch to a PLC tag if this is suspected.

Confirm the cause by enabling the Status column in the alarm view. If the second row shows O, the cause is filter #1 above. If the second row shows I with a new timestamp, the cause is filter #3, #4, or #5.

5. Solution Overview

The corrective action is to make the alarm view show the alarm exactly once for the entire active period of the trigger condition. Two complementary changes are required in TIA Portal:

1. Set the alarm view filter to Pending alarms (or Pending and unacknowledged if acknowledgment is not required for this class).
2. Configure the alarm class so that acknowledgment is required and the O transition is automatically hidden once the alarm is acknowledged.

The optional but recommended third change is to enable the Status column on the alarm view so operators can interpret any remaining state transitions correctly.

6. Step-by-Step Configuration in TIA Portal

6.1 Prerequisites

• TIA Portal V16 or later (V17/V18/V19 recommended for the screenshots in this article).
• A configured HMI device (Comfort Panel, Unified Panel, or PC Runtime) with at least one screen containing an Alarm View control.
• A discrete alarm already created in HMI alarms > Discrete alarms and bound to a PLC Boolean tag.
• The HMI project compiled at least once successfully.

6.2 Configure the Alarm View Filter

1. In the TIA Portal project tree, open the HMI device and navigate to Screens > [target screen].
2. Select the Alarm View control on the screen. In the Inspector window, open Properties > General.
3. Locate the Filter property (label varies: Filter, Alarm filter, or Default filter).
4. Change the value from Alarm events or All to Pending alarms.
5. Under Properties > Columns, enable the Status column so the I/O state is visible to the operator.
6. Compile the HMI and download to the panel.

6.3 Configure the Alarm Class

1. In the project tree, open HMI alarms > Alarm classes.
2. Select the alarm class used by the discrete alarm (commonly Errors or Warnings).
3. Set Acknowledgment to With acknowledgment (this is the default for "Errors").
4. If the alarm must require operator acknowledgment even after the trigger has cleared, enable Acknowledgeable outgoing in the class properties.
5. Confirm the State machine setting matches the desired operator behavior:
   • Standard — I, IA, O, OA, G states (recommended for process alarms).
   • With acknowledgment and confirmation — adds a confirm step before G.
6. Recompile and download.

6.4 Confirm Only One Alarm References the Trigger Tag

1. Open HMI alarms > Discrete alarms.
2. Use the column header filter to display only alarms where Trigger tag contains the variable name of the suspect bit.
3. If more than one row is returned, delete the duplicate or re-point it to the correct trigger tag.

6.5 Verify the PLC Program

Open the PLC block (e.g., DB_HMI) in the PLC programming editor. Confirm that the trigger bit is not set and reset in the same scan cycle, and that no other logic (e.g., a start-up OB) writes the bit twice in quick succession. Use a watch table with a 100 ms trigger to log the bit over 10 s; the bit should rise once and fall once per fault event.

7. Configuration Reference Table

8. Verification Procedure

After downloading the modified project to the HMI, perform the following on the live panel:

1. Force the trigger bit to 1 from the PLC watch table.
2. Confirm that exactly one row appears in the alarm view with state I.
3. Acknowledge the alarm from the panel (Acknowledge key or soft key on the alarm view toolbar).
4. Reset the trigger bit to 0 in the watch table.
5. Confirm that the row is removed from the alarm view without reappearing, or — if "Acknowledge outgoing" is enabled — that the row briefly shows state OA and is removed on the second acknowledge.
6. Toggle the bit 10 times in succession; confirm that the operator sees at most one active row at a time, and that the alarm log contains exactly 10 incoming transitions and 10 outgoing transitions (the log is expected to record both; the live view is not).

9. Platform-Specific Notes

9.1 Comfort Panels (TP700 / TP900 / TP1200 / TP1500 / TP2200)

Comfort Panels support the full WinCC alarm state machine. The alarm view filter property is found in the Inspector under Properties > General > Filter. Comfort Panels support up to 4,000 simultaneous pending alarms and an alarm log capacity of 500 MB by default.

9.2 Basic Panels (KTP400 / KTP700 / KTP1000 / KTP1200)

Basic Panels support discrete alarms but use a simplified state model. The alarm view on Basic Panels does not support the "Pending alarms" filter in the same way; it always shows the active alarm until cleared. For Basic Panels, configure the alarm class with automatic clear on trigger reset (achieved by leaving acknowledgment disabled) to avoid the duplicate behavior. This is the only configuration path on Basic Panels.

9.3 Unified Comfort Panels (MTP700 / MTP1000 / MTP1200 / MTP1500 / MTP1900 / MTP2200)

Unified Panels use the Alarm Control (not the classic Alarm View). The filter is configured in the same way, but the property name in the Inspector is Filter → Default filter. The status column is called State in the Unified Alarm Control.

9.4 WinCC Runtime Advanced (PC)

The same procedure applies. The filter is set on the alarm view control on the screen. Runtime Advanced supports a separate alarm log database if persistence is required.

9.5 WinCC Runtime Professional (PC/SCADA)

Runtime Professional uses the WinCC AlarmControl ActiveX / WPF control. The filter is configured on the control's Filter property. For SCADA deployments with many operators, consider using the Single Message mode that collapses repeated identical alarms into a count column.

10. Troubleshooting Matrix

11. Reference: Alarm State Machine (SVG Diagram)

The following inline diagram summarizes the discrete alarm state transitions. The O transition is the source of the "duplicate" appearance when the alarm view is filtered on events rather than pending alarms.

12. Acknowledgment Tag and Group Acknowledgment

Each discrete alarm in TIA Portal can optionally use an acknowledgment tag — a Boolean tag the operator toggles (e.g., via a button on the screen) to acknowledge that alarm. When an acknowledgment tag is configured, the HMI writes a 1-pulse to the PLC, which the PLC can use to clear the underlying condition or log the operator action.

For batch acknowledgment of multiple alarms, the alarm view toolbar offers Acknowledge visible. This sends an acknowledgment pulse for all visible (filtered) rows. To use this with the "Pending alarms" filter, ensure that the filter is set before the operator presses the key; otherwise the operator will acknowledge only the visible subset.

13. Common Pitfalls

• Mixing alarm filters across screens. If Screen A uses "Pending alarms" and Screen B uses "Alarm events" for the same HMI tag, operators will report inconsistent behavior. Standardize on a single filter per project.
• Configuring the alarm class to "Without acknowledgment" for safety-related alarms. This is a functional safety violation in most industries. Safety alarms must require acknowledgment.
• Using the same alarm text for two different trigger tags. Operators cannot distinguish the two, and a duplicate display is the typical symptom. Always include the tag name or a unique identifier in the alarm text.
• Not compiling after property changes. Some filter and column changes are not visible on the live panel until a full HMI compile + download is performed. Partial download of the screens only may not propagate alarm view properties on older firmware.
• Ignoring panel firmware version. Comfort Panel firmware < V14 does not support all TIA Portal V17 alarm view properties. Upgrade panel firmware via ProSave or the TIA Portal online portal.

14. Related Standards and References

Alarm handling on industrial HMIs is covered in part by:

• ISA-18.2 — Management of Alarm Systems for the Process Industries. Defines operator alarm load limits and alarm philosophy expectations.
• IEC 62682 — Alarm systems for the process industry. Mirrors the lifecycle and state model concepts used by TIA Portal alarm classes.
• NAMUR NE 107 — Status categories for field devices; relevant when importing diagnostic alarms from PROFIBUS/PROFINET devices.

These standards do not prescribe the "one row per trigger cycle" behavior; they prescribe alarm philosophy, prioritization, and operator workload. The TIA Portal configuration choices described in this article help satisfy those constraints on the operator-display layer.

15. FAQ