Siemens S7-400H CPU 412-3H STOP LED Blinking Troubleshooting

1. Problem Statement: Blinking STOP LED on S7-400H CPU 412-3H

A Siemens SIMATIC S7-400H high-availability installation reports a persistent STOP LED blink pattern on one CPU of the redundant pair. The reported configuration is:

• CPU model: CPU 412-3H (MLFB 6ES7 412-3HJ14-0AB0)
• Firmware: V4.5
• Location of failing CPU: Rack-1 of the H-system
• Rack-0 CPU: operating normally, no STOP blink
• Recent event: Ethernet module in Rack-1 had all LEDs blinking, was sent for service, returned and reinstalled
• Behavior: After a memory reset the STOP LED sometimes extinguishes for a few seconds, then resumes blinking

The remainder of this guide is structured as a systematic troubleshooting workflow that maps each observation from the field report to a diagnostic action, root-cause candidate, and verified resolution step. All diagnostic paths assume STEP 7 V5.5 SPx (or compatible) with the S7-400H option package installed, since S7-400H is not programmable from TIA Portal without the redundancy option.

2. S7-400H Hardware Platform Overview

The SIMATIC S7-400H is a fault-tolerant PLC platform composed of two redundant CPUs of identical type and identical firmware version, operating in parallel using an event-synchronised redundancy protocol. The official S7-400H system manual is the primary reference:

• SIMATIC S7-400H Fault-Tolerant Systems System Manual (entry ID 109751566)
• S7-400H Module Data Reference Manual
• S7-400H Commissioning and Configuration

Key architectural points relevant to the reported symptom:

1. Each rack (Rack-0 and Rack-1) contains its own CPU 412-3H, its own power supply (PS 405 or PS 407), and its own I/O or distributed I/O interface modules.
2. The two CPUs communicate through two redundant fibre-optic links. These are normally terminated in CP 443-1 or in the integrated PROFINET interface of the CPU 412-3H, depending on the configuration.
3. Both CPUs must have identical firmware versions. Mixed-firmware redundancy pairs are not supported and can produce STOP-blink patterns that resemble the one described.
4. The CPU carries a hardware switch on the rear that selects the rack number (Rack-0 or Rack-1). A mismatched position will produce a permanent redundancy error.

3. CPU 412-3H Identification, LEDs, and Switch Settings

The CPU in the field report is identified by the Siemens MLFB 6ES7 412-3HJ14-0AB0, firmware V4.5. The dash segment breaks down as:

Reference documentation:

• CPU 412-3H (6ES7 412-3HJ14-0AB0) Operating Instructions
• CPU 412-3H product listing (Siemens Industry Online Support)

3.1 LED Indicators on the CPU 412-3H Front Panel

A blinking yellow STOP LED specifically (not solid STOP, not RUN with blinking SF) is the diagnostic pattern the CPU uses when it has performed a memory reset and is requesting an overall reset / is unable to find a valid project on the memory card, OR when a redundant-coupling fault or rack fault recurs immediately after restart.

3.2 Rack Selection Switch on the Rear of the H-CPU

Each H-CPU carries a mechanical selector on its rear that fixes the rack role. Before any software work, physically verify on both CPUs:

• Rack-0 CPU: switch set to position 0
• Rack-1 CPU: switch set to position 1

4. H-System First-Boot Behavior and the 90-Minute Self-Test

A behaviour explicitly called out in the discussion thread and documented in the S7-400H system manual is that an H-system performs an extensive self-test on its very first commissioning, and again on every restart when no backup battery is present in the PS module. The self-test can take up to 90 minutes during which the CPU alternates between RUN, STOP, and link-check states.

Conditions that force the self-test to re-run on every restart:

1. No backup battery (lithium AA or equivalent per PS module variant) installed in the PS 405 / PS 407.
2. Battery below threshold voltage (typical warning threshold 2.7 V).
3. Memory card (MMC, since this CPU does not use a SIMATIC Micro Memory Card in the traditional sense — confirm by checking the slot type) absent or unreadable.
4. Hardware configuration mismatch between the two racks detected at boot.

If the field condition is that the STOP LED has been blinking for many hours without ever settling, the 90-minute self-test is no longer the suspect. Move to the diagnostic procedure below.

5. Root Cause Analysis for STOP LED Blinking on Rack-1

Based on the symptoms described (blinking STOP on Rack-1 only, briefly clears after reset, recurring Ethernet module history on the same rack), the working root-cause matrix is:

Rank 1 is the most consistent with the reported symptom profile because of the recent Ethernet module event on the same rack. Rank 3 and 4 are quick to verify and are the highest-yield low-effort checks.

6. Step-by-Step Diagnostic Procedure

Execute these steps in order. Do not skip the physical checks before going online.

1. Power down both racks. Verify the rear selector switch on each CPU: 0 on the Rack-0 CPU, 1 on the Rack-1 CPU. Reseat the CPU.
2. Inspect fibre-optic redundancy links. Both CPUs must see each other on the redundancy ports. A loose connector produces exactly the described brief-clears-then-blinks pattern.
3. Verify memory card. The CPU 412-3H uses a SIMATIC Memory Card. The field report mentions "memory card option" — confirm the card is present, that the contacts are clean, and that the project on it matches the physical rack configuration.
4. Power up and observe. Watch the LED sequence for 20 to 30 minutes without intervening. Record the exact LED sequence on the Rack-1 CPU.
5. Connect STEP 7 to Rack-0 (the one running normally) via PROFIBUS or Ethernet. Open the project online.
6. Read the diagnostic buffer of the Rack-1 CPU from STEP 7: PLC → Module Information → Diagnostic Buffer. The latest entry will identify whether the STOP was caused by a redundancy-loss event, an I/O fault, an OB-not-loaded fault, or a programming error.
7. Read the diagnostic buffer of the Rack-0 CPU. The Rack-0 buffer will log any partner-CPU-down events with timestamps matching the Rack-1 blink.
8. Compare firmware: PLC → Module Information → General. Both must show V4.5 (or whatever the project expects). If they differ, this is the fault.
9. Pull the recently serviced Ethernet module from Rack-1 and restart. If the blink clears, the module or its slot is the cause.
10. Re-insert the Ethernet module, confirm IP/subnet/gateway against the project, and re-test.

7. Diagnostic Buffer Interpretation

The diagnostic buffer is the single most informative tool for this symptom. Common entries that match the observed behaviour and what they mean:

Reference: Siemens KB entry on reading the S7-400 / S7-400H diagnostic buffer (entry ID 67596070).

8. Firmware Version Verification Between the Redundant CPUs

The H-system protocol requires the two H-CPUs to share the same firmware version. STEP 7 will allow an asymmetric update in some cases but the runtime will not tolerate it.

1. Open STEP 7, go online to Rack-0.
2. Open PLC → Module Information → General. Record the firmware version of the Rack-0 CPU.
3. Switch online connection to Rack-1 (via MPI/DP on Rack-1 or via Ethernet routing) and record the same field.
4. Compare against the project hardware configuration (HW Config → CPU properties → Order / Firmware).
5. If any differ, the H-system cannot complete redundancy hand-shake. Update the lower-revision CPU using the Siemens firmware update tool, then full memory reset.

9. Error OB Configuration (OB82, OB86, OB70, OB72, OB121, OB122)

The original poster explicitly raised OB82 (diagnostic interrupt) and OB86 (rack failure). In an S7-400H project both OBs are essential — without them, a transient diagnostic event from any module forces the CPU to STOP rather than continue operation.

Skeleton error OB to satisfy the H-system baseline:

// OB82 - Diagnostic Interrupt
// Just acknowledge and return; do not stop the CPU.
// Reading the diagnostic buffer entry tells you which module raised it.

// OB86 - Rack Failure
// Do not stop the CPU on a single rack event; log the event ID and continue.

Reference: S7-400H System Manual, section on error OBs.

10. Rack-1 Ethernet Module Fault Isolation

Because the field report documents that the Ethernet module on Rack-1 had all LEDs blinking before being sent for service, it is the prime suspect. The fact that the blink reappeared after the module was reinstalled means one of the following is still true:

1. The Ethernet module was returned with a different firmware or hardware revision than the project expects.
2. The module's IP / subnet / gateway / PROFINET device name was not re-assigned after the swap.
3. The module is in a slot that does not match the HW Config of the project (slot mismatch → OB86 → STOP).
4. The fibre-optic / copper patch between this module and the rest of the network was disturbed during the service and is intermittent.

Procedure to isolate:

1. Open HW Config, compare the slot assignment of the Ethernet module in Rack-1 against the physical rack.
2. Compare the Ethernet module's PROFINET device name and IP address (set via STEP 7 → PLC → Ethernet → Edit Ethernet Node) against the project.
3. Pull the Ethernet module from Rack-1 and start the H-system without it. If the blink clears, the module or its slot is the cause.
4. Replace the module with a known-good spare if available.

11. Verification, Commissioning, and Long-Term Checks

Once the system is back to a clean RUN state on both CPUs, run the following verification pass:

1. LED verification: Both CPUs show RUN solid green. SF, INTF, EXTF, IFM1F, IFM2F all off. RACK0 LED solid on the Rack-0 CPU, RACK1 LED solid on the Rack-1 CPU.
2. Redundancy test: Pull the fibre from one of the two redundancy ports. The system should continue in RUN without interruption. Reconnect. Verify the diagnostic buffer of both CPUs records the event.
3. Rack failover test: Power down the Rack-1 CPU. Rack-0 must continue RUN. Re-power Rack-1, verify it re-synchronises and returns to RUN-Redundant.
4. Diagnostic buffer: Clear the diagnostic buffer on both CPUs and confirm it stays clean during 30 minutes of normal operation.
5. Battery test: Confirm BATT LED on PS 407 is off on both racks. Replace batteries older than 3 years as preventive maintenance.
6. Firmware record: Document the firmware version of both CPUs in the asset register so future replacements match.

12. Troubleshooting Matrix and Field-Proven Cautions

Frequently Asked Questions