Resolving S7-400 STOP Mode from Hardware Configuration Mismatch

1. Problem Overview

An Siemens SIMATIC S7-400 CPU 416-3 PN/DP transitions to STOP operating mode immediately after a Hardware Configuration download from SIMATIC Manager (Step 7 V5.x) when the configured rack does not match the physically inserted modules. The SF (System Fault) LED is illuminated on the CPU, and the diagnostic buffer records a configuration mismatch event. A second symptom occurs when a user program from a different S7-400 CPU (e.g., 416-2 DP) is downloaded into the new CPU: the controller again enters STOP, but in this case no LED is lit, leaving the engineer without an immediate visible fault indicator.

This is a classic hardware configuration mismatch condition and is fully expected behavior of the S7-400 firmware. The CPU compares the configured slot map in System Data (SDB) with the actual physical presence of modules detected during power-up and refuses to enter RUN when the two do not agree.

2. Affected Hardware and Firmware

Both CPUs belong to the same S7-400 V7 generation and are binary-compatible at the user-program level, but they have different hardware catalogs, different default PN/DP interface configurations, and a different number of communication resources. The CPU 416-3 PN/DP adds a PROFINET interface on the X5 port in addition to the MPI/DP (X1) and PROFIBUS-DP (X2) ports present on the 416-2 DP.

3. Root Cause Analysis

The S7-400 firmware performs a strict physical-vs-configured reconciliation on every transition from STOP to RUN and on every cold/warm restart. The reconciliation process checks:

1. Slot population — Every rack slot (0-18) configured in HW Config must contain the exact module type specified, identified by order number (MLFB) and hardware revision.
2. Module diagnostic — All configured modules must respond on the backplane bus during the slot-check phase.
3. Interface consistency — The MPI, DP, and PN (where present) interface parameters in SDB must be valid for the CPU type in use.
4. User program signature — The downloaded blocks (OB, FB, FC, DB) must be compileable against the new CPU's instruction set and resource map.

If any of these checks fail, the CPU enters STOP with a fault entry written to the diagnostic buffer. The behavior described in the source — first download with SF LED on, then user program copy with no LED on — corresponds to two distinct fault conditions:

4. Why the SF LED Disappears on the Second Download

When the original, mismatched System Data is overwritten by the user program copy, the diagnostic buffer is itself partially overwritten. The S7-400 keeps the most recent 100 diagnostic events in a ring buffer; once the new (still inconsistent) SDBs are loaded, the buffer may be repopulated with startup-type entries that do not raise the SF latch. The CPU then holds in STOP because the startup OBs (OB100/OB101/OB102) and the error OBs are either missing or referenced resources that no longer exist in the new CPU's resource map.

Key points:

• The S7-400 distinguishes hardware-detected faults (which set SF) from startup-time aborts (which simply hold the CPU in STOP without raising SF if OB100/OB101/OB102 are missing or empty).
• Copying Data Blocks from a different CPU is safe only if the DB interfaces match exactly; copying System Data from a different CPU is always wrong and will cause a STOP condition.
• The absence of an LED does not mean the CPU is healthy — it only means no active hardware fault is latched at the time of inspection. Open the diagnostic buffer in STEP 7 to see the real cause.

5. Diagnostic Procedure: Reading the Diagnostic Buffer

The diagnostic buffer is the single most important tool for any S7-400 STOP-mode investigation. Procedure in SIMATIC Manager:

1. Connect to the target CPU via Accessible Nodes or via the configured PG/PC interface.
2. Select the target CPU in the project tree.
3. Choose PLC → Diagnostic/Setting → Diagnostic Buffer (German: Zielsystem → Diagnose/Einstellung → Diagnosepuffer).
4. Read the most recent entries. Each entry has a timestamp (relative to power-on) and an event code.
5. Double-click any entry to open the help text that explains the event in detail.

Common event codes for the symptom in this article:

6. Correct CPU Replacement Procedure

The field report recommends a clean, supported migration path: right-click on the CPU in HW Config and select "Change CPU…" (German: CPU tauschen). This is the proper method for upgrading within the S7-400 family. STEP 7 then asks for the target CPU type, copies the existing hardware tree, and re-parameterizes only the differences between the old and new CPU (interface assignments, work memory, communication resources, integrated PN if present).

1. Open the existing project in SIMATIC Manager (V5.5 SP4 or later recommended).
2. Open HW Config for the station containing the 416-2 DP.
3. Right-click the CPU icon (slot 3) and select Change CPU.
4. Choose CPU 416-3 PN/DP with the same firmware version if possible.
5. Confirm the change. STEP 7 will report any incompatible objects (e.g., F-modules if going from F to non-F).
6. Open Station → Save and Compile (Strg+S).
7. Verify the slot map matches the physical rack you intend to use.
8. Download the entire station to the new CPU using PLC → Download.

7. PLCSim Validation Workflow

PLCSim (S7-PLCSIM V5.4 SP5 or later) emulates the S7-400 CPU, including the diagnostic buffer and STOP/RUN state machine. The discussion thread specifically recommends PLCSim to verify the new program before field deployment.

1. Open the project in SIMATIC Manager.
2. Start S7-PLCSIM from the toolbar.
3. Download the HW Config and the user program to the simulated CPU.
4. Use the PLCSim CPU panel to toggle the simulated CPU from STOP to RUN.
5. Monitor OB1, OB100, and any user OBs using the PLCSim watch table.
6. If the simulated CPU enters STOP, read its diagnostic buffer (right-click the PLCSim CPU → Diagnostic Buffer) to identify the cause before going to the field.

PLCSim does not require a real rack, so the entire hardware configuration can be tested against the new CPU type without any physical hardware. The limitation is that PLCSim does not validate physical module presence — it validates only the programmatic configuration. The final field acceptance must still confirm that the real rack matches HW Config.

8. Field Commissioning Procedure for the 416-3 PN/DP

Given the production-line constraint mentioned in the source (2-day window, must reuse old I/O modules from the 416-2 DP machine), the following procedure is recommended:

1. Power down the existing 416-2 DP rack. Note the slot-by-slot module layout (labels, MLFBs, firmware stickers).
2. Replace the CPU with the 416-3 PN/DP in slot 3. Re-seat all I/O modules in the same slots they occupied previously.
3. Connect a PG to the CPU via MPI/DP (X1) using a PC-Adapter USB or CP 5611/CP 5621.
4. Open the migrated project (already changed from 416-2 DP to 416-3 PN/DP via the Change CPU wizard).
5. Perform a full Download to Target: HW Config, then user program, then System Data. Use PLC → Download User Program to Memory Card if the project will be archived on the PLC's Flash card.
6. Switch the CPU to RUN via the PG (PLC → Operating Mode → RUN) or the mode selector switch.
7. Observe the RUN LED and SF/BF/INTF/EXTF LEDs. A clean start shows only RUN and DC5V green.
8. Read the diagnostic buffer immediately after a successful RUN to confirm no latent events.

9. LED Status Reference

The absence of all fault LEDs (SF, BF, INTF, EXTF) with the CPU in STOP indicates a startup-time abort, not a runtime hardware fault. The diagnostic buffer must still be read to determine the cause.

10. System Data Blocks vs User Program

A common source of STOP conditions in S7-400 migrations is confusion between System Data and the User Program:

When migrating from 416-2 DP to 416-3 PN/DP, the System Data must be regenerated by STEP 7 when the CPU is changed. Manually copying SDBs from the old project is not supported and produces the silent-STOP behavior described in the source. The user program (OB1, OB100, all FBs/FCs/DBs) can usually be reused verbatim, provided the new CPU has at least the same work memory and the same number of S7-400-specific resources (timers, counters, bit memory, I/O).

11. Memory Reset and Re-Commissioning

If the CPU is stuck in STOP with no LED and the diagnostic buffer points to a system-data inconsistency, a memory reset followed by a clean download will clear the condition:

1. Set the mode selector to MRES and hold for ~3 seconds until the STOP LED flashes slowly.
2. Release the switch, then within 3 seconds turn it back to MRES and hold again until the STOP LED is steady on.
3. Release — the CPU is now memory-reset and the diagnostic buffer is cleared.
4. Connect with STEP 7 and download HW Config first, then user program.

12. Pre-Deployment Verification Checklist

13. Key Takeaways

• Yes, the physical rack must match the SIMATIC Manager hardware configuration exactly — there is no "best-effort" mode in the S7-400.
• Copying a user program (OB/FB/FC/DB) from a different CPU is permitted if the CPU family and interfaces are compatible, but System Data must be regenerated by STEP 7.
• A STOP condition with no LED is a startup-time abort, not a hardware-detected fault — always read the diagnostic buffer.
• Use STEP 7's Change CPU wizard to migrate within the S7-400 family. It preserves the program and updates only the system data.
• Validate every migration in PLCSim before taking the production line offline.

14. Frequently Asked Questions