Is the S7-400 diagnostic buffer interpreted the same way as the S7-300, or does the high-availability H-System introduce additional fault categories that require different diagnostic steps? The S7-400 standard CPU (CPU 41x) uses the same event class system as the S7-300 and is read identically in STEP 7. However, the S7-400H (High Availability) system with redundant CPUs introduces additional fault classes (16#29xx, 16#2Axx) that indicate synchronization events and redundancy switchover conditions — events that have no equivalent in the S7-300 or S7-400 standard CPU. The S7-400F (Failsafe) introduces safety-program-specific diagnostic entries. This Siemens S7-400 CPU fault codes STEP 7 diagnostic buffer complete reference covers all 41x, 41xH, and 41xF CPUs, with the specific interpretation for each event class and the correct diagnostic action.
- Accessing the S7-400 Diagnostic Buffer in STEP 7
- TIA Portal vs STEP 7 Classic: Reading the Diagnostic Buffer
- Complete S7-400 Event Class Reference
- S7-400 CPU STOP Reason Codes
- S7-400H Redundancy Fault Codes
- S7-400F Safety Program Fault Codes
- S7-400 Organization Block Fault Response Table
- S7-400 Scan Time and Cycle Monitoring Configuration
- Technical Validation
- Frequently Asked Questions
Accessing the S7-400 Diagnostic Buffer in STEP 7
The S7-400 diagnostic buffer is accessed through STEP 7 SIMATIC Manager identically to the S7-300:
STEP 7 SIMATIC Manager →
PLC → Diagnostics/Setting → Module Information →
Select: CPU (not the rack; not the IM) →
Diagnostic Buffer tab
S7-400 diagnostic buffer capacity: the S7-400 CPU stores up to 3200 diagnostic buffer entries (compared to 100 for most S7-300 CPUs). This larger buffer is critical for high-availability applications where multiple switchover events may occur between maintenance windows.
Online alternative: in HW Config → Online → Module Information. The HW Config method shows the same buffer content with the addition of a visual rack layout.
S7-400H with active standby: when using an S7-400H, STEP 7 can read the diagnostic buffer of each CPU independently. Connect to the Master CPU (CPU A) and Standby CPU (CPU B) separately to read their individual buffers — redundancy switchover events show the transition from the perspective of each CPU.
Reading the S7-400 Diagnostic Buffer via TIA Portal (Migrated Projects)
Siemens S7-400 CPUs can be used in TIA Portal when a STEP 7 project has been migrated to TIA Portal V13 SP1 or later via the Project Migration Wizard (Extras → Migrate Project). Once migrated, the S7-400 diagnostic buffer is accessible through TIA Portal’s Online & Diagnostics interface, but with important differences from the STEP 7 Classic path:
TIA Portal path for S7-400 diagnostic buffer:
1. Open TIA Portal → go online with the S7-400 CPU (set the PG/PC interface to the correct network adapter).
2. In the Project tree, right-click the S7-400 CPU → Online & Diagnostics.
3. In the Online & Diagnostics window, expand Diagnostics → Diagnostic buffer.
4. The buffer shows the same event codes as in STEP 7 Classic, but the display format differs: TIA Portal shows timestamps in ISO 8601 format and displays the system block number (OB/SFC call origin) in a separate column.
5. To export: click Save to file… → saves as .txt with the same event structure as STEP 7 Classic, compatible with post-processing scripts.
STEP 7 Classic path (for non-migrated projects):
1. Open STEP 7 → PLC → Module Information → Diagnostic Buffer tab.
2. Events appear in descending chronological order (newest first). The event code format is 16#XXXXYYYY where XXXX is the event class and YYYY is the associated information block.
3. Double-click any event to expand associated data (OB number, memory address, additional hex data).
4. Export via Save button — saves .mdi file readable only in STEP 7.
Critical difference: STEP 7 Classic .mdi exports cannot be opened in TIA Portal and vice versa. If you need to share diagnostic data between STEP 7 and TIA Portal environments, export as .txt from both tools.
Complete S7-400 Event Class Reference
S7-400 diagnostic events use the same STEP 7 event class format as S7-300:
| Event Class (hex) | Category | CPU Behavior | Common Cause |
|---|---|---|---|
| B#16#4A | Power-up / startup complete | Informational | Normal startup sequence |
| B#16#26 | STOP mode entered | CPU in STOP | Multiple causes — see STOP reason table |
| B#16#35 | STOP due to internal error | CPU forced to STOP | OB not called, programming error |
| B#16#36 | STOP due to hardware fault | CPU forced to STOP | I/O fault, backplane error, hardware test failure |
| B#16#39 | Module diagnostic interrupt | OB82 called (or STOP if missing) | I/O module internal fault |
| B#16#38 | Rack failure / I/O station fault | OB86 called (or STOP if missing) | IM module, expansion rack communication |
| B#16#3A | Insert/remove of I/O module | OB83 called (or STOP if missing) | Module hot-swap during RUN |
| B#16#25 | PROFIBUS DP slave failure | OB86 called | PROFIBUS station not responding |
| B#16#27 | PROFIBUS DP slave return | Informational | PROFIBUS station communication restored |
| B#16#2F | CPU parameter error | STOP or informational | Wrong configuration parameter downloaded |
| B#16#29 | H-System: redundancy switchover (S7-400H only) | Informational or fallback | CPU-A fails, CPU-B takes over |
| B#16#2A | H-System: synchronization error (S7-400H only) | H-state change | CPUs cannot synchronize |
| B#16#37 | Safety program diagnostic (S7-400F only) | F-System specific | Safety function violation |
S7-400 CPU STOP Reason Codes
When the S7-400 CPU enters STOP, the STEP 7 Module Information dialog shows the STOP reason in the General tab under “Last startup” or in the Diagnostic Buffer. The STOP reason code identifies the specific cause:
| STOP Reason | Code | Meaning | Fix |
|---|---|---|---|
| STOP due to OB not programmed | 0x20xx (OB number in xx) | Required OB called but missing from program | Add the missing OB |
| STOP due to cycle time exceeded (2nd time) | 0x3580 | OB80 called twice in one cycle | Reduce scan load; check for blocking SFC calls |
| STOP due to programming error | 0x3500 | Illegal instruction, division by zero, memory access error | Fix the programming error in the identified block |
| STOP due to I/O access error | 0x2521 | Module not responding, slot not configured | Restore I/O hardware or correct slot configuration |
| STOP due to insufficient memory | 0x3501 | Program exceeds CPU work memory | Reduce program size or upgrade to larger memory CPU |
| STOP due to priority conflict | 0x3502 | Priority class conflict in OB calling | Review OB interrupt priority assignments |
| STOP triggered by SFC46 in program | 0x2526 | User program explicitly called STOP | Locate SFC46 call in program |
The S7-400 (especially high-performance CPUs like the CPU 414, CPU 416, CPU 417) has a larger work memory and faster scan cycle than the S7-300, so cycle time exceeded events are less common — when they occur on an S7-400, the cause is typically a blocking communication SFC or a very large data structure being copied each scan.
S7-400H Redundancy Fault Codes
The S7-400H High Availability System maintains two synchronized CPU units (CPU-A and CPU-B) connected by fiber-optic Sync cables. The H-System fault codes are exclusive to the 414H and 417H CPU models:
S7-400H System States:
| H-System State | Meaning | LED Indication |
|---|---|---|
| Redundant | Both CPUs synchronized, both running | Both CPUs: RUN LED solid green |
| Single mode CPU-A | CPU-A running alone; CPU-B in STOP or fault | CPU-A: RUN; CPU-B: STOP |
| Single mode CPU-B | CPU-B running alone after switchover | CPU-B: RUN; CPU-A: STOP |
| Synchronizing | CPUs re-establishing synchronization | H-System sync LED flashing |
H-System fault event classes in the diagnostic buffer:
| Event Class | Code | Meaning | Impact |
|---|---|---|---|
| Redundancy loss | B#16#29 | Switchover from CPU-A to CPU-B (or B to A) | Process continues on single CPU; redundancy lost |
| Sync fiber fault | B#16#2A | Sync cable between CPUs disconnected or failed | Cannot re-synchronize CPUs; may trigger switchover |
| CPU-B not responding | B#16#2B | Standby CPU not accessible | Single mode; repair standby CPU |
| Re-synchronization started | B#16#2C | CPUs beginning memory synchronization | Both CPUs briefly in single mode during sync |
| Re-synchronization complete | B#16#2D | H-System returned to redundant state | Normal redundant operation restored |
Critical S7-400H diagnostic: if the buffer shows repeated B#16#29 switchover events at regular intervals, the CPUs are not remaining synchronized — investigate sync cable quality (fiber optic connectors dirty or damaged) and verify both CPUs are running identical program versions.
S7-400F Safety Program Fault Codes
The S7-400F (Failsafe) adds safety program (F-Program) execution alongside the standard user program. F-Program faults generate distinctive diagnostic entries:
| Safety Fault Type | Diagnostic Buffer Entry | Meaning |
|---|---|---|
| F-Program execution error | B#16#37 with F-DB identifier | Safety function block detected a violation |
| F-Channel error | B#16#37 with channel number | Safety input or output channel in error state |
| F-CRC error | B#16#37 CRC mismatch | Safety program memory integrity violation |
| F-Communication error | B#16#37 with F-Link info | F-Link (Profisafe) communication fault |
S7-400F faults require acknowledging via the STEP 7 Safety Console (not the standard diagnostic buffer interface) before the F-program can resume. For standard S7-300/S7-400 non-safety diagnostic buffer events, the S7-300 SF LED reference also applies to the S7-400’s SF LED behavior — see Siemens S7-300 Sf Led Error Diagnosis Step By Step Fix.
S7-400 Organization Block Fault Response Table
The S7-400 supports all S7-300 OBs plus additional OBs for high-availability and extended interrupt functions:
| OB | Trigger | S7-400 Response if Missing | S7-300 Equivalent |
|---|---|---|---|
| OB80 | Cycle time exceeded (1st occurrence) | STOP | Same |
| OB81 | Power supply fault or battery | Continues RUN (no STOP) | Same |
| OB82 | I/O module diagnostic interrupt | STOP | Same |
| OB83 | I/O module insert/remove | STOP | Same |
| OB84 | CPU hardware fault | STOP | Same |
| OB85 | Program cycle error | STOP | Same |
| OB86 | Rack failure / PROFIBUS station failure | STOP | Same |
| OB87 | Communication error | Depends on error type | Same |
| OB70 | I/O redundancy error (S7-400H only) | H-System specific response | Not available |
| OB71 | CPU redundancy error (S7-400H only) | H-System specific response | Not available |
| OB72 | CPU redundancy mode change (S7-400H only) | Informational only — no STOP | Not available |
| OB73 | Pull/plug of redundant I/O modules (S7-400H only) | H-System specific | Not available |
The S7-400 provides OBs 70–73 specifically for H-System events. If these OBs are not programmed in an S7-400H system, the H-System will enter single mode (one CPU running without redundancy) rather than stopping entirely — a key design difference from standard OBs.
For the S7-1200 and S7-1500 OB structure which evolved from the S7-400 architecture, see Siemens S7-1200 Error Codes Complete List.
S7-400 Scan Time and Cycle Monitoring Configuration
The S7-400’s cycle monitoring configuration differs from the S7-300 in that it supports multiple priority classes simultaneously, each with its own cycle time monitoring:
Default watchdog settings (S7-400): – OB1 (priority 1): scan cycle monitoring time configurable from 1 ms to 6000 s – Hardware interrupt OBs (priority 16–26): no individual watchdog (monitored by OB1 cycle) – Priority classes share the CPU time — a high-frequency hardware interrupt can reduce OB1 time
Configuring the S7-400 watchdog:
STEP 7 HW Config → Double-click CPU → Properties →
Cyclic Interrupts / Cycle Time →
Scan cycle monitoring time: [value in ms]
Priority of OB1 execution: [1–26; default 1]
Unlike the S7-300 (maximum watchdog 6000 ms), the S7-400 allows extremely long watchdog settings (up to 6000 seconds) for applications where occasional very long cycles are acceptable — but in practice, a watchdog above 5000 ms provides minimal protection.
For S7-300 OB80 cycle time exceeded diagnosis and the differences in S7-300 scan monitoring, see Siemens S7-300 Ob80 B#16#01 Cycle Time Exceeded Diagnosis.
For a cross-platform comparison of Siemens vs Allen-Bradley error code structures, see: Siemens Vs Allen Bradley Plc Error Code Comparison Guide
Technical Validation
S7-400 CPU fault code reference and diagnostic buffer event classes from the Siemens STEP 7 Error Code Reference Document 770453. Siemens S7-400 error code cross-reference for SCADA and OPC alarm management integration from Honeywell Process Solutions Siemens S7 PLC Error Codes reference. Industrial S7-400 system and H-CPU training from Penn State Berks PLC Industry Certificate Program.
Frequently Asked Questions
Does the S7-400 diagnostic buffer use a different format in STEP 7 compared to the S7-300, or are they read identically?
The S7-400 diagnostic buffer is read through the identical STEP 7 Module Information interface as the S7-300. The event class codes, Incoming/Outgoing event format, and Additional Information field structure are the same. The differences are in capacity (S7-400 stores up to 3200 entries vs. 100 for most S7-300 CPUs) and in the additional event classes available only on the S7-400H and S7-400F variants (redundancy and safety events). A technician familiar with S7-300 diagnostic buffer reading can work with the S7-400 buffer immediately — only the H-System and F-System specific event classes require additional knowledge.
The S7-400H diagnostic buffer shows “Redundancy switchover” at 3:15 AM every Saturday. What causes a scheduled redundancy switchover on a high-availability system?
A scheduled redundancy switchover at a fixed time typically indicates a planned maintenance task that briefly interrupts the sync fiber connection — a cleaning schedule on the fiber connectors, a UPS test that momentarily affects the power supply of one CPU rack, or (rarely) a firmware difference between the two CPUs that causes one CPU to fail its internal consistency check at the same time each week. The S7-400H requires both CPUs to run identical program versions and have identical hardware configurations. If one CPU received a firmware or configuration update while the system was in single mode, the CPUs may have a parameter mismatch that periodically triggers a re-synchronization event. Check that both CPU racks have identical 24VDC supply quality and that the Sync fiber connectors are clean (IEC 61300-3-35 compliant cleaning tools).
The S7-400F safety program diagnostic shows a CRC mismatch error. What can cause a safety program CRC to change without any programming changes?
A safety program CRC mismatch on the S7-400F without intentional programming changes indicates that the F-Program memory content has changed unexpectedly. Causes: (1) a memory error in the CPU (rare but possible after extended operation or thermal cycling) — the CRC check detected data corruption in the F-Program storage; (2) a partial program download was performed that updated only some blocks, and the CRC mismatch is detecting the inconsistency between the updated block and the remaining older blocks; (3) the CPU clock battery discharged, causing retain memory loss that affected F-Program parameters stored in retain DBs. In all cases, the correct recovery is to perform a complete F-Program download from the STEP 7 Safety Console (not a partial block download) and verify the CRC matches the expected value from the last validated F-Program version.
Can a STEP 7 project developed for an S7-400 standard CPU be loaded into an S7-400H CPU?
Yes, but with required additions. An S7-400 standard CPU project can be compiled and downloaded to an S7-400H CPU, and the standard user program will run. However, to take advantage of the H-System redundancy, the project must be configured in STEP 7 as an H-System project (with both CPUs defined in HW Config), and the redundancy-specific OBs (OB70, OB71, OB72, OB73) must be programmed if the application requires graceful handling of redundancy events. Without OB70–73, the H-System will enter single mode on redundancy events without the program being notified — the process continues on one CPU but the application cannot log or respond to the redundancy condition.