Resolving S7-400H ALARM_8P Alarms Not Appearing in WinCC PCS 7

When block-related alarms generated by the SIMATIC ALARM_8P function block on a S7-400H or S7-400FH Automation System (AS) stop reaching the WinCC Alarm Logging on a PCS 7 OS station after an unpredictable runtime, the root cause almost always lies in message configuration, OB start-event assignment, or AS-OS link health. A blanket Entire Program Download temporarily restores the alarms, which is a strong indicator that the message references or instance-DB consistency have drifted out of sync with the runtime database. This reference walks through field-proven diagnostics and corrective procedures that avoid the "download the world" recovery cycle.

1. System Architecture and Alarm Path

Before changing any configuration, confirm the actual alarm path on the segment. A redundant S7-400H AS sends message events to the WinCC OS through a chain of system blocks:

1. ALARM_8P (FB 35) inside the CFC chart collects the eight signal inputs and message text references.
2. FB 35 internally calls SFC 51 (RDSYSST) to retrieve system state, and SFC 17 (ALARM_SQ) or — on H systems — SFC 107 (ALARM_DQ) to dispatch the message to the operator station.
3. The message is queued in the AS connection's alarm buffer and shipped over the configured S7 connection to the OS.
4. The OS receives the message via the S7 Protocol Suite channel and writes it to WinCC Alarm Logging.
5. The WinCC Alarm Control (graphics runtime) reads from Alarm Logging and renders the entry.

Any break in this chain — even transient — will manifest as "alarms stop appearing." Note that an Entire Program Download regenerates every instance DB, re-creates the S7 connection, and forces the message text to be re-catalogued on the OS, which is why it acts as a hammer-grade reset.

2. Symptom Matrix

3. Root-Cause Analysis

3.1 Instance DB and Message Reference Drift

The dominant cause when Entire Program Download is the only known recovery is instance-DB drift. PCS 7 stores message texts in the WinCC Text Library and references them in the instance DB of every ALARM_8P call. When the CFC is recompiled with new signal connections but the OS has not been recompiled, the message number-to-text mapping on the OS side becomes stale. The CPU continues to send messages correctly; the OS simply cannot find the matching text and either drops them or hides them.

Verify: In the WinCC Explorer open Text Library > Alarm Logging > Messages and locate the message numbers generated by the affected chart. If Status: Modified or Not found in AS appears, the OS side is out of sync.

Fix:

1. In PCS 7, select the OS project and run Compile OS > All (with Memory Reset). This re-builds the message tables on the OS side without disturbing the running AS.
2. Download only the OS runtime; do not perform an Entire Program Download on the AS — the goal is to avoid touching healthy instance DBs.

3.2 OB Start-Event Assignment

ALARM_8P must run inside a valid OB. The block's task is to evaluate its inputs and decide whether a new message must be queued. If the CFC chart is compiled with an OB that is not started on the CPU (for example, an OB 35 cycle OB that has been disabled in HW Config), the message logic will not execute and no events will be produced.

Verify:

• Open the CFC chart, right-click the chart footer > Block Properties > Run Time Properties and note the OB1/OB35/OB40 etc. assignment.
• In STEP 7 HW Config > CPU Properties > Cyclic Interrupts, confirm that OB35 (or whichever OB is targeted) is enabled with a non-zero period.
• In the online diagnostic buffer, look for OB 35: time error or OB 80: time fault events. These events silently suppress ALARM_8P execution when an OB priority inversion occurs.

Fix: Re-enable the OB in HW Config, or move the ALARM_8P to a healthy OB (commonly OB 35 at 1000 ms for S7-400H, since the 1 s beat matches WinCC's default update cycle).

3.3 OS Alarm Buffer Overflow and Lock

WinCC Alarm Logging maintains a ring buffer on the OS station. If the buffer is full and the archive action is not configured, new messages are dropped. On S7-400H, the redundant pair can each send the same event during a failover transition, which can rapidly fill a small buffer.

Verify:

• In WinCC Explorer > Computer Properties > Startup > Alarm Logging Runtime, check the configured Maximum number of messages and Maximum number of archive entries. The default is 1000 / 1000. For a plant that generates high-frequency alarms, raise to 5000 / 5000 minimum.
• Open the Alarm Control in graphics runtime and check whether the Status Bar shows Buffer full.

Fix: Configure a long-term archive segment (e.g. circular database, 30-day retention) and increase the in-memory buffer to 5000 messages. Re-test after 24 hours of operation.

3.4 Asymmetric Execution on H Standby

On S7-400H, ALARM_8P is intended to run on the active CPU. If a CFC chart is mistakenly compiled with a runtime that only executes on the standby CPU (for example, a task inserted into a chart that is owned by the backup), the message will be generated, sent to the OS, then dropped during the next master/standby switchover because the new active CPU has never seen the message condition.

Verify:

• In the S7-400H diagnostic view (STEP 7 > PLC > Operating Mode), confirm the current master CPU and the time of the last master/standby switchover.
• Cross-reference the timestamp of the last missed alarm with the switchover log. If they correlate, the chart's run-time assignment is asymmetric.

Fix: Open the chart in CFC and force the run-time group to Run on both CPUs in the S7-400H section of HW Config > H Parameters > Redundant. This is the default for PCS 7 charts but can be lost after manual edits.

3.5 Fail-Safe Messaging on S7-400FH

An S7-400FH requires the fail-safe message block SFC 108 (ALARM_F) for safety-related notifications, not the standard ALARM_8P path. If safety messages are configured through ALARM_8P, the F-runtime will not dispatch them and the OS will see no event.

Verify: In the safety program editor (CFC / SCL safety view), search for ALARM_8P calls inside F-blocks. These should be moved to SFC 108 with the corresponding F-message number range.

Fix: Replace ALARM_8P in the F-block area with the F-specific message block documented in the PCS 7 Driver Blocks reference PDF (entry ID 8787681).

3.6 Automatic Alarm Hiding in the Alarm Control

WinCC Alarm Control can be configured to hide acknowledged messages or messages older than a threshold. If the user cannot see alarms in runtime, but the diagnostic buffer of the AS confirms the messages have been sent, the Alarm Control is hiding them.

Verify: Open the Alarm Control configuration > Selection tab. Inspect the Selection by status checkboxes. A common cause is "Hide acknowledged messages" being enabled in combination with an "Auto-acknowledge after" timeout set below the operator response time.

Fix: Clear the auto-hide filter in graphics designer, redeploy the picture, and re-test. The Siemens support entry referenced in the original investigation (entry ID 55699984) documents this exact pattern in greater detail.

4. Configuration Review Checklist

Run the following checks against the live project before scheduling a download. The aim is to identify the failing link in section 3 with no AS-side disruption.

5. Step-by-Step Recovery Procedure

When the live diagnostics above identify a single root cause, the corrective procedure is the minimal action set:

5.1 OS-Side Drift (most common)

1. In SIMATIC Manager / PCS 7, expand the OS project node.
2. Right-click the OS > Compile OS.
3. Select All (with Memory Reset) and tick Scope: Entire OS.
4. Click Compile. Compilation should report 0 errors, 0 warnings.
5. Download the OS via OS > Download > Master-Server / Standby-Server. Do NOT touch the AS at this point.
6. Activate runtime and verify that the previously-missing alarm appears in WinCC Alarm Control within one OB cycle (≤ 1 s).

5.2 OB Mis-Assignment

1. Open the CFC chart with the suspect ALARM_8P.
2. Chart menu > Block Properties > Run Time Properties.
3. Change the OB assignment to OB 35 (Cyclic Interrupt, 1000 ms) if it currently shows an unassigned or disabled OB.
4. Compile and download the chart only.
5. Watch the diagnostic buffer for OB 80/85 errors. If they return, an OB overload exists — investigate priority inversions before proceeding.

5.3 OS Buffer Overflow

1. Stop WinCC runtime on the OS station.
2. Open WinCC Explorer > Computer Properties > Startup.
3. Raise the alarm buffer from 1000 to 5000 messages.
4. Configure an archive segment (minimum 30-day circular) under Tag Logging / Alarm Logging > Archives.
5. Restart WinCC runtime and monitor for buffer-full events over 24 hours.

5.4 H Asymmetry

1. In HW Config > H CPU Properties > Redundancy, verify the run-time group is set to Run on both CPUs.
2. Recompile and download the affected S7 program to both H CPUs.
3. Force a master/standby switchover via PLC > H Functions > Switchover and verify alarm continuity.

6. Verification Procedure

After any of the corrective steps above, validate the fix with the following acceptance test before returning the system to production:

1. From the engineering station, force a known signal on one of the ALARM_8P inputs (e.g. set SIG_1 = 1 in Monitor/Modify).
2. Confirm the message appears in WinCC Alarm Logging within 2 seconds.
3. Acknowledge the alarm from the OS and confirm ACK_STATE toggles back to TRUE on the AS side within one OB cycle.
4. Force a master/standby switchover on the S7-400H and confirm the same alarm is re-reported on the new master CPU.
5. Run the plant at full load for 24 hours and confirm zero "alarms lost" entries in the WinCC diagnostic log.

7. Related Siemens Documentation

• PCS 7 Driver Blocks — Function Manual (Entry ID 8787681)
• SIMATIC S7-400H — Fault-tolerant Systems, Operating Instructions
• PCS 7 Operator Station — Configuration Manual (WinCC Alarm Logging chapter)
• S7-400F and S7-400FH — Programming and Operating Manual (SFC 108 ALARM_F)

8. FAQ