WinCC Comfort: Cycle All Active Alarms in Single Line View on TP900/TP1900 Comfort

On a SIMATIC TP900 Comfort or TP1900 Comfort panel running WinCC Comfort V16 (TIA Portal V16 Update 6), the configured Alarm Line control shows only the first or the last entry of the active alarm queue, never all of them. The control is single-line by design: it reserves exactly one row on the screen and binds that row to a single record selected by the configured sort order. This article documents the root cause, the limits of the WinCC Comfort alarm API, and a robust, in-field-proven PLC-driven filter cycling workaround that rotates the display through every active alarm at a configurable dwell time, while keeping the original alarm text (with its dynamic process-value fields) intact.

1. Problem Definition

The Alarm Line control is a one-row, low-profile alarm indicator typically placed in the title bar or footer of a Comfort screen. The expected behaviour on panels with a small visible status area is:

• Show the most recent unacknowledged alarm, OR
• Cycle through all current active alarms at a user-defined interval (commonly 2 to 3 seconds per alarm).

What the panel actually does in TIA V16:

• Show first → static display of the topmost alarm in the sort order; the field never refreshes while that alarm is still active.
• Show last → static display of the bottom alarm; the field never refreshes while that alarm is still active.

If more than one alarm is active simultaneously, the operator never sees the other entries unless they open the full Alarm View. The 2-3 second automatic rotation that operators expect from SCADA-style ticker behaviour is not a built-in property of the Alarm Line control on Comfort panels.

1.1 Engineering Impact

The problem is most visible on machines with densely packed alarms - printing lines, packaging cells, conveyor sorters, HVAC plants - where the panel has room for one line of text and a full alarm view would obscure the underlying process image. Operators rely on the single-line indicator to know how many distinct faults are present, not only the most recent one.

2. Root Cause: WinCC Comfort Alarm System Constraints

WinCC Comfort (the runtime shipped on Comfort Panels) is a deliberately trimmed-down SCADA engine compared to WinCC Advanced or WinCC Professional. The trimming matters here because two capabilities that would normally solve the problem are missing:

Consequence: the only programmable handle the HMI engineer has on the active alarm set at runtime is the filter string of the Alarm Line / Alarm View. The filter is a string property that can be bound to a PLC tag, and the runtime re-evaluates that string every time the tag changes. This single, well-defined hook is what the workaround below exploits.

3. Required Hardware and Software

References: Siemens Industry Online Support, TIA Portal V16 documentation collection, WinCC Comfort/Advanced V16 system manual, SIMATIC HMI Comfort Panels device manual.

4. Solution Architecture: PLC-Driven Filter Cycling

The workaround uses the Alarm Line's Filter property, bound to a PLC string tag, and rotates the value of that string so that the runtime shows a different alarm every N seconds.

The PLC owns the rotation logic; the HMI owns the alarm text rendering. The two meet at exactly one string tag that is updated by the PLC OB1 cycle and read by the Alarm Line every time its value changes.

5. Step 1 - HMI Alarm Configuration with Numeric Prefixes

Each alarm text entry must be unique and must contain a stable, machine-parseable prefix so that the filter can isolate exactly one alarm at a time.

5.1 Naming Convention

Use a fixed-width numeric prefix in front of the human-readable message. A 4-digit zero-padded prefix allows up to 9,999 uniquely-filterable alarms, which is well above the practical limit of any Comfort-panel project.

Open the HMI tags and alarms editor in TIA Portal V16, declare each as a discrete alarm, assign it to an alarm class (typically Errors for drive and process faults, Warnings for soft limits), and enter the alarm text exactly as above. The dynamic process-value fields (e.g. {Pressure} or station index) remain fully functional because they are still rendered by WinCC from the alarm buffer; the prefix is treated as part of the text only when filtering.

6. Step 2 - HMI Alarm Line Filter Binding

Place the Alarm Line control on the screen where the operator needs it. The default properties to adjust are:

Declare a new HMI tag HMI_FilterString of type WString length 8 (or String length 8, depending on the project), connected to the PLC tag of the same name. The length must be at least 5 characters to hold the prefix 0001 plus the implicit null terminator.

When the HMI tag value changes, the runtime re-evaluates the filter. Setting the filter to the string 0001 shows only the alarm whose text starts with 0001. Setting it to 0002 shows only the second one, and so on. Setting it to an empty string '' removes the filter and shows the first active alarm by sort order.

7. Step 3 - PLC Cycle Controller Implementation

The PLC owns the timing and the decision of which prefix to display. The following SCL block runs in OB1 (or in a cyclic OB 30 ms for tighter timing) and produces a new filter string every dwell time interval.

7.1 Data Block (DB of type)

TYPE "UDT_AlarmCycler"
  STRUCT
      arrActive    : ARRAY[1..64] OF BOOL;   // 1 = alarm active
      iCurrent     : INT;                    // Currently displayed index (0 = none)
      tDwell       : TIME;                   // Time per alarm, default 2 s
      bAnyActive   : BOOL;                   // Aggregate "at least one active"
      sFilterOut   : STRING[8];              // Filter string to HMI
  END_STRUCT;
END_TYPE

7.2 Function Block

FUNCTION_BLOCK "FB_AlarmCycler"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
VAR_INPUT
    iAlarmCount  : INT  := 64;     // Number of alarms to scan (1..64)
    tDwellTime   : TIME := T#2S;    // Display dwell time per alarm
END_VAR
VAR
    statTimer  : TON;              // Cycle dwell timer
    statIndex  : INT  := 0;        // Search start index
    statCur    : INT  := 0;        // Currently displayed alarm
    statI      : INT;              // Loop helper
    statPad    : STRING[4];        // Zero-padded prefix builder
END_VAR
VAR_OUTPUT
    sFilterString : STRING[8];     // Bound to HMI tag HMI_FilterString
END_VAR
BEGIN
    // 1. Aggregate: at least one alarm active?
    #statI.%X0 := FALSE;
    FOR #statI := 1 TO #iAlarmCount DO
        IF "DB_Alarms".arrActive[#statI] THEN
            #statI.%X0 := TRUE;   // abuse of the loop variable as a temp BOOL
            EXIT;
        END_IF;
    END_FOR;

    // 2. Run the dwell timer when something is active
    #statTimer(IN := #statI.%X0, PT := #tDwellTime);

    // 3. On dwell expiry (or on first activation), pick the next active alarm
    IF #statTimer.Q OR (#statCur = 0 AND #statI.%X0) THEN
        #statTimer(IN := FALSE);

        // Search forward from current+1, wrap once
        #statIndex := 0;
        FOR #statI := #statCur + 1 TO #iAlarmCount DO
            IF "DB_Alarms".arrActive[#statI] THEN
                #statIndex := #statI;
                EXIT;
            END_IF;
        END_FOR;

        IF #statIndex = 0 THEN
            FOR #statI := 1 TO #iAlarmCount DO
                IF "DB_Alarms".arrActive[#statI] THEN
                    #statIndex := #statI;
                    EXIT;
                END_IF;
            END_FOR;
        END_IF;

        #statCur := #statIndex;
    END_IF;

    // 4. Build the zero-padded filter string "0001" .. "0064"
    IF #statCur > 0 THEN
        #statPad := INT_TO_STRING(#statCur);
        // Left-pad to 4 characters
        WHILE LEN(#statPad) < 4 DO
            #statPad := CONCAT('0', #statPad);
        END_WHILE;
        #sFilterString := #statPad;
    ELSE
        #sFilterString := '';
    END_IF;

    // 5. Write to global filter tag (visible on HMI connection)
    "HMI_FilterString" := #sFilterString;
END_FUNCTION_BLOCK

7.3 Clean Production Variant

Replacing the loop-variable abuse with a dedicated variable:

VAR
    statAnyActive : BOOL;
END_VAR

BEGIN
    // 1. Aggregate
    #statAnyActive := FALSE;
    FOR #statI := 1 TO #iAlarmCount DO
        IF "DB_Alarms".arrActive[#statI] THEN
            #statAnyActive := TRUE;
            EXIT;
        END_IF;
    END_FOR;

    // 2. Timer and rotation step 3..4 identical to the listing above,
    //    but use #statAnyActive instead of #statI.%X0.
END_FUNCTION_BLOCK

7.4 Bit-to-Array Population

The DB of type UDT_AlarmCycler still has to be populated. The simplest way is a single block call in OB1 that maps the 64 alarm bits to arrActive[1..64]:

// OB1 - compress the 64 alarm bits into the array
"DB_Alarms".arrActive[1]  := "Alarm".MotorM12Overload;
"DB_Alarms".arrActive[2]  := "Alarm".ConveyorC4BeltSlip;
"DB_Alarms".arrActive[3]  := "Alarm".HydraulicLow;
"DB_Alarms".arrActive[4]  := "Alarm".SafetyDoorB;
// ... 5 .. 64 ...
"FB_AlarmCycler_DB"();    // call the cycler

For projects that already maintain an array of alarm bits, the explicit mapping collapses to a single MOVE_BLK or BLK_MOVE instruction.

8. Step 4 - Tag Mapping and Cycle Time Tuning

Bind the PLC tag "HMI_FilterString" to the HMI tag of the same name (default acquisition cycle 1 s is acceptable; the PLC owns the dwell time). Adjust the following parameters for the installed process:

For 64 alarms and a 30 ms OB35, the cycle FB adds less than 50 µs of CPU load on a CPU 1511-1 PN - well below any threshold worth worrying about.

9. Step 5 - Verification and Commissioning

Commissioning follows the standard Siemens V16 sequence. The checklist below targets the specific behaviour of the alarm cycler.

1. Download the PLC project, then the HMI project, to the panel.
2. Force the alarm bits one at a time. Confirm that the Alarm Line shows only the matching text, e.g. forcing arrActive[1] produces 0001 Motor M12 overload - station 3 in the line.
3. Force two alarms simultaneously (e.g. 0001 and 0003). The PLC should rotate between them every tDwellTime.
4. Force all 64 bits. Confirm that the cycle is smooth and that the prefix always has exactly 4 characters (no spaces, no leading/trailing garbage) - this validates the pad loop.
5. Clear all bits. The filter string should become '' and the Alarm Line should empty (or show the configured default), not freeze on the last prefix.
6. Force a non-existent prefix, e.g. set statCur := 99 in the FB. The runtime should display an empty Alarm Line - confirming that unmatched filters do not crash the line.
7. Trigger a 100 ms burst of all 64 alarms and then clear them. Confirm that the FB settles back to an empty filter within one dwell interval.

9.1 State Machine (Verification Aid)

9.2 Timing Diagram (Dwell = 2 s, 3 active alarms)

10. Edge Cases, Limitations, and Field Notes

11. Alternative Approaches on Comfort Panels

The PLC-driven filter method is the most robust, but three other techniques are sometimes considered. The table below ranks them for a TP900/TP1900 Comfort target.

For projects that need to move to WinCC Professional later, the same prefix scheme is harmless - the Professional runtime ignores the filter when no other filter is configured - so no rework is required at the upgrade boundary.

12. Frequently Asked Questions