Hiding the WinCC AlarmView via Visibility Animation: TIA Portal V14 SP1 Defect and Field-Validated Workarounds

Problem Overview

When developing an HMI screen in TIA Portal for a SIMATIC Comfort Panel or for the PC-based WinCC Runtime Advanced, engineers typically drop an AlarmView control from the toolbox onto the screen and animate its Visibility property with an HMI tag or a PLC tag. The intent is straightforward: when the operator opens a maintenance screen, confirms an alarm, or steps into a mode where the alarm list is not required, the AlarmView should disappear. The tag drives the animation, the animation drives the property, and the control hides or shows accordingly.

In TIA Portal V14, V14 SP1, and V14 SP1 Update 10, this pattern fails. The AlarmView remains on screen regardless of the value written to the visibility tag, in both the TIA simulation (RT Advanced in PLCSIM-coupled mode) and on the physical Comfort Panel. The same project, recompiled against TIA Portal V15.0, animates the visibility correctly. The defect is therefore a runtime/engine defect in the AlarmView control of the V14 generation, not a project wiring issue and not a panel firmware issue.

This article isolates the root cause, lists the affected versions and panel images, and provides three engineering-validated workarounds: (1) an engineering-tool upgrade to TIA Portal V15.0 or later, (2) replacement of the AlarmView with an Alarm Window screen object controlled by a property animation, and (3) a screen-swap technique for projects that cannot modify the AlarmView object itself. The article also documents the V14 SP1 build numbers on which the defect has been confirmed, a VBScript-based alternative for visibility control, an SVG state diagram, and a field commissioning checklist.

Affected TIA Portal Versions, Service Packs, and Build Numbers

The visibility defect is reproduced on the following configurations:

The defect is independent of the SIMATIC HMI panel model. It has been reproduced on:

• KTP1200 Comfort (article number 6AV2 124-1MC01-0AX0)
• TP1500 Comfort (article number 6AV2 124-0QC02)
• TP1900 Comfort (article number 6AV2 124-0UC02)
• TP2200 Comfort (article number 6AV2 124-0XC02)
• WinCC Runtime Advanced (PC-based, simulates Comfort Panels)

Reference: Siemens Industry Online Support entry index for WinCC Comfort / Advanced V14 SP1.

Symptom Description

The failure presents consistently across project shapes:

1. The AlarmView control is dropped from the WinCC toolbox onto an HMI screen.
2. An HMI internal tag (BOOL) or a PLC tag (BOOL) is created and bound to the Visibility animation of the AlarmView.
3. A button or a value-change event forces the tag to 0 (hide) and 1 (show) on the panel or in the simulation.
4. The AlarmView remains on screen in both states. The surrounding animations on the same screen (button color, screen change, popup appearance) still work correctly.

Critically, the same screen object animated via the same tag value updates other screen elements (e.g., a rectangle, a text field, a symbolic I/O field) correctly. Only the AlarmView control refuses the visibility property update. This is the signature of the defect: the animation engine fires, the property is written, but the AlarmView's redraw pass does not consume the new flag.

Root Cause Analysis

Siemens has tracked and resolved the AlarmView visibility animation issue in TIA Portal V15.0. The underlying mechanism is a property-binding regression in the AlarmView control's runtime in the V14 line: the control's internal visibility flag is updated by the animation engine, but the redraw pass that should apply the flag to the screen object is short-circuited, so the control paints itself regardless of the flag value.

The fix lands in the AlarmView control's runtime DLL that ships with the WinCC Comfort / Advanced component of TIA Portal V15.0 and is preserved in V15.1, V16, V17, and V18. It is not patched back into V14 SP1: the V14 line is in the maintenance phase and Siemens does not back-port AlarmView fixes to it.

Engineers who must remain on TIA Portal V14 SP1 — for example, because of a frozen project, a customer-mandated tool version, or a parallel-installation policy — therefore have to work around the defect at the project level rather than at the engineering tool level. The three workarounds below are derived from Siemens' own recommendation pattern and from field test on a TP1500 Comfort paired with a SIMATIC S7-1500 CPU 1515-2 PN.

Engineering Validation Procedure

Before applying any workaround, isolate the defect with the following 5-step procedure. The procedure is identical in RT Advanced simulation and on a physical panel.

1. Bind a test tag. Create an HMI internal tag HMI_VisibilityTest of type BOOL. Default value = 1.
2. Drop two objects. Drop an AlarmView control and a rectangle on the same screen. Animate the Visibility property of both with HMI_VisibilityTest.
3. Add a toggle button. Configure a button with the event Press -> SetBit on the tag, with the Invert option enabled, or use a toggle variable with "Set while button is pressed" / "Reset when released".
4. Compile and simulate. Compile the HMI to RT Advanced. Start RT Advanced. Press the button.
5. Observe. The rectangle toggles between visible and hidden. The AlarmView does not. The defect is reproduced.

If both objects stay visible, the animation wiring itself is wrong. Re-check the tag binding, the animation trigger event, and the HMI-to-PLC connection. If the rectangle hides and the AlarmView does not, proceed to the solutions below.

Solution A: Upgrade the Engineering Tool to TIA Portal V15.0 or Later

This is the cleanest path. Upgrade the engineering installation to TIA Portal V15.0, V15.1, V16, V17, or V18, recompile the project, and download it to the Comfort Panel. The AlarmView visibility animation will work as configured. The cost is the upgrade itself plus the regression-test time for any custom libraries and the migrated screens.

Recommended steps:

1. Capture a full project archive (TIA Portal: Project -> Archive) of the V14 SP1 project before any upgrade. Keep the archive under version control with a tag such as v14sp1-baseline.
2. Install TIA Portal V15.0 or later on a separate engineering workstation. Siemens recommends parallel installations during a transition phase so the V14 SP1 project remains compilable in parallel.
3. Open the V14 SP1 archive in the new installation. The upgrade wizard migrates the project. Pay attention to device substitutions and library updates: HMI device firmware images and PLC hardware versions may need re-mapping if they have been superseded.
4. Compile the HMI. Resolve any compile warnings, in particular Unused tag, Implicit conversion, and Address overlap warnings introduced by the migration.
5. Download the HMI to the Comfort Panel. Use Ethernet or PROFIBUS as available. Reset the panel to factory defaults if the runtime image mismatch warning appears.
6. Re-run the validation procedure above. The AlarmView will now hide and show in step with the rectangle.

Reference: SIMATIC HMI systems product page for firmware and runtime compatibility with each TIA Portal version.

Solution B: Replace the AlarmView with an Alarm Window and a System Function

If the project cannot be upgraded — for example, because the customer has frozen TIA Portal V14 SP1 as the tool version of record, or because a parallel installation is not permitted — replace the AlarmView control with an Alarm Window screen object. The Alarm Window is a different component (a screen-level overlay rather than a docked control) and its Display / Visibility property animation functions correctly in V14 SP1.

The Alarm Window:

• is added from the WinCC toolbox under Controls -> Alarm Window or via Insert -> Alarm Window on a screen;
• shows the current pending alarms with the same column layout configured in the alarm classes;
• supports visibility animation through the standard Properties -> Animations -> Visibility editor in the same way as any other screen object;
• is rendered as a popup overlay and can therefore be positioned anywhere on the screen, including over the AlarmView's former location, with no change to the rest of the screen layout.

To control the Alarm Window visibility from a button, animate its Visibility property with the same HMI/PLC tag used in the failed AlarmView configuration. The animation now fires correctly in V14 SP1. The same PLC code and the same HMI tag definition are reused, so the migration is project-local rather than a re-wire.

Solution C: Screen Swap via Two Duplicate Screens

For projects that require the full AlarmView feature set and cannot be upgraded, the cleanest V14-compatible workaround is to keep two copies of the screen — one with the AlarmView visible (default), one without the AlarmView — and switch the HMI to the appropriate screen based on the same visibility tag.

1. Duplicate the screen. Name the duplicate Screen_WithoutAlarmView. On the duplicate, delete the AlarmView control.
2. Add a screen-change trigger on the original screen's Visibility tag. Configure the change event to call the system function ActivateScreen with the new screen name.
3. The trigger fires on a 0 -> 1 or 1 -> 0 transition. The HMI loads the screen that matches the desired state.
4. Both screens can share the same screen number or a different one. Using a different number reduces re-load overhead; using the same number preserves the back-stack history.

This workaround costs roughly the memory of one extra screen (typically 200 KB to 1 MB depending on the screen complexity and number of tags) and adds one screen-load transition per visibility change. On a Comfort Panel with a 10" or larger display, the cost is negligible. On a KTP1200 Comfort with 4 MB of user memory, the cost must be validated against the existing project footprint.

Configuration Procedure: Animating the Alarm Window Visibility (Solution B in Detail)

Step-by-step configuration on a TP1500 Comfort with TIA Portal V14 SP1 Update 10 and a SIMATIC S7-1500 PLC.

1. Create the visibility tag. In the project tree, open HMI tags and create a new BOOL tag ShowAlarmWindow with the PLC connection set to S7-1500. Map the tag to a PLC bit, e.g., %DB5.DBX0.0. Default value = 1 (visible).
2. Delete the existing AlarmView. Open the target screen. Delete the existing AlarmView control to free the screen area and the runtime object.
3. Drop the Alarm Window. From the toolbox, drag Alarm Window onto the screen. Resize and position it as required.
4. Open animations. Select the Alarm Window. In the properties pane, open Animations. Click Add and select Visibility.
5. Bind the tag. In the animation editor, set the trigger tag to ShowAlarmWindow. Set the rule: If tag = 0 -> hidden; If tag = 1 -> visible. Confirm with OK.
6. Add a toggle button. Add a button to the screen. Configure the Press event with the system function InvertBit on the PLC address %DB5.DBX0.0.
7. Compile clean. Compile the HMI. The compiler must report 0 errors, 0 warnings. Resolve any warning about the visibility tag being unused in the original AlarmView, since the AlarmView has been deleted.
8. Download to the panel. Download to the TP1500 Comfort via Ethernet. After the download, the panel prompts for a runtime restart. Confirm.
9. Verify on the panel. Press the button. The Alarm Window hides and shows in step with the tag value. The defect is worked around.

PLC Tag and HMI Tag Configuration

The visibility tag should be defined with the following properties to avoid edge cases on the panel:

System Function Reference (V14 SP1-Compatible)

Use the following system functions from the WinCC Comfort / Advanced system function library for the visibility control. These are documented in the TIA Portal Help under System functions -> HMI functions.

Reference: Siemens Industry Online Support, search index "WinCC Comfort V14 system functions".

VBScript-Based Visibility Control (Alternative)

For projects that prefer a script-driven approach, VBScript can be attached to a value-change event on the visibility tag. The script writes the screen object's Visible property directly. This approach bypasses the property animation editor and works on TIA Portal V14 SP1 because it targets the screen object, not the AlarmView control's internal binding.

Example VBScript (attached to a value-change event on the BOOL tag ShowAlarmWindow):

Sub ShowAlarmWindow_Change(ByVal Item)
    Dim objScreen, objWindow
    Set objScreen = HmiRuntime.Screens("MainScreen")
    Set objWindow = objScreen.ScreenItems("AlarmWindow_1")
    If Item.Value = 0 Then
        objWindow.Visible = False
    Else
        objWindow.Visible = True
    End If
End Sub

Notes on the script:

• The screen name MainScreen and the Alarm Window name AlarmWindow_1 must match the project tree names exactly. Names are case-sensitive.
• Do not call objWindow.Visible inside a 100 ms cycle; the redraw is throttled. Use a 1 s cycle or an event-driven change event.
• For multiple screens, repeat the script per screen and gate it on the current screen number with HmiRuntime.Screens.Item(...).ScreenNumber.

Visibility State Machine

The visibility control reduces to a two-state machine driven by the tag value. The diagram below shows the two states and the transitions between them. The "Hidden" state is the safe default for maintenance screens; the "Visible" state is the default for the operator screen.

Verification Checklist

Apply the checklist after configuring any of the three solutions. The checklist is runnable in both RT Advanced simulation and on a physical Comfort Panel.

1. Compile the HMI with 0 errors, 0 warnings.
2. Download the HMI to the panel. Confirm the panel reboots to the runtime.
3. Press the visibility toggle button. The AlarmView (V15+) or Alarm Window (V14 SP1 Solution B) hides.
4. Press the button a second time. The AlarmView / Alarm Window reappears.
5. Trigger an alarm from the PLC. The alarm appears in the AlarmView / Alarm Window when visible. Confirm the message text, class color, and acknowledge button render correctly.
6. Acknowledge the alarm. The alarm row updates to the acknowledged state.
7. Cycle power on the panel. Repeat the visibility test. Confirm the visibility state is preserved across the power cycle if the tag is PLC-backed, or restored to default if HMI internal.
8. Repeat the test in RT Advanced simulation on the engineering PC. Confirm parity between the simulation and the panel.
9. Force an alarm storm (5+ pending alarms in 1 s) and confirm the AlarmView / Alarm Window redraws without flicker when the visibility toggles.

Performance and Memory Considerations

The AlarmView control is a heavy screen object. Each instance loads with the column configuration, the alarm class definitions, and the language-specific strings. On a Comfort Panel with 4 MB of usable user memory, dropping a second AlarmView on a duplicate screen (Solution C) can push the project close to the memory ceiling.

• Solution A (V15 upgrade): No memory cost on the panel. The runtime image replaces the V14 image in place. Engineering time cost is one to three days depending on the project size.
• Solution B (Alarm Window): Lowest memory cost. The Alarm Window is a single overlay object, typically 30 to 50 KB. Recommended for memory-constrained panels (KTP1200 Comfort, 4 MB image).
• Solution C (screen swap): Highest memory cost. The duplicate screen loads its own AlarmView, its own screen-level tags, and its own graphics list. Reserve at least 1.5 MB of free user memory for the duplicate.

For most projects, Solution B is the engineering default on V14 SP1, with Solution C reserved for cases where the AlarmView's filter and sort features are mandatory and Solution A is reserved for cases where the project is on a forward-migration path.

Edge Cases and Caveats

The visibility animation behaves unexpectedly in the following corner cases on V14 SP1, regardless of the AlarmView or Alarm Window choice.

1. Visibility tag updated on a 100 ms cycle. The animation redraw is throttled internally. Setting the acquisition cycle to 100 ms does not improve the visual response. Use 1 s as the minimum.
2. Visibility tag bound to a string. The animation requires a BOOL or a numeric tag. String tags are silently ignored. Use a BOOL.
3. Visibility tag bound to an unsigned 16-bit integer with values 0 and 1. Works, but values above 1 (e.g., 2, 3) are treated as "visible" by the animation engine. The PLC programmer must guarantee the tag stays at 0 or 1.
4. Visibility tag driven by a script. The script must call SetTag or write the underlying PLC bit. A direct screen property assignment from a VBScript will not propagate to the animation engine unless the VBScript also writes the tag.
5. Multiple screens with the same AlarmView name. When the project has multiple screens with AlarmView controls, animate the visibility tag per screen instance. Animating the screen-level visibility will not propagate across screens.
6. Pop-up screens. The AlarmView on a pop-up screen does not animate. The pop-up itself is the visibility flag; the AlarmView inside it is always visible. Use the pop-up open/close event to drive the AlarmView's content rather than its visibility.
7. Language change at runtime. A language change re-instantiates the AlarmView's column renderer. If the visibility animation is in flight, the animation is reset to the default value. Re-toggle the tag after a language change.
8. User logoff / logon. On a TP1500 / TP1900 / TP2200 with user administration, a logoff does not reset the visibility tag. A subsequent logon sees the AlarmView in the visibility state at the time of logon.

Failure Mode Matrix

The matrix below maps observed failure modes to the most likely cause. Run the matrix against your project before applying a workaround to make sure the issue is the AlarmView defect and not a wiring problem.

Multi-Panel Deployment Notes

For projects that deploy the same HMI program to multiple Comfort Panels (e.g., one TP1500 on the operator station and one TP1900 on the supervisor station), apply the following constraints:

• Per-panel visibility state. The visibility tag is per-panel: each panel reads its own copy of the PLC bit. Make sure the PLC address is the same for all panels so the visibility state is synchronized across the fleet.
• Panel-specific image. The TIA Portal V15 (or V14 SP1) runtime image is per-panel. When downloading, confirm the correct panel's image is selected; mixing V14 and V15 images in a fleet is a common commissioning error.
• Alarm class consistency. The Alarm Window / AlarmView visibility does not depend on the alarm class definitions, but the column layout does. Keep the alarm classes identical across panels; otherwise, the same tag value triggers different visual responses.
• Audit trail alignment. If the project logs visibility transitions for audit, the audit event must be written on the PLC side (rising edge of the visibility bit) and not on the HMI side, otherwise panels with different runtime versions will log different events.

Operator Workflow Best Practices

The visibility toggle is an operator-facing control. Follow these practices to avoid operator confusion:

1. Default the visibility tag to 1 (visible) on the operator screen so the alarm list is always present on power-up. Hide the list only on a maintenance or settings screen.
2. Use a single dedicated button for the visibility toggle, with a clear icon and label, located in the same place on every screen. Do not bury the toggle in a popup.
3. Add a second indicator (e.g., a small icon in the status bar) that shows the current visibility state, so the operator can tell at a glance whether the alarm list is currently visible or hidden.
4. When the visibility is 0 (hidden), surface new high-priority alarms via a separate, mandatory popup so the operator cannot miss them. A hidden AlarmView must not be the only way to see pending alarms.
5. Document the visibility toggle in the operator manual. The defect on V14 SP1 may cause the toggle to be reported as "broken" by the operator; the workaround and its limitations must be part of the operator training.

Compatibility Matrix: Solutions vs. Project Constraints