WinCC Comfort Alarm Class Button Color Change with S7-1200 PLC

Overview

This technical reference covers the configuration of an HMI indicator button whose graphic changes color according to the highest-priority active alarm class on a Siemens KTP700 Comfort panel paired with an S7-1200 CPU programmed in TIA Portal. The driving requirement is a single screen object that reflects the machine alarm status in real time: grey (idle), blue (information), yellow (warning), orange (operator action required), and red (fault / E-stop). Because WinCC Comfort and WinCC Advanced expose events only on individual discrete alarms and not on alarm classes as a whole, the class-to-color mapping must be derived from per-alarm state tags on the PLC side, encoded into a single INT, and consumed by an HMI graphic list tied to a tag whose acquisition mode guarantees cross-screen visibility.

The reference documents a working field architecture (FC "Colour" on the S7-1200 producing an INT 0–4 that drives a five-entry graphic list on the KTP700 Comfort), the underlying WinCC alarm model, the cyclic-continuous acquisition mode required for global tag behavior, and an alternative VB-script path using a scheduled task. The final section covers commissioning, verification, and a troubleshooting matrix keyed to common field symptoms such as the indicator failing to update when the screen is not active, scripts not firing, or alarm classes returning unexpected values.

System Architecture and Component Reference

The following components form the validated reference stack. Substitute equivalent SIMATIC panels and CPUs from the same family where applicable; the alarm model and tag configuration patterns are consistent across the Comfort, Advanced, and Professional WinCC lines.

All downloads, manuals, and firmware updates for these catalog numbers are available from the Siemens Industry Online Support portal. Search by catalog number for the corresponding operating instructions, device manuals, and firmware release notes.

WinCC Comfort Alarm Class Model

WinCC Comfort organizes alarms into discrete alarm classes that govern only the visual presentation of the alarm record (background color, acknowledgment icon, and font style in the alarm view and alarm line). Alarm classes are not a runtime status object: there is no system tag exposing "is any alarm in class X currently active," and no event fires when an alarm class transitions between empty and non-empty.

The default WinCC Comfort alarm classes are:

Each alarm configured in the HMI editor is assigned exactly one class. The runtime color and the alarm-buffering behavior (log target, print target, e-mail target) are inherited from the class definition under HMI Tags & Connections → Alarm Settings → Alarm Classes. The class identity is therefore a static metadata property of the alarm record, not a runtime process variable.

Each alarm record exposes a fixed set of runtime events on the HMI side:

• OnCome: fires the moment the alarm becomes active (coming edge).
• OnGo: fires when the alarm condition clears (going edge).
• OnAcknowledge: fires when the operator presses the ACK button.
• OnConfirm: fires on confirmation of an alarm that requires confirmation.

Derivation Strategy: PLC-Side Priority Encoding

Because the HMI cannot natively evaluate "which class is active," the pattern that scales best and survives recipe changes is to compute a single integer priority code on the PLC and let the HMI render it. This avoids per-alarm HMI scripting and produces a deterministic result that is identical across all screens.

The reference priority ladder is:

Reference SCL Implementation (FC "Colour")

The FC enumerates the discrete alarm state bits feeding the alarm-class decisions on the PLC and emits the highest-priority value that is currently set. The implementation in SCL (Structured Control Language) follows.

FUNCTION "Colour" : Int
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT
      i_RedAlarm    : Bool;   // TRUE = at least one alarm in Errors class active
      i_OrangeAlarm : Bool;   // TRUE = at least one alarm in Operator-Action class
      i_YellowAlarm : Bool;   // TRUE = at least one alarm in Warning class
      i_BlueAlarm   : Bool;   // TRUE = at least one alarm in Information class
   END_VAR
   VAR_OUTPUT
      retVal : Int;           // 0=Grey, 1=Blue, 2=Yellow, 3=Orange, 4=Red
   END_VAR
BEGIN
   IF #i_RedAlarm THEN
      #retVal := 4;                            // Highest priority wins
   ELSIF #i_OrangeAlarm THEN
      #retVal := 3;
   ELSIF #i_YellowAlarm THEN
      #retVal := 2;
   ELSIF #i_BlueAlarm THEN
      #retVal := 1;
   ELSE
      #retVal := 0;                            // No alarm in monitored classes
   END_IF;
END_FUNCTION

The FC is called cyclically from a program cycle OB (OB1) at a 100 ms rate, which is sufficient for operator-perceptible alarm indication. If the machine must reflect sub-100 ms events (for example, a safety trip), raise the OB1 cycle priority or call the FC from a time-of-day interrupt OB10 / cyclic interrupt OB30. Avoid call rates faster than 50 ms; the HMI tag poll rate is the limiting factor and faster cycles do not improve visible response.

Wiring the Boolean Inputs

There are two practical ways to feed the four boolean inputs:

1. From discrete PLC tags already driving the alarms. The alarms themselves are usually triggered from a PLC bit (e.g., dbAlarm.bEstopActive, dbAlarm.bOverloadWarn). The same bit is used as the alarm trigger in the HMI alarm configuration and as the input to the FC. This guarantees perfect consistency between what the alarm view shows and what the color code indicates.
2. From alarm acknowledgment flags: AckState bits on each alarm record. This is more fragile because acknowledged-but-still-active alarms would otherwise be invisible to the FC. Use only if the indicator must reflect only unacknowledged alarms.

HMI Graphic List Configuration

A graphic list is the correct HMI object for mapping an INT to a displayed bitmap. Configure under HMI Tags & Connections → Graphics Lists:

1. Create a new graphic list named, for example, AlarmColorList.
2. Set the list to List range 0..4 (five entries).
3. For each index, assign the desired PNG / BMP / SVG graphic representing the state. Recommended assets are 32×32 or 48×48 pixels for a 7" panel, transparent background:

4. Under Process value, select the PLC tag that carries the FC output. If the FC returns directly into a data block tag (e.g., DB_HMI.Status.intAlarmColor), use that tag. Otherwise create a tag in a shared DB and assign it to retVal via a move or by setting the FC output to a global tag.

HMI Tag Configuration and Acquisition Mode

This is the most common failure point in field deployments. WinCC tags have an acquisition mode that determines when the runtime polls the PLC. For a global status indicator that must update regardless of which screen is currently shown, the acquisition mode must be Cyclic continuous.

Configure the alarm-color tag as follows in the HMI tag editor:

• Acquisition mode: Cyclic continuous
• Acquisition cycle: 1 s (sufficient for human-perceptible color change; faster is wasteful of the HMI–PLC link bandwidth)
• PLC tag type: INT (16-bit)
• Connection: the HMI connection used by the project

HMI Button Configuration

The alarm indicator is typically a screen object of type Symbolic I/O field or Graphic view (WinCC Comfort) wired to the graphic list. To make it open the alarm view on press, configure:

1. Drag a Graphic view object onto the screen.
2. Under General → Graphic list, select AlarmColorList.
3. Under Animations → Appearance, ensure the graphic list tag is the same tag as the one bound in the graphic list itself. (If left empty, the graphic view defaults to the graphic-list's own tag.)
4. Under Events → Press, add the system function OpenScreen (or OpenScreenByNumber) and target the alarm screen template, for example Screen_Alarms.
5. Under Events → Release, no action is required; remove any unintended system functions.
6. Under Security → Authorization, leave at the lowest level so the indicator is visible at all operator login levels.

If the object must also flash when new alarms are present, use Animations → Appearance → Flashing and tie it to a separate boolean tag that mirrors the unacknowledged count > 0 condition computed in the PLC.

Alternative Path: VB Script in a Scheduled Task

For projects where the PLC cannot be modified (legacy retrofit, vendor-locked controller, third-party PLC), the priority code can be reconstructed entirely in the HMI runtime using a VB script executed by a scheduled task. This path is heavier, harder to maintain, and not recommended where the PLC is accessible, but it works.

Approach

1. Create one boolean HMI tag per alarm state of interest. These tags are updated either by alarm events → tag write on each alarm or by mirroring the PLC source bits directly into HMI tags.
2. Create an internal INT tag intAlarmColor on the HMI.
3. Under Schedules → Scheduled Tasks, create a task with a 500 ms cycle that runs the following VBScript:

' Script: UpdateAlarmColor
' Source: each HMI tag is the OnCome latch of one alarm
' Priority: Red > Orange > Yellow > Blue
If SmartTags("bRedAlarm") Then
    SmartTags("intAlarmColor") = 4
ElseIf SmartTags("bOrangeAlarm") Then
    SmartTags("intAlarmColor") = 3
ElseIf SmartTags("bYellowAlarm") Then
    SmartTags("intAlarmColor") = 2
ElseIf SmartTags("bBlueAlarm") Then
    SmartTags("intAlarmColor") = 1
Else
    SmartTags("intAlarmColor") = 0
End If

4. Bind the same internal tag intAlarmColor to the graphic list as described in the PLC-side approach.

Commissioning Procedure

The following sequence should be executed by the commissioning engineer with the panel online to the PLC.

1. Verify the FC is compiled and loaded. In the S7-1200 project tree, confirm Colour is present under Program blocks, with no compile errors. Download to the PLC if needed.
2. Watch the FC inputs online. Open the PLC in Online & Diagnostics, monitor each boolean input of Colour. Force a known alarm bit (e.g., the E-stop trigger) on and confirm the corresponding FC input transitions to TRUE.
3. Watch the FC output online. With the E-stop forced, confirm retVal = 4. Force the E-stop off and a yellow alarm bit on, confirm retVal = 2. Force both, confirm priority holds at 4.
4. Verify the HMI tag poll. On the panel, enter the alarm screen and use the Tag diagnostics tool (or TIA Portal Online → HMI Tags) to confirm the tag value matches the FC output. Cycle through every priority and verify five distinct tag values.
5. Verify cross-screen behavior. From the main screen, force the E-stop and confirm the indicator on the main screen turns red without opening the alarm screen. If it does not turn red, the tag is on Cyclic in screen — correct the acquisition mode.
6. Verify acknowledgment does not affect the color. Force the E-stop, acknowledge the alarm, and confirm the indicator stays red until the underlying trigger clears (assuming the project requirement is "show current alarm state," not "show unacknowledged state").
7. Verify flash animation (if configured). Force a new alarm and confirm the indicator flashes. Acknowledge and confirm the flash stops while the underlying alarm remains active.
8. Document and lock. Record the FC tag, the HMI graphic list name, and the priority mapping in the project documentation. Lock the FC with know-how protection if intellectual property applies.

Verification and Acceptance Criteria

The implementation passes acceptance when the following observable conditions hold on the live system:

Troubleshooting Matrix

Extended Considerations and Edge Cases

Safety Alarms

If the red class contains safety-relevant alarms (E-stop, guard-door interlock, light curtain break), confirm that the FC and the HMI tag are not the only indication. The safety function itself must be executed on the F-CPU or a fail-safe output; the HMI is supplementary. Tag latency on a Comfort panel can reach 2–3 s under load and must not be relied on for safety.

Multi-Color Alarm Classes

Where more than five severity tiers are required, extend the FC to output a wider range (for example, 0..15 if the graphic list supports that many entries) and define additional graphic list entries. The PLC priority encoder remains identical in structure.

Multiple Panels

If a second panel mirrors the first (e.g., a remote KTP900 on a pendant), each panel must have its own HMI tag binding to the same PLC tag. The acquisition mode must be set to Cyclic continuous on both panels. Cross-panel consistency is not guaranteed by WinCC runtime; both panels poll the PLC independently.

Recipe-Based Alarm Class Mapping

Where different recipes map the same PLC bit to different alarm classes (for example, "low lubricant pressure" is a warning in one recipe and an error in another), the FC must be parameterized by the recipe number. Add a recipe-ID input to the FC and a CASE structure that selects the FC inputs based on the current recipe.

Firmware Compatibility

Older S7-1200 firmware (V4.0–V4.2) supports the FC pattern unchanged but has a lower limit on simultaneous cyclic tags. On V4.0–V4.1 CPUs, keep the number of cross-screen cyclic tags below 64 to avoid watchdog-triggered CPU stops. Comfort panel HMI image V14 and later fully support the pattern; V13 requires the graphic list index to start at 1 instead of 0.

OPC UA Path

If the alarm color must be exposed to a higher-level SCADA via OPC UA on the S7-1200 (which provides an OPC UA server starting with firmware V4.4), expose the FC output DB tag as an OPC UA node. The SCADA can subscribe and render the same color code without further configuration.

Reference Documentation

• Siemens Industry Online Support — product manuals, firmware, FAQs for S7-1200 and Comfort panels
• S7-1200 Programmable Controller System Manual — search by catalog number 6ES7214-1AG40-0XB0 or 6ES7215-1AG40-0XB0
• KTP700 Comfort Operating Instructions — search by catalog number 6AV2124-1GC01-0AX0
• WinCC Comfort / WinCC Advanced Engineering Manual — integrated in TIA Portal Help under "Visualizing Processes → Working with Alarms"