Comfort Panel Alarm Buffer Empty: Root Cause and USB Log Fix

Problem Description

On a SIMATIC HMI Comfort Panel (TP700, TP900, TP1200, TP1500, TP1900, TP2200), the alarm window object displays an empty alarm buffer after a power cycle of the panel, even though identical HMI stations in the same plant show the historical alarm entries correctly. Operators open the alarm view, the list is empty, and the only historical record available is what was acknowledged before the last reboot. This is a known runtime behavior on Comfort Panels when the alarm log storage location is set to the default internal flash path and the panel reboots unexpectedly or is power-cycled. The alarm buffer is a volatile copy of the active (unacknowledged) alarms, while the alarm log is the persistent record. When the log path is misconfigured, deleted, or unwritable, the buffer appears empty on startup even when configuration is correct.

The symptom presents in two distinct ways:

• Empty after power cycle — Alarms are visible during operation, but on the next boot the alarm view shows zero entries. This indicates the alarm log location was not persistent across the reboot.
• Empty on a single HMI only — A specific panel in a fleet of identically-configured units does not show alarms while its peers do. This typically points to a per-device project configuration drift, a corrupted runtime file system, or a hardware issue with the storage medium.

The error is most commonly reported on projects originally created in TIA Portal V13 SP1 and later updated in V15, V15.1, V16, V17, V18, V19, or V20. It affects WinCC Comfort, WinCC Advanced, and WinCC Professional runtime environments where Comfort Panel targets are configured.

Affected Products and Versions

Alarm Architecture on Comfort Panels

Comfort Panels maintain three separate alarm data structures. Understanding the distinction is the prerequisite to resolving the empty-buffer symptom.

Alarm Buffer (Active Alarms)

The alarm buffer is a volatile, in-memory list of currently active or unacknowledged alarms. It exists in RAM only and is reconstructed on each boot from the alarm log plus the live tag conditions. If the alarm log is not persistent across the boot, the buffer reconstructs empty even when alarms had been active prior to the reboot.

Alarm Log (Persistent Alarms)

The alarm log is a circular file stored on the configured storage medium. Default storage is the internal flash file system at /home/cf-card/Logs or, when no CF card is present, on the internal NAND at /home/Logs. The log survives reboot only if the storage medium is persistent and the file is intact.

Alarm Archive (Long-Term)

The alarm archive is a separate configurable file used for long-term export, often to a network share or USB stick. Archives are not used to populate the alarm view on startup; only the log is.

The alarm window object on the screen reads from the buffer and the log simultaneously. If the log cannot be read, the window falls back to showing only the currently active (unacknowledged) alarms, which may be zero after a clean boot.

Root Cause Analysis

Five root causes account for nearly all field reports of an empty Comfort Panel alarm buffer.

Cause 1: Internal Flash Wear or Corruption

Comfort Panels use internal NAND flash for the alarm log when no external storage is configured. After tens of thousands of write cycles, particularly on panels with high alarm traffic, the file system can develop bad blocks. The alarm log file may exist but be unreadable, and the runtime silently fails to populate the buffer. The SystemLog.txt on the panel contains entries such as "Alarm logging: file system error" when this occurs.

Cause 2: Missing or Unmounted Storage Medium

If the alarm log is configured to point to an SD card or USB stick path and that medium is not present at boot, the runtime cannot reconstruct the buffer. The error is silent: the alarm view simply shows zero entries.

Cause 3: Power Loss During Log Write

An uncontrolled shutdown (24 V DC supply removed under load) while the log file is open can truncate the file. The next boot detects an invalid log header and discards the contents, leaving the buffer empty.

Cause 4: Project Drift Between Identical HMI Stations

When a fleet of panels is configured from the same master project but only some show the symptom, the project loaded on the affected panel is not identical to its peers. The drift is typically a difference in:

• Alarm log storage path (one panel set to internal, another to USB or SD)
• Alarm log segmentation (size, time-based rollover)
• Alarm classes registered (missing user-defined class)
• Project version (one panel not updated during a recent TIA Portal upgrade)

Cause 5: xlsx Alarm Import Issue

When alarms are imported into the project from an xlsx file, empty list entries for existing alarms are ignored. The entries of the existing alarms remain. This is documented behavior in the TIA Portal help and means a partial or malformed import will leave the project with stale alarm definitions, which can produce an empty buffer if the runtime cannot resolve the alarm classes. Review the official Siemens documentation on importing alarms in TIA Portal V20 to confirm import semantics before assuming a project drift cause.

Solution 1: Route the Alarm Log to a USB Stick (Field-Proven Workaround)

Siemens support recommends configuring the alarm log storage location to a USB stick on the front USB port of the Comfort Panel. The USB stick is mounted as /media/usb0 at runtime and the log persists across power cycles independently of the internal file system.

Prerequisites

• USB 2.0 stick formatted with FAT32 file system (one partition, 32 KB cluster size recommended)
• USB stick capacity 1 GB to 32 GB (larger sticks are not always recognized by the panel image)
• Industrial-grade stick recommended (MLC or SLC NAND) for environments with high write cycles
• Project source in TIA Portal V13 SP1 or later
• Active project download capability (ProSave, Ethernet, or USB)

Step-by-Step Configuration

1. Open the TIA Portal project containing the affected Comfort Panel.
2. In the project tree, select the HMI device and open Runtime Settings > Alarm Logging (or Alarms > Settings > Alarm Logging in older TIA versions).
3. Locate the Storage location property for the alarm log. By default this is Storage Card or Internal Flash.
4. Change the storage location to USB (path /media/usb0/Logs) or define a custom path under the USB mount point.
5. Confirm the Log size and Segmentation parameters: a 2 MB to 8 MB circular log with time-based segmentation of 24 hours is typical for alarm-only retention.
6. Enable Activate alarm log.
7. Compile the HMI project (full rebuild, not incremental).
8. Download the compiled runtime to the Comfort Panel.
9. Insert the prepared USB stick into the front USB port (X1) of the panel before the panel boots, or insert it and reboot the panel via the Control Panel > Reboot menu.
10. Trigger a known alarm and acknowledge it. Power-cycle the panel. Verify the alarm is still visible in the alarm view.

Verification

1. Trigger an alarm (e.g., a level switch overrange).
2. Acknowledge the alarm from the alarm window.
3. Open the Control Panel on the HMI and select Reboot.
4. Wait for the panel to restart and load the project.
5. Open the alarm view. The previously triggered alarm must still be present in the log.
6. If the alarm is missing, check the USB stick for the file AlarmLog_ALG_0.csv (or similar). The file should be present and contain the historical entries.

Solution 2: Realign the Project on the Affected HMI

When a single HMI in a fleet shows the empty buffer and others do not, the project on the affected unit is not byte-identical. Restore parity.

1. Identify the project source archive used for the working peers (TIA Portal .ap13, .ap15_1, .ap16, etc.).
2. Connect the engineering station to the affected HMI via Ethernet or Profinet.
3. In TIA Portal, select the HMI device and choose Download to device > Software (full download).
4. Confirm the dialog indicates a full project transfer, not a delta update.
5. After download completes, the panel reboots automatically. Verify the alarm buffer reconstructs from the log.

Solution 3: Clear and Re-create the Alarm Log

If the internal flash log is corrupted, clear and re-create it.

1. Open the Control Panel on the HMI (the small panel behind the Start Center).
2. Navigate to File System > Logs.
3. Delete the alarm log file (typically AlarmLog_ALG_0.csv or *.dat depending on version).
4. Reboot the panel.
5. The runtime will create a new log file on the next alarm event.

Solution 4: Reflash the Panel Image

For panels that have been in service for multiple years with high alarm traffic, the internal NAND may be worn. Reflash the image with ProSave.

1. Launch ProSave on the engineering station.
2. Connect to the panel via Ethernet (set the panel IP temporarily via the Control Panel if unknown).
3. Select OS Update and load the matching TIA Portal image (for example, the V16 image for a V16 project).
4. Reset the panel to factory defaults after the image update.
5. Re-download the project.
6. Verify the alarm buffer behavior.

Diagnostic Steps for Field Engineers

Use this sequence when arriving on site to isolate the cause quickly.

1. Read SystemLog.txt. Use ProSave or an FTP client to retrieve /home/SystemLog.txt from the panel. Search for entries containing "Alarm", "log", "file system", or "CSV". Errors here pinpoint storage issues.
2. Verify storage medium. Check that the configured storage path exists and is writable. Trigger a test alarm and confirm a new entry appears in the log file via FTP.
3. Compare project versions. On the engineering station, right-click the HMI device and select Device Information > Compile Information. Repeat for a working peer. The compile timestamps and project hashes must match.
4. Check alarm class registration. Open the alarm window in the TIA Portal simulation. If the simulation shows alarms but the runtime does not, the project compiled correctly but the runtime cannot resolve the alarm class definitions.
5. Inspect the alarm log file size. A zero-byte or suspiciously small log file indicates the file system refused to write. A truncated file indicates a power loss during write.

Alarm Log Configuration Reference

Troubleshooting Matrix

Preventive Measures

• Always deploy projects with the alarm log routed to an external medium (USB or SD card) to avoid dependency on internal flash longevity.
• Maintain a baseline project archive and verify the compile hash of every deployed HMI quarterly. Drift is the most common cause of unexplained single-unit faults.
• For plants with 24 V DC supply that is not backed by a UPS, add a small UPS or use a buffered DC supply to prevent uncontrolled power loss on the panel.
• Use industrial-grade USB sticks (e.g., Swissbit, ATP, or Siemens SIMATIC HMI USB sticks rated for industrial temperature and write cycles).
• Schedule a periodic export of alarm logs to a network share using the panel's archive function. This decouples retention from a single storage medium.
• Document the TIA Portal version and panel image version per HMI in the plant asset register.

Cross-Reference: Importing Alarms into the Project

When bulk-loading alarms from a spreadsheet, the TIA Portal import treats empty list entries for existing alarms as no-ops: the existing alarm definitions remain in the project. This means a malformed import will not delete alarms but may leave the project in a state where classes, groups, or trigger tags referenced by some alarm rows are not present. The runtime will fail to register those alarms and the buffer appears empty for the affected class. To avoid this, validate the xlsx before import and ensure every row has a complete alarm class, trigger tag, and message text. Refer to the official TIA Portal help for importing alarms in TIA Portal V20 for the complete import procedure and field constraints.

FAQ