S7-400H Redundant Mode Error: CPU 412-5H Diagnostic Buffer Guide

Overview: Interpreting 'System (1 out of 2) Has Gone Into Redundant Mode' on S7-400H

The diagnostic buffer entry System (1 out of 2) has gone into redundant mode on a SIMATIC S7-400H CPU 412-5H (and on the related CPU 410-5H and CPU 414-5H / 416-5H / 417-5H variants) is an event-class informational message produced by the H system firmware. The wording is, at first reading, ambiguous to many field engineers: a single CPU has just entered redundant operation relative to its partner. The message is not by itself a fault — it is a state-transition record. It can, however, be the surface symptom of a fault in the synchronization link, in the standby CPU, or in the redundancy control layer of the H runtime.

This reference walks through the operating-mode model, the candidate root causes, the diagnostic buffer analysis procedure in STEP 7 V5.x (and STEP 7 Professional / TIA Portal where supported), and the field-proven verification steps for an S7-400H installation. Where a same-class failure pattern is documented for the newer S7-1500H, the cross-reference is included so engineers migrating or maintaining mixed fleets can compare symptoms directly.

S7-400H Redundancy Architecture Recap

An S7-400H system is built around two identical H-CPUs that exchange data in real time over a dedicated synchronization link. The relevant building blocks are:

• H-CPU pair: e.g. 6ES7412-5HK06-0AB0 (CPU 412-5H). Both CPUs run identical user programs in lock-step.
• Sync modules plugged into the subrack backplane of each H-CPU, typically 6ES7960-1AA04-0XA0 / 6ES7960-1AA06-0XA0 (last valid order numbers in the S7-400H catalog). The modules convert the internal parallel sync bus to a serial fiber-optic link.
• Fiber-optic sync cables: duplex plastic optical fiber (POF) up to 10 m, or polymer-clad fiber (PCF) up to 100 m, terminated in Sub-D / SMI connectors on the sync module side.
• Redundancy control firmware implemented in the H runtime (CFBs / H-CiR objects in the user program; OB 70, OB 72, OB 80, OB 82, OB 83, OB 85, OB 86, OB 87, OB 88, OB 121, OB 122 are the I/O / fault-tolerance OBs most relevant to H system reactions).
• Ethernet CP 443-1 / CP 443-1 Advanced for HMI, programming, and optionally PROFINET ring redundancy, plus optional PROFIBUS CPs in redundant pair configuration.

For a more detailed mechanical and topology description, refer to the SIMATIC S7-400H Fault-Tolerant Systems manual available from the Siemens Industry Online Support portal under entry ID 6ES7 400-1HR0x-0xA0 family documentation, and the installation manual S7-400H Programmable Controller, Hardware and Installation.

H System Operating Modes and the Meaning of 'Gone Into Redundant Mode'

The H runtime distinguishes several operating modes. The diagnostic buffer event is generated when the H system transitions from a non-redundant mode to the redundant mode, i.e. the partner CPU has just become available and the system has re-acquired redundancy.

The message System (1 out of 2) has gone into redundant mode specifically indicates that CPU 1 of the H system has just re-entered the redundant operating state, i.e. transitioned from RUN-SOLO, STARTUP, or UPDATE into RUN-REDUNDANT. The number (1 out of 2) identifies the H-system instance, not the slot number, on multi-pair installations (H-system 1 of 2, H-system 2 of 2, etc.).

Three preconditions for the event are:

1. The partner CPU completed a successful link-up sequence.
2. The redundancy control re-established the master / standby role assignment.
3. No OB 70 (I/O redundancy loss), OB 72 (CPU redundancy loss), or OB 80 (timeout) is currently pending — otherwise the runtime will generate a parallel failure event.

Root-Cause Categories

Even though the message itself is informational, it is the direct result of an earlier event. The buffer should be read from the bottom up (oldest first). Field-proven cause categories are summarized below.

Category 1 — Synchronization Link (Sync Module / Sync Cable)

The most common cause of entering redundant mode after a transient fault is the synchronization link. Symptoms that align with this category:

• SF (System Fault) LED on one or both H-CPUs lit or flashing.
• IFM1F / IFM2F (interface module fault) or sync-module error LED lit on the affected subrack.
• Optical link budget marginal: the S7-400H link uses two POF or PCF fibers; a single bent or contaminated fiber causes intermittent sync loss.
• Recent subrack swap, sync module reseat, or fiber re-termination by maintenance.

Per the S7-400H manual, the synchronization link is designed for continuous operation. A link flap of more than ~1 s will trigger a redundancy loss event (OB 72), and the runtime will switch the affected CPU to RUN-SOLO. When the link is re-established, the standby CPU will be brought back into UPDATE and then RUN-REDUNDANT — which is exactly when the message in question is generated.

Category 2 — Partner CPU Restart

If the partner CPU was reset (STOP / MRES / power off / firmware update), the running CPU will hold the process in RUN-SOLO, retaining the master role. Once the partner completes start-up and link-up, the redundant mode event is logged. There is no inherent fault; the engineering question is why the partner restarted. Always scroll to the partner CPU's diagnostic buffer for the underlying cause.

Category 3 — I/O Redundancy Loss Recovery (OB 70)

Where a redundant PROFIBUS DP or PROFINET IO subsystem lost one channel — e.g. a switched channel module, an ET 200M, or a PN ring node — and is back, OB 70 will be triggered. The H system will re-establish I/O redundancy; the event is paired with the redundant-mode entry.

Category 4 — H-CiR / Configuration-in-RUN

Configuration changes in RUN on an H system go through H-CiR. The process is a two-phase commit during which the standby CPU goes through UPDATE and then a brief re-alignment. The redundant-mode event is the closure record for the commit.

Diagnostic Buffer Read-Out Procedure in STEP 7 V5.x

The standard engineering workflow on a maintenance call is:

1. Connect the programming device to the H-CPU (PG cable via MPI / PROFIBUS or Ethernet to CP 443-1).
2. In SIMATIC Manager, select the CPU in the project tree and press Ctrl + D (PLC > Diagnostics/Settings > Module Information). On an H system, this opens the H-aware diagnostic buffer that includes both CPUs.
3. Switch to the Diagnostic Buffer tab.
4. Sort by time (default: most recent first) and scroll to the redundant mode entry.
5. Select the event and click Open in Event Help to retrieve the Siemens IPI reference. Note the suggested OB and any module reference.
6. Click Save As and store the buffer as a .txt file for the report — never paste screenshots, the text file is the engineering artifact.
7. Repeat for the partner CPU. Compare the two buffers; the event order will reveal whether CPU A or CPU B was the source of the disturbance.

For the operating-mode confirmation, navigate to PLC > Operating Mode in SIMATIC Manager. The dialog shows, for each CPU in the H pair, the mode string (RUN, STOP, HALT), the role (Master / Standby), and the current state of the sync link (Link OK / Link Down / Link-Up). The redundant-mode event is consistent with the role block transitioning from Standby (no link) to Standby (linked) and then both CPUs reporting RUN-R (RUN-REDUNDANT).

Sample Diagnostic Buffer Excerpt (illustrative)

Seq  Date       Time         Event                                Module
001  12.03.2025 14:02:11.213  Partner CPU restart                  CPU 412-5H (slot 3)
002  12.03.2025 14:02:11.420  Link down                            Sync module slot 9
003  12.03.2025 14:02:14.984  Standby CPU STOP requested           CPU 412-5H (slot 4)
004  12.03.2025 14:02:18.220  Link up                              Sync module slot 9
005  12.03.2025 14:02:19.811  System (1 out of 2) has gone into redundant mode  CPU 412-5H

The bottom-to-top read of such a list shows: link down → partner restart → link up → redundant mode. The relevant question is why the link went down in the first place.

Procedure: Step-by-Step Triage

1. Confirm both CPUs are present and identical. In the H-aware module information, check that both CPUs report the same order number and the same firmware release. Mixed firmware on an H pair is a known cause of sync instability. The CPU 412-5H firmware V6.0.6 (and later) is the published baseline for many plants; consult the S7-400H compatibility list for the exact pairing rules.
2. Read the operating mode of both CPUs. Both should show RUN-R after the redundant-mode event. If only one shows RUN-R and the other is STOP / RUN-Solo, the event was transient and the recovery is incomplete.
3. Inspect the sync link.
   • Check the duplex fiber-optic cable for bends below 25 mm radius, kinks, dirt on the polish, or any gap at the SMI / Sub-D connector.
   • Verify the link length budget: POF ≤ 10 m, PCF ≤ 100 m. For 410-5H systems the maximum depends on the SFP / sync module variant — confirm against the S7-400H installation manual.
   • Reseat both sync modules. Power-down is recommended even though sync modules are designed for hot-swap; observe ESD precaution.
4. Check the subrack health. On S7-400 UR2 / UR2-A subracks, a missing or loosely seated fan tray raises the subrack temperature, which the IM / sync module reports as a fault. Inspect the FAN and SF LEDs on the PS 407 / PS 405 power supplies.
5. Look for environmental causes. Vibration on cabinet doors can chafe the POF cable, and high-EMI areas (VFD cabinets, welding) can break the link even at short distances. The fiber link is intrinsically immune to EMI, but the sync module's electrical sub-section (DC-DC, FPGA) is not.
6. Cross-check the partner CPU buffer. A partner buffer showing a memory reset, a STOP command, a firmware update, or a watchdog event is the actual root cause; the redundant-mode event is the consequence.
7. Verify I/O redundancy state. In PLC > Operating Mode > I/O Redundancy, all DP / PN slaves with redundancy should report active on both channels. A slave reporting passive or faulted will keep OB 70 pending and prevent full redundancy.

Sync Module Selection, Installation, and Link Budget

The sync module part number is critical. The 6ES7960-1AA04-0XA0 module is the standard for 6GK/6XV cable bundles up to 10 m, while 6ES7960-1AA06-0XA0 (and successor) is the long-distance / high-availability variant. Mismatched module types on an H pair are not supported and produce immediate sync faults on the first link-up.

Cross-Reference: S7-1500H 55 ms Failure Window

The S7-1500H family has a documented failure scenario in which both redundant Ethernet sync connections drop within a 55 ms window. The resulting behavior in the H runtime is a fallback to a deterministic single-CPU state with the partner treated as failed. The documented reference is the TIA Portal manual collection, section Application planning > Failure scenarios > Failure of both redundancy connections in S7-1500H ≤ 55 ms apart:

TIA Portal manual — Failure of both redundancy connections in S7-1500H (≤ 55 ms apart)

Although the S7-400H sync layer is implemented on a different physical layer (fiber-optic sync modules, not PROFINET) and uses a different redundancy control firmware, the diagnostic philosophy is identical: classify the redundant-mode event by the underlying loss-of-link event, the role assignment transition, and the recovery window. Field engineers maintaining a mixed S7-300H / S7-400H / S7-1500H fleet benefit from applying the same triage to both families.

Comparison: S7-400H vs. S7-1500H Operating States

Verification Procedure After Recovery

1. In SIMATIC Manager, open PLC > Operating Mode and confirm both CPUs report RUN-R and the sync status Link OK on both sides.
2. Force a CiR (configuration-in-RUN) test or a planned partner restart to confirm the redundant-mode event is reproducible only as a controlled operation, not from a spontaneous fault.
3. Read the SZL (System State List) via PLC > Module Information > Diagnostic Buffer > Save As or via SFC 51 (RDSYSST) — the SZL index 0x0424 (H-system status) and 0x0425 (H-state) can be polled from the user program for continuous health monitoring.
4. Read the diagnostic buffer of all DP / PN slaves via SFC 13 (DPNRM_DG) and check for OB 70 events. OB 70 should not be pending after a clean redundant-mode transition.
5. Confirm the standby CPU is performing cyclic memory comparison with the master. In PLC > Operating Mode the standby role should show Standby (linked), not Standby (no link).
6. Optionally, run the H system through a controlled power-fail test on the standby CPU only (master must remain in RUN) and verify that the redundant-mode event is logged without any OB 72 fault. The recommended method is a controlled stop of the standby CPU via mode switch on a non-production window, followed by start-up. This is the canonical smoke test for an H system.

When the Message Indicates an Actual Fault

The redundant-mode event is a fault indicator if any of the following co-occur:

• OB 70, OB 72, OB 80, OB 82, OB 86, or OB 87 is pending in the diagnostic buffer.
• One CPU shows SF LED latched on after the event.
• Process I/O went into safe state (e.g. PROFINET devices report station failure).
• The H state does not settle to RUN-REDUNDANT within 30 s — i.e. the standby CPU is stuck in UPDATE or LINK-UP.
• Memory comparison failure (SZL 0x0425 bit "memory diff") is reported and cannot be cleared by an H-CiR re-alignment.

In those cases the diagnostic buffer of both CPUs must be read end-to-end, and the event just before the redundant-mode message is the actual fault. The remaining steps are the standard S7-400H repair flow per the fault-tolerant systems manual.

Diagnostic Buffer Save Procedure (Recall)

Because the diagnostic buffer is the primary evidence in an S7-400H call, save it correctly:

1. From SIMATIC Manager, select the CPU in the project view.
2. Press Ctrl + D to open the module information.
3. Select the Diagnostic Buffer tab.
4. Click Save As… and choose a .txt file destination. The output is a fixed-column text file that includes the event index, timestamp, event class, event ID, and event text — this is the canonical record.
5. Repeat for the partner CPU and store both files in the same folder with a clear naming convention (e.g. 412-5H_slot3_2025-03-12_buffer.txt).

Screenshots of the dialog should never replace the .txt artifact. The text file is the input for event-ID lookups and for inclusion in the maintenance report.

Programmatic Detection: SZL Polling Snippet (Structured Text)

For continuous health monitoring from the user program, poll the H-state SZL:

// S7-400H SZL read for H-system status (index 0x0424)
// and H-state (index 0x0425)
// Call SFC 51 (RDSYSST) with the SZL ID and store the result in a DB
// for trend analysis in the HMI or SCADA layer.

DATA_BLOCK DB_H_Status
  STRUCT
    H_State         : WORD;   // bit field, see manual
    Master_Residence : WORD;   // slot of master CPU
    Standby_Residence : WORD; // slot of standby CPU
    Link_OK         : BOOL;   // sync link healthy
    Memory_Diff     : BOOL;   // standby memory differs
    Redundancy_Established : BOOL;
  END_STRUCT
END_DATA_BLOCK

// In OB 1 (or OB 35):
CALL SFC 51 (
  REQ     := TRUE,
  SZL_ID  := W#16#0425,        // H-state
  INDEX   := W#16#0000,
  RET_VAL := RET,               // 0 = OK
  BUSY    := BUSY_FLG,
  SZL_HEADER := SZL_HDR,        // 4-byte header
  DR      := H_STATE_BUF        // 34-byte payload into DB_H_Status
);
// Evaluate the bits per the manual and write to DB_H_Status members.

The relevant manual section is SIMATIC S7-400H Fault-Tolerant Systems > Diagnostics > SZL; the SZL index 0x0424 (H-system) and 0x0425 (H-state) are documented as the runtime-accessible H-state registers.

Troubleshooting Matrix

Safety-Related Considerations for S7-400F / S7-400FH

If the H pair is configured as S7-400F / S7-400FH with F-CPUs (e.g. CPU 416F-3 PN/DP) and the S7 F-systems safety package, the redundant-mode event is also a safety-relevant state transition. The F runtime logs its own passivation / re-integration events in the safety diagnostic buffer. The F-host and F-I/O must be in the same passivation state across the H pair; an asymmetric state will keep the safety program in passivation. Always cross-check the safety diagnostic buffer in the F-CPU's F-Diagnostic dialog (provided by the S7 F ConfigurationPack) before clearing a redundant-mode event from a safety-process point of view.

Hardware Reference Snapshot

Always verify the exact catalog reference against the project's BOM and the latest S7-400H spare-parts list. Siemens regularly publishes update packages and successor part numbers; for example, the CPU 412-5H is available in a -0AB0 revision (newer firmware) and an earlier -0AA0 revision (legacy firmware), and the two revisions cannot be mixed in an H pair.

FAQ