Siemens Comfort Panel Alarm Class Supervision: PLC Trigger

Engineer field reference for supervising Siemens Comfort Panel alarm classes and triggering dedicated PLC bits when unacknowledged alarms exist. Covers TIA Portal V20 ProDiag integration, VBScript polling workarounds, and PLC-side aggregation when the WinCC Professional Runtime alarm object is not available on the HMI.

Overview

WinCC Professional Runtime exposes a complete alarm object model that lets scripts query class-level state directly ("any unacknowledged alarm in class X"). Comfort Panels run WinCC Comfort or WinCC Advanced Runtime, which implements a deliberately smaller scripting surface. The sample project described in the Siemens Support post 135130 for WinCC Professional V13 SP1 drives a horn and warning lamp by evaluating alarm-class state inside a VBScript that calls the full alarm object. That script depends on alarm object methods not present in Comfort Panel Runtime and cannot be ported verbatim.

This reference documents three engineering approaches that do work on a Comfort Panel, ordered by reliability and license cost:

1. Tag-based acknowledgment state per alarm, aggregated in the PLC by class. Works on every Comfort Panel firmware from V11 onward and on every WinCC Comfort/Advanced license.
2. ProDiag-based visualization with TIA Portal V20, which adds code-level monitoring alarms and class-filtered alarm views on Panels, Comfort Panels, and RT Advanced/Professional.
3. Scheduled VBScript polling of the HMI alarm buffer where the Comfort Panel Runtime license permits script execution against the alarm subsystem.

All three produce a single boolean tag per alarm class on the PLC side. The PLC uses that boolean to drive a horn, a beacon, an SMS sender, or an alarm forwarding function block.

Prerequisites

The Comfort Panel Runtime Limitation

WinCC Professional Runtime and WinCC Comfort Runtime share the alarm configuration screens in TIA Portal but expose different runtime APIs. The differences that matter for this problem are:

• Alarm object scripting surface: The full alarm object model with class-state queries, event-driven scripts, and centralized buffer access is fully available on PC Runtime. Comfort Panels allow VBScript but the function set against the alarm subsystem is restricted; calling unsupported methods on the alarm object returns a Runtime error rather than a defined value. The Comfort Panel script environment does not expose a method that returns "any unacknowledged alarm in class X" as a single call.
• HMI-side aggregation: A Comfort Panel cannot natively publish a per-class boolean to the PLC. The acknowledgment state of each individual alarm is a per-alarm Runtime value, not an aggregate. Any class-level boolean has to be derived either on the PLC side (by feeding it per-alarm state) or on the HMI side via a scheduled script that emulates the missing query.
• Event-driven alarm scripts: The WinCC Professional sample referenced above uses an event-driven alarm script that fires on state change. Comfort Panels support scheduled scripts but the event-driven alarm hookup is more limited; in practice, polling is the only reliable path on a Comfort Panel.
• Alarm buffer size: the default Comfort Panel alarm buffer is typically 512 entries. A project with thousands of alarms must size the buffer explicitly under Runtime Settings > Alarms.

The Siemens support thread post 132006 covers alarm class configuration and confirms that the API-level class-state query is not exposed on Comfort Panels.

Result: a Comfort Panel cannot give you a one-shot answer to "any unacknowledged in class X". The aggregate has to be computed either on the PLC side (by feeding it per-alarm state) or on the HMI side via a workaround script.

Method Comparison

Engineers should default to Method 1. Methods 2 and 3 are supplements, not replacements. ProDiag in particular is a code-monitoring framework, not a class-aggregation tool; it does not answer "any unacknowledged in class X" for the project's existing discrete/analog alarms.

Method 1: Tag-Based Acknowledgment State

The most reliable approach. Each alarm is configured to write its acknowledgment state to a dedicated bit in an HMI tag. The PLC OR-aggregates those bits per alarm class and exposes a single boolean per class to the rest of the program.

HMI Alarm Configuration

1. In the TIA Portal project tree, open HMI alarms > Discrete alarms (or analog alarms, depending on the application).
2. Select the first alarm, open Properties > Settings, and assign an acknowledgment tag in the trigger section. WinCC Comfort supports a 1-bit acknowledgment tag per alarm.
3. Set the tag's update mode to "On change" so the PLC sees both the rising edge (alarm raised, not yet acknowledged) and the falling edge (alarm acknowledged or cleared).
4. Assign each alarm to one of the three alarm classes you created earlier.
5. Repeat for every alarm in the project, allocating a unique bit offset in a structured HMI tag (a Word or DWord mapped to a PLC data block).
6. Compile and download the HMI project. The HMI now writes the acknowledgment state of every alarm to its assigned bit.

Bit Layout Convention

Use a single HMI tag of type Word or DWord per alarm class so the PLC can OR the whole word in a single instruction. The example below assumes 16 alarms per class maximum; for up to 32 alarms use a DWord.

Within each word, allocate bit 0 to alarm 1, bit 1 to alarm 2, and so on. Document the mapping in a project spreadsheet so future alarm additions do not collide. Reserve bit 15 of each word for a "synthetic" alarm raised from the PLC side (e.g. a heart-beat that always forces the aggregate up while the PLC is running, used for diagnostics).

Why This Works

WinCC Comfort writes the acknowledgment tag exactly when the alarm state transitions. If the bit is set in the alarm word, it indicates "raised and not yet acknowledged". The PLC OR-aggregates the word and produces a single class has unacknowledged boolean. The acknowledgment tag in WinCC Comfort follows the convention: 1 = unacknowledged active, 0 = acknowledged or inactive. Verify this against your project's alarm settings; the convention matches the standard WinCC behavior used in the WinCC Professional V13 SP1 reference sample.

Method 2: ProDiag-Based Visualization (TIA Portal V20)

ProDiag is a TIA Portal capability that provides detailed monitoring of PLC program execution. It is licensed on the PLC side and visualized on the HMI. With TIA Portal V20, ProDiag alarms are displayable on Panels, Comfort Panels, and RT Advanced/Professional, as documented in the ProDiag alarm view configuration guide.

Enabling ProDiag

1. In the PLC device configuration, open Properties > Runtime > ProDiag and enable the ProDiag functions for the CPU.
2. Ensure the panel firmware supports the ProDiag HMI runtime extension. TIA Portal V20 documentation explicitly lists Comfort Panels as supported targets.
3. Place ProDiag-typed blocks in the PLC program (typically a GRAPH sequencer or HLFB block). The PLC automatically generates ProDiag alarms when block conditions are violated.
4. Assign each ProDiag alarm to one of the three alarm classes created in the HMI project.

Filtering the HMI Alarm View by Class

1. Open the screen that contains the alarm view, select the view, and switch to Properties > General.
2. In the filter section, select the alarm classes that the view should display. The configuration step is shown in the TIA Portal V20 ProDiag alarm view documentation.
3. Configure a separate alarm view per class if the operator needs to see them in isolation (typical for a dedicated "Critical Alarms" tab).
4. Use the Properties > Layout dialog to give each class view a distinct background color so operators can identify the class at a glance.

Trade-offs

ProDiag requires an S7-1500 (or limited S7-1200) CPU with a ProDiag license, plus a Comfort Panel that supports the V20 ProDiag HMI extension. On older panels or older TIA Portal versions, the ProDiag HMI integration is not available and Method 1 must be used for the entire project. For mixed fleets (some panels V20, some older), accept that ProDiag alarms will only display on the newer panels and let Method 1 drive the PLC.

Method 3: Scheduled VBScript Polling

If the project does not have a PLC powerful enough to OR dozens of bits per cycle, or if the engineer wants a single HMI-side computed tag, use a scheduled VBScript to evaluate the alarm buffer and write a class-level tag.

Script Skeleton (Conceptual)

The exact VBScript API for filtering alarms by class on a Comfort Panel is not exhaustively documented in the public Siemens function manual; the engineer should test the call on the target panel firmware. A representative polling skeleton is shown below; treat the buffer-iteration primitives as a starting point and verify against the panel's Runtime help.

Sub PollAlarmClasses()
    Dim i, sClass
    ' Reset aggregates
    SmartTags("PLC_Class1_Unack") = False
    SmartTags("PLC_Class2_Unack") = False
    SmartTags("PLC_Class3_Unack") = False
    ' Iterate visible alarm entries
    For i = 0 To AlarmBuffer.Count - 1
        sClass = AlarmBuffer.Item(i).Class
        If AlarmBuffer.Item(i).State = hmiAlarmStateUnacknowledged Then
            Select Case sClass
                Case "Class_1": SmartTags("PLC_Class1_Unack") = True
                Case "Class_2": SmartTags("PLC_Class2_Unack") = True
                Case "Class_3": SmartTags("PLC_Class3_Unack") = True
            End Select
        End If
    Next
End Sub

Scheduling the Script

Configure a Scheduler > Trigger task in the HMI project that runs the script every 500 ms to 1000 ms. The HMI tag PLC_ClassX_Unack is a normal HMI tag connected to a PLC tag, so any change is pushed to the PLC over the fieldbus on the next acquisition cycle. Avoid periods below 250 ms; the Comfort Panel's script scheduler can saturate and starve other HMI tasks.

Edge Cases and Caveats

• Comfort Panel reboot: the script stops running until the panel completes startup. Method 1 has the same limitation but the PLC tags retain their last value.
• Alarm buffer overflow: if more than the buffer capacity of unacknowledged alarms exist, the script may miss older entries. Configure the alarm buffer size in the HMI Runtime settings to match the worst-case alarm count.
• Class identifier vs display name: WinCC Comfort uses internal class identifiers, not the human-readable name. The "Class_1" string above is illustrative; check the project's alarm class identifier to determine the exact value to compare against.
• Script Runtime error: if the panel's Runtime does not expose the alarm buffer API, the script raises a Runtime error visible in the HMI diagnostic viewer. In that case, fall back to Method 1; tag-based aggregation does not use the alarm scripting object.
• Concurrent alarms in the same class: a single pass through the alarm buffer correctly identifies the class-aggregate because the script sets the output tag to True if any unacknowledged alarm of that class exists. The reset at the start of each pass prevents the output from being sticky across cycles.

PLC Program Sample (S7-1500 / S7-1200)

The PLC side is identical for all three methods. The aggregated class-level booleans are written by the HMI; the PLC publishes them and adds the standard handling (edge detection, latching, masking by operator enable).

Data Block Layout (SCL)

DATA_BLOCK "DB_AlarmClass"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
   STRUCT
      Class1_Unack       : Bool;   // Any unacknowledged alarm in class 1
      Class2_Unack       : Bool;
      Class3_Unack       : Bool;
      Class1_Latch       : Bool;   // Latched until operator reset
      Class2_Latch       : Bool;
      Class3_Latch       : Bool;
      Class1_Edge_Memory : Bool;   // Edge detection helper
      Class2_Edge_Memory : Bool;
      Class3_Edge_Memory : Bool;
      Horn_Out           : Bool;   // Combined horn trigger
   END_STRUCT;
END_DATA_BLOCK

Aggregation and Latching Logic (SCL)

// Method 1: PLC-side OR aggregation of acknowledgment tag words.
// "HMI_Alarms_ClassX" is a Word HMI tag; bit n = alarm n of class X.
"DB_AlarmClass".Class1_Unack := "HMI_Alarms_Class1" <> 16#0000;
"DB_AlarmClass".Class2_Unack := "HMI_Alarms_Class2" <> 16#0000;
"DB_AlarmClass".Class3_Unack := "HMI_Alarms_Class3" <> 16#0000;

// Latch the unacknowledged state so a momentary flicker does not
// release a beacon. Latch resets when the operator acknowledges
// ALL alarms of that class (i.e. the aggregate returns to FALSE).
IF "DB_AlarmClass".Class1_Unack THEN
    "DB_AlarmClass".Class1_Latch := TRUE;
END_IF;
IF NOT "DB_AlarmClass".Class1_Unack AND "HMI_Ack_Class1" THEN
    "DB_AlarmClass".Class1_Latch := FALSE;
END_IF;
// Repeat the block for Class2 and Class3.

// Horn trigger: rising edge of any class latch.
"DB_AlarmClass".Horn_Out := "DB_AlarmClass".Class1_Latch
                        OR "DB_AlarmClass".Class2_Latch
                        OR "DB_AlarmClass".Class3_Latch;

For S7-300/400 use STL or LAD with the equivalent OW and <>0 instructions. The HMI word is moved into a temporary, OR-aggregated with the running total, and compared to zero. The latch logic uses standard set/reset coil pairs in LAD.

Alarm Class Color Configuration

Operators differentiate alarm classes at a glance. Configure the class colors in the HMI project so the unacknowledged state is visually distinct. Per Siemens Support forum post 1270551, WinCC Comfort exposes the alarm class colors under HMI alarms > Alarm classes. The recommended color convention is:

Verification and Commissioning

1. Compile and download the HMI project to the Comfort Panel and the PLC project to the CPU.
2. Trigger a test alarm in class 1 (force the trigger tag in the PLC). Verify the HMI_Alarms_Class1 word shows the corresponding bit as 1 in the HMI tag table (online > monitor).
3. Verify the aggregate: the Class1_Unack boolean in the PLC should switch to TRUE within one cycle of the bit being set.
4. Acknowledge the alarm on the HMI. The bit must fall to 0 and the aggregate must fall to FALSE within one cycle.
5. Repeat for all three classes. Stress-test with simultaneous alarms in multiple classes to ensure the OR aggregation is correct.
6. Test the latch: clear a momentary alarm and confirm the latch holds until the operator acknowledges (or until the configured latch reset condition).
7. If using Method 3: temporarily reduce the scheduler period to 100 ms and confirm the script executes without Runtime errors in the HMI diagnostic viewer.
8. Operator acceptance: have the operator confirm the alarm colors meet the site's standards before sign-off.
9. Power-cycle test: power down the Comfort Panel, bring it back up, and confirm the aggregates return to FALSE within one acquisition cycle. Stale state from a previous session is a common cause of phantom horn triggers.
10. Network-load test: with the PLC running at peak cycle load, verify the HMI tag update does not stall. Add a diagnostic tag that counts tag updates per second and alarm if it drops below 5 Hz.

Troubleshooting Matrix

Field-proven caveats to keep in mind: the Comfort Panel loses Runtime state on power cycle, so the PLC must rely on the HMI reinitializing the acknowledgment tags to 0 at startup. If the project allows the operator to mute a single alarm without acknowledging, the acknowledgment tag may transition differently from the visible state; cross-check the alarm configuration's Acknowledgment setting ("On acknowledgment" vs "On reset"). For distributed I/O on PROFINET with sub-millisecond cycle, the HMI tag update can lag by several PLC cycles; the aggregation still works but the operator may see a one-cycle delay. If more than one Comfort Panel writes to the same acknowledgment tag (primary and mirror panel), designate a single owning panel or OR the values from both panels on the PLC side.

FAQ