Problem Description
The Siemens WinCC Advanced TIA Portal V13 Alarm View control fails to render on a Basic Panel, Panel, Comfort Panel, or WinCC Runtime Advanced HMI screen even though the object is configured in the project tree and placed on the screen graphic. Operators do not see live, queued, or historical alarm lines, although the project's alarm configuration compiles without errors. This symptom is consistently observed when:
- The Alarm View object is present in the screen layout but does not appear in Runtime.
- The visibility of the control is animated through a tag or expression that evaluates to
0at startup. - Temporary cache files used by the TIA Portal compile pipeline contain stale references to the removed or renamed alarm tags.
- The HMI device firmware does not match the version of TIA Portal V13 SPx that produced the project binary.
- Historical alarm rows are requested but the corresponding alarm log or archive is not linked to the Alarm View's filter.
Affected Components and Versions
| Component | Version / Catalog | Notes |
|---|---|---|
| TIA Portal | V13, V13 SP1, V13 SP2 | Project compilation may leave stale .em-* temporary files after control replacement. |
| WinCC Advanced | V13 / V13 SPx | Hosts the Alarm View editor for Comfort Panels and PC Runtime. |
| WinCC Professional | V13 / V13 SPx | Same Alarm View control, same Visibility property model. |
| Basic Panels (KTP400, KTP700, KTP1000, KTP1200) | Firmware ≥ device-specific min. for V13 | Basic Panels use a reduced Alarm View subset (no historical list on entry-level devices). |
| Comfort Panels (TP700..TP2200, KP700..KP1500) | Firmware ≥ device-specific min. for V13 | Full Alarm View with single, summary, and historical lists. |
| PC Runtime (WinCC RT Advanced) | V13 / V13 SPx | Same control surface; recompile triggers a full restore of cached screens. |
The official V13 Alarm View entry point is documented at Alarm view (as of V13) - Siemens Industry Online Support.
Root Cause Analysis
The Alarm View is a managed WinCC screen object whose rendering is gated by three independent layers. A failure of any one layer can suppress the control without raising a compile or consistency-check error:
-
Animation layer — the Visibility animation on the Alarm View is evaluated first. If a tag-driven expression returns
0at Runtime startup, the entire control is hidden, and the alarm table does not occupy any screen real estate. - Compile / cache layer — TIA Portal V13 stores compiled screen fragments in a per-device temporary folder. If the Alarm View was deleted and reinserted, or if its referenced alarm tags were renamed, the cached *.hmi equivalents may still reference the old symbol set, causing the Runtime loader to silently drop the control.
- Alarm source layer — if the Alarm View is configured to display a specific alarm class, acknowledgment model, or historical log that contains no matching entries, the table renders empty rather than failing outright. Empty is easily confused with "not displayed".
Diagnostic Matrix
| Symptom | Likely Layer | First Verification |
|---|---|---|
| Alarm View rectangle visible in editor, blank in Runtime | Animation / Visibility | Properties → Animations → Visibility; confirm no tag or expression is bound, or that bound tag is 1. |
| Alarm View not even selectable in Runtime, no toolbar | Compile cache | Right-click HMI device → Compile → Software (Compile all); restart Runtime. |
| Alarm View present but no rows of historical alarms | Alarm source / log link | Properties → General → alarm categories & filter; verify log path on the HMI / Runtime is reachable. |
| Alarm View flashes for <1 s on screen change then disappears | Visibility animation with PLC tag | Inspect the PLC tag update cadence; non-zero default initial value keeps the control hidden. |
Solution 1 — Visibility Animation Reset
The most common cause in V13 projects is a leftover Visibility animation. Visibility animations are configured under Properties → Animations for any screen object, including the Alarm View. A bound tag or formula expression whose result is 0 hides the control.
- In the project tree, open the screen that contains the Alarm View.
- Select the Alarm View object.
- In the properties inspector, switch to the Animations tab.
- Expand Visibility. If an entry appears with a tag name, expression, or formula, delete the animation (right-click → Remove animation).
- If Visibility must remain dynamic, ensure the bound expression evaluates to
1at startup. For a Boolean tag, this means the initial value of the tag in the HMI tag table must be1, not0. - Recompile the HMI device (right-click the HMI in the project tree → Compile → Software (Compile all)) and start Runtime.
Solution 2 — Clean Recompile of HMI Software
Stale temporary files in the V13 build chain are a documented source of "ghost" screen objects. The clean-rebuild sequence below resolves the issue without re-creating the project:
- Select the HMI device node in the TIA Portal project tree.
- Right-click and choose Compile → Software (Compile all). Confirm the rebuild completes without warning or error.
- Close TIA Portal V13 completely to release all file handles on the project working directory.
- Navigate to the project folder and inspect
...\IM\HMI\<DeviceName>\<DeviceName>.hmi_temp\and...\IM\<DeviceName>\<DeviceName>.tmp\. If these folders exist and have not been deleted automatically, archive and remove them. - Restart TIA Portal, open the project, and recompile the HMI device.
- Transfer the rebuilt binary to the panel (or start WinCC Runtime Advanced).
This is the same procedure recommended by Siemens application engineers when "the Alarm control does not appear in the Runtime screen but you have configured it in your screen in the project".
Solution 3 — Replace the Alarm View Control
If the previous two steps do not surface the control, the Alarm View object instance on the screen has accumulated incompatible property edits. Replace it with a fresh instance:
- Open the screen, select the existing Alarm View, and delete it.
- From the Toolbox palette, drag a new Alarm View onto the screen. Do not modify any properties yet.
- Compile and run Runtime. The new control must appear with default styling and an empty alarm grid.
- After confirming visibility, re-apply the original column layout, sort order, and filter selections one property at a time, recompiling after each batch.
This is the procedure that resolved the reported incident: after inserting a brand-new Alarm View control without any custom properties, the alarm table rendered correctly in Runtime for the first time.
Solution 4 — Configuring Historical Alarm Display
A separate but commonly confused symptom is the Alarm View rendering but never showing rows of historical alarms. Historical alarm display requires both an alarm log on the HMI device and the Alarm View configured to reference that log.
| Property | Path in TIA Portal V13 | Required Value |
|---|---|---|
| Alarm log path | HMI device → Runtime settings → Alarms → Alarm log | Storage path on the panel or Runtime PC; \Storage Card SD\Logs\<logname> for Comfort Panels. |
| Alarm buffer mode | Alarm log → Properties | Volatile (RAM) for live-only, persistent (file) for historical. |
| Alarm View mode | Alarm View → Properties → General → Mode | Alarm line, Single alarm, Summary, or Historical list depending on the operator requirement. |
| Filter categories | Alarm View → Properties → Filter | At least one alarm class ticked (e.g., Errors, Warnings). |
| Time range | Alarm View → Properties → Filter → Time interval | For historical: relative (last N hours) or absolute (date / time). On Basic Panels, historical is restricted to entry-level models. |
- Verify the panel has an active alarm log. On a Comfort Panel, configure Runtime settings → Logs with a path on the SD card.
- On the Alarm View, switch Mode to Historical list. Confirm the filter's time interval covers the range of stored alarms.
- Generate a test alarm from the PLC (e.g., set an analog limit) to confirm the alarm is logged and then retrieved.
Verification Procedure
- Visual check: In Runtime, navigate to the screen that hosts the Alarm View. The control frame and toolbar must be visible.
- Row check: Force a controlled alarm from the PLC (e.g., set a configured tag above its high limit). The Alarm View must show a new row within one polling cycle (typically 250 ms).
- Acknowledge check: If acknowledgment is enabled in the alarm class, the Acknowledge button on the Alarm View must accept a single operator action and clear the unacknowledged flag.
- Historical check: Switch the Alarm View to Historical list with the configured time filter. Previously raised alarms must appear.
- Compile integrity: On the HMI device, right-click → Compile → Software (Consistency check only). The result must be "Consistent".
Extended Diagnostics
A. Difference Between Alarm View and Alarm Control (Unified)
The WinCC Unified Alarm control supersedes the V13 Alarm View beginning with V16. The V13 Alarm View uses a HMIRuntime-based alarm subscriber; the Unified alarm control uses the new IMUIS.Alarm API. Symptoms that look identical in Runtime — empty grid, hidden control — have different root causes across the two families. Confirm the project is targeting WinCC Advanced V13 SPx before applying the procedures above; if the project has been migrated to V17+, consult the WinCC Unified documentation at Alarm control (RT Unified) - WinCC Unified.
B. Tag Filtering of Alarm Classes
If the Alarm View shows some alarms but not others, verify the class filter on the Alarm View. By default a new Alarm View in V13 is configured to show only the Errors class. Operator information, system, and custom classes are hidden unless explicitly enabled.
C. Display Class and Acknowledgment Model
On Comfort Panels the alarm class has both an acknowledgment model and a display class. Alarms whose display class is not selected on the Alarm View will not render even if their bit status is set. Open the Alarm View's filter and confirm the relevant display class is enabled.
D. Runtime-to-Panel Version Mismatch
If the HMI binary was compiled in TIA Portal V13 but the panel runs a firmware image older than the matching Service Pack, Alarm View rendering can fail silently. Cross-check the ES and OS versions on the Comfort Panel in the Panel Information menu under System → Versions and confirm the panel firmware is at or above the version referenced in the TIA Portal V13 SP readme.
Field-Proven Checklist
| # | Check | Acceptance Criterion |
|---|---|---|
| 1 | Alarm View present on screen | Visible in editor, no Visibility animation bound |
| 2 | Visibility animation | No bound tag, or bound tag evaluates to 1 at startup |
| 3 | Compile integrity | Compile → Software (Compile all) reports no warnings or errors |
| 4 | Alarm log path | Configured and reachable on panel SD / Runtime disk |
| 5 | Mode | Single, Summary, or Historical list selected per operator requirement |
| 6 | Filter categories | Required alarm class(es) ticked |
| 7 | Display class | Active display classes match the alarm view filter |
| 8 | Firmware compatibility | Panel FW ≥ TIA Portal V13 SPx minimum |
| 9 | Test alarm | Forced PLC alarm visible in Alarm View within 1 s |
| 10 | Historical alarm | Historical list shows alarms from log within configured time interval |
Preventive Measures
- Avoid binding Visibility animations on Alarm Views unless the underlying Boolean tag has a documented startup value of
1. - When replacing Alarm Views, perform a full panel recompile and a project close / reopen cycle to clear stale temporary files.
- Document the alarm log path and time-filter convention in the project engineering specification so that operators and maintainers do not mistake "no rows" for "not displayed".
- Lock the TIA Portal project to a single Service Pack (V13 SP1, V13 SP2, or V13 SP3) and avoid multi-engineer branches that mix SP levels; mismatched SP levels can introduce Alarm View rendering anomalies.
Frequently Asked Questions
Why does my Alarm View not appear in WinCC Advanced V13 Runtime even though it is on the screen?
The most common cause is a Visibility animation bound to a tag that evaluates to 0 at startup. Open the Alarm View's properties, switch to the Animations tab, expand Visibility, and delete any bound tag or formula. Recompile the HMI device with right-click → Compile → Software (Compile all) and restart Runtime.
How do I clear the TIA Portal V13 temporary files that cause Alarm View rendering issues?
Close TIA Portal V13, navigate to the project's IM\HMI folder, and delete any *.hmi_temp and *.tmp directories associated with the affected HMI device. Reopen the project, recompile the HMI device with Compile → Software (Compile all), and transfer the rebuilt binary to the panel or Runtime.
How do I configure historical alarm display in a V13 Alarm View?
Confirm an alarm log is configured on the HMI device (Runtime settings → Logs), then set the Alarm View's Mode to Historical list and configure a relative or absolute time interval filter. On Basic Panels with reduced feature sets, the historical list may not be available; switch to a Comfort Panel or WinCC Runtime Advanced for full historical support.
What is the difference between the V13 Alarm View and the WinCC Unified Alarm control?
The V13 Alarm View uses the legacy HMIRuntime alarm subscriber and is documented under WinCC Advanced / Professional V13. The WinCC Unified Alarm control uses the IMUIS.Alarm API and applies to TIA Portal V16 onward. Symptom isolation procedures differ between the two; verify the project targets V13 SPx before applying the procedures in this article, otherwise consult the WinCC Unified documentation.
My Alarm View shows some alarm classes but not others — what should I check?
Open the Alarm View's filter properties and confirm that the missing alarm class is ticked under both the alarm category filter and the display class filter. By default a new V13 Alarm View shows only the Errors class; warnings, operator information, and custom classes are hidden until explicitly enabled in the filter.