Siemens OP177B Alarm Buffer Loss on WinCC Flexible 2008 SP1: Field Troubleshooting Guide

The SIMATIC OP 177B is a 5.7-inch operator panel widely deployed in machine-level HMI applications. When eight OP 177B panels are networked under a single WinCC Flexible 2008 SP1 project and three units spontaneously clear their alarm buffer (containing only a single message instead of the documented 256-message ring capacity), the root cause is typically one of three conditions: a firmware revision mismatch, a defective alarm persistency setting within the WinCC Flexible project, or project-side parameters that trigger an unintended buffer reset. This guide walks through the diagnostic tree, the OS update path, the Hotfix 2 patch, and the project-audit procedure required to restore the documented 256-message alarm buffer behavior.

1. Problem Definition and Observable Symptoms

Normal OP 177B alarm buffer behavior is defined as a circular buffer of 256 messages. Once the buffer is full, the oldest entry is overwritten (FIFO). The reported failure mode deviates from this contract in the following way:

• The alarm buffer holds one (or very few) messages and is then emptied.
• Older alarm entries vanish after only a few operating hours instead of accumulating to the 256-message limit.
• The behavior is reproducible on three out of eight panels but never on the remaining five.
• No power cycle, no logged operator action, and no PLC-side trigger correlates with the buffer reset.

The fact that the symptom is localized to specific physical panels (and not the entire fleet) points to either a per-panel firmware revision difference or a project-side condition that interacts with the panel runtime to produce the early flush.

2. OP 177B Hardware and Runtime Specifications

Before applying any fix, capture the panel-side data so each of the eight units can be compared. The OP 177B family is documented in the SIMATIC HMI device manual and the relevant parameters are summarized below.

The alarm buffer is stored in flash memory with optional retentivity. If the internal lithium buffer battery is depleted (typical service life of approximately 5-7 years at 25 °C), retentive data including the alarm buffer can be lost on power down. Always verify battery voltage before chasing firmware or project issues.

3. Root Cause Analysis

Three documented failure paths explain the behavior observed in the field.

3.1 Firmware Revision Mismatch

WinCC Flexible 2008 SP1 generates runtime image files that target a specific panel firmware revision. When two OP 177B units in the same fleet ship with different factory firmware revisions (for example V06.04.03 vs V06.04.04), the panel with the older revision may exhibit runtime anomalies that are silently fixed in newer revision images. The Siemens support entry for OP 177B firmware documents multiple revisions that include corrections for alarm handling and persistence logic. Eight identical-looking MLFB units can leave the factory with different firmware loads depending on manufacturing date.

3.2 Alarm Persistency Setting in the WinCC Flexible Project

The alarm buffer can be configured as retentive or non-retentive. The default for OP 177B panels in WinCC Flexible 2008 SP1 is "deactivated" (non-retentive). When persistency is deactivated and the runtime experiences certain conditions, the alarm buffer can be cleared. The runtime properties dialog exposes this setting under alarm persistency. On panels that exhibit the symptom, the runtime setting must be inspected.

Reference: Siemens documentation on alarm persistency (Unified Basic Panels runtime properties). The principle applies across the HMI panel portfolio including the OP 177B; the default state is deactivated unless explicitly enabled in the engineering tool.

3.3 Project-Side Configuration That Triggers Buffer Reset

Several project-side conditions can clear the alarm buffer prematurely:

• Alarm classes configured with the "Acknowledge" or "Display" settings that call a buffer-clear function.
• Scheduled scripts (VB script on the OP 177B is supported in WinCC Flexible 2008 SP1) that call alarm buffer manipulation functions.
• An HMI tag or PLC variable that is mapped to alarm-archive flush.
• A recipe or data record action that inadvertently triggers the alarm buffer reset.

Because the symptom appears on three of eight panels running the same compiled runtime image, this points to a project-side condition that interacts with panel-specific state. The WinCC Flexible 2008 SP1 Hotfix 2 patch is the documented remediation for known runtime anomalies.

4. Step-by-Step Resolution Procedure

Execute the following steps in order. Do not skip a step: each step rules out one of the three documented failure paths.

Step 1 - Capture the Panel-Side Identification

1. On each OP 177B, press the Control Panel button (or navigate via the Start menu on Windows CE 5.0).
2. Open OP Properties or System > Device.
3. Record the device name, MLFB, firmware revision, and build date.
4. Record the version of the WinCC Flexible runtime image currently loaded.
5. Compare the eight units side by side. Flag any unit whose firmware revision differs.

Step 2 - Apply WinCC Flexible 2008 SP1 Hotfix 2

Siemens released Hotfix 2 for WinCC Flexible 2008 + Service Pack 1 to address multiple runtime anomalies including alarm-handling edge cases. Apply Hotfix 2 to the engineering station before recompiling the project.

1. Download Hotfix 2 from the Siemens Industry Online Support portal (entry ID 37355823, "Hotfix 2 for WinCC flexible 2008 SP1").
2. Close all instances of WinCC Flexible 2008 SP1 and any TIA Portal-side tools.
3. Run the hotfix installer with administrative privileges.
4. Restart the engineering station.
5. Verify the hotfix via Help > About in WinCC Flexible 2008 SP1; the installed build number must reflect Hotfix 2.

Step 3 - Verify the Alarm Persistency Setting

1. In WinCC Flexible 2008 SP1, open the affected project.
2. Navigate to the OP 177B device in the project tree.
3. Open Properties > Alarm Settings (or the equivalent runtime properties dialog).
4. Locate the Alarm Persistency checkbox or radio control.
5. If the property is set to "deactivated", set it to "activated" and recompile the project.
6. Document the original value before changing it for rollback purposes.

Step 4 - Execute an OS Update With Reset to Factory Settings

If Hotfix 2 and persistency settings do not resolve the issue, perform an OS update with the "Reset to factory settings" option. This re-flashes the Windows CE 5.0 image and clears any internal state corruption that may be triggering the early flush.

1. Back up the current project from the OP 177B using ProSave, WinCC Flexible transfer, or the HMI device's CF/USB storage.
2. Connect the engineering station to the OP 177B via MPI/PROFIBUS or Ethernet (depending on the variant) using a PC adapter cable (for example 6ES7 972-0CB20-0XA0 USB-MPI or 6GK1 571-1AA00 Ethernet).
3. Open ProSave or WinCC Flexible Transfer.
4. Select the OP 177B target.
5. Select OS Update and enable the Reset to Factory Settings option.
6. Select the OS image file matching the panel's MLFB and firmware revision.
7. Start the update. The process takes approximately 5-10 minutes; do not interrupt power.
8. After completion, perform a fresh project transfer (do not restore the backup; transfer the recompiled image from step 3).

Step 5 - Project Audit: Identify Buffer-Reset Triggers

With Hotfix 2 applied and persistency enabled, the symptom should be eliminated. If it persists, audit the project for the conditions listed in section 3.3.

1. Search the project for any script that calls the alarm buffer functions. In WinCC Flexible 2008 SP1 VB scripting, search for keywords such as ClearAlarmBuffer, ResetAlarmBuffer, or any function that maps to the alarm buffer manipulation API.
2. Inspect every alarm class for "Display" or "Acknowledge" events that might trigger buffer reset.
3. Check scheduled functions for any call to alarm archive or buffer manipulation.
4. Verify that no PLC-side tag is mapped to a function that affects the buffer.

Step 6 - Minimal Project Test

If the symptom still persists after the steps above, deploy a minimal test project to one of the affected panels to isolate whether the original project is the cause.

1. In WinCC Flexible 2008 SP1, create a new project targeting the OP 177B.
2. Add a single screen with two or three discrete alarms configured.
3. Set Alarm Persistency to "activated".
4. Compile and transfer to the affected panel.
5. Operate for 24 hours and verify the buffer retains 256 messages or behaves according to the ring-buffer overwrite contract.
6. If the minimal project runs without anomaly, the original project contains the buffer-reset trigger; revert to step 5 to isolate it.

5. Alarm Persistency Reference

Alarm persistency controls whether the alarm buffer survives a power cycle and protects against runtime anomalies that clear the buffer. The relevant configuration surface is summarized below.

Reference: Siemens documentation on alarm persistency.

6. Firmware Revision Compatibility Matrix

The OP 177B ships with firmware revisions that contain cumulative bug fixes. Compile and runtime behavior can shift between revisions, especially for alarm handling. Capture the firmware version on every panel before any update.

7. Verification Procedure

After completing the resolution steps, execute the following verification sequence on each panel.

1. Confirm WinCC Flexible 2008 SP1 Hotfix 2 is installed on the engineering station (Help > About shows Hotfix 2).
2. Confirm Alarm Persistency is set to "activated" in the project before transfer.
3. Confirm firmware revisions on all eight panels match (or have been updated to a known-good revision).
4. Transfer the recompiled project to all eight panels.
5. Generate a continuous stream of test alarms on each panel (e.g., toggle a discrete tag in a PLC or via simulation).
6. Operate each panel for at least 24 hours.
7. Verify each panel's alarm buffer contains more than one message after 24 hours, and that the buffer accumulates up to 256 messages as documented.
8. Power-cycle one panel and verify the buffer is retained.

8. Troubleshooting Matrix

9. Preventive Measures and Best Practices

• Always enable Alarm Persistency for production OP 177B panels. The default "deactivated" state is rarely what an operator actually wants in a 24/7 process.
• Maintain a single firmware revision across the entire fleet of OP 177B panels. Document the revision in the project's change log.
• Apply WinCC Flexible hotfixes on a controlled schedule and revalidate alarm behavior after each update.
• Replace the internal lithium buffer battery on a 5-year cycle; a depleted battery can cause retentive data loss including the alarm buffer.
• Avoid VB scripts that directly manipulate the alarm buffer. Use the documented alarm acknowledgement and display flow instead.
• Back up each panel's project and runtime image before any firmware or hotfix operation. Store backups with timestamped filenames.
• Document panel-level firmware revisions and runtime image versions in the asset management system.

10. Field Commissioning Notes

When commissioning a new OP 177B fleet, perform the following checks before sign-off:

1. Verify the firmware revision on every panel and confirm uniformity.
2. Confirm Alarm Persistency is "activated" in the deployed project.
3. Run a 48-hour soak test with continuous alarm generation; confirm the buffer accumulates to the documented limit without early flush.
4. Power-cycle each panel and confirm alarm buffer retention.
5. Document the runtime image version and firmware revision for each panel in the commissioning record.

11. FAQ