Troubleshooting S7-300 PLC Stop Mode Diagnostic Buffer and OB

1. Problem Overview

An Siemens S7-300 CPU that transitions to STOP during operation and refuses to return to RUN is one of the most disruptive failure modes in brownfield plants. Operators see the STOP LED illuminated, the process outputs drop to their configured substitute values, and field equipment either holds last state (for retentive outputs) or de-energizes depending on the wiring and the values defined in the hardware configuration (HW Config) of STEP 7. The user program is no longer executed, so the controlled process is brought to a safe, idle state per Siemens functional description of S7-300/S7-400 operating modes (STOP mode - S7-300/S7-400).

The classic field symptom reported is: CPU enters STOP, MRES / RUN selector toggle fails to recover, hot-restart does not occur, and only a hardware swap returns the line to service. Before declaring the CPU scrap, every STOP event must be traced to a root cause through the diagnostic buffer (Diagnostic Buffer / Diagnosepuffer) and the active error organization blocks (OBs).

2. STOP Mode Fundamentals on S7-300 CPUs

The S7-300 operating state machine is shared across the 312, 314, 315-2 DP/PN, 315F-2 DP/PN, 317-2 DP/PN, 317F-2 DP/PN, and 319-3 PN/DP families. STOP semantics per the Siemens functional description:

• User program execution is suspended (OB1, OB35, OB40, OB82, OB85, OB86, OB100, OB121, OB122 all stop).
• All process outputs are forced to the substitute values configured in HW Config (0, 1, or Hold Last Value).
• Forcing is removed; the force table is reset on the next RUN start.
• The diagnostic buffer, real-time clock, and retentive flags/Markers/timers/counters remain intact.
• The CPU accepts online configuration changes only via STEP 7 and ignores most user commands from the program.

Powering the CPU down and back up performs a complete restart (OB100); the MRES selector position performs a memory reset that clears the work memory, reload from MMC, and a cold restart. If MRES is not successful, the failure is almost always traceable to either a corrupted MMC, a defective CPU firmware, or a system fault that the OB hierarchy cannot mask.

3. Root Cause Matrix

STOP events on S7-300 fall into seven well-defined categories. The diagnostic buffer event ID and the active SF/BF/FRCE/MAINT/SD LED combination disambiguates each case.

4. Diagnostic Buffer Retrieval Procedure

The diagnostic buffer is the single most valuable artifact when an S7-300 enters STOP. The buffer holds the last 100 (small) to 500 (large) entries with millisecond timestamps, allowing reconstruction of the chain of events leading to STOP.

1. Connect the engineering station running STEP 7 V5.6 / V5.7 (classic) or TIA Portal V17–V20 to the CPU's MPI/DP/PN interface.
2. Open the project that contains the offline hardware configuration matching the physical rack. If the offline project is unavailable, use "Accessible Nodes / Online > Diagnostic" for read-only retrieval.
3. Navigate to CPU > Module Information > Diagnostic Buffer (in TIA Portal: Online & Diagnostics > Diagnostics buffer).
4. Read the most recent events in reverse chronological order. Identify the event ID, the affected OB, the module address (logical / geographic), and the timestamp.
5. Export the buffer to a text file (right-click > Save As). The export preserves the 16-bit and 32-bit raw values needed to query Siemens SIMATIC Technical Support.
6. Cross-reference the top-of-buffer STOP entry with the Stack tab of the Module Information dialog. The B (break) stack pinpoints the instruction that triggered a programming error (OB121/OB122).

5. OB-Based Fault Classification

Error OBs are the second pillar of the diagnostic process. The presence or absence of an OB at runtime determines whether the CPU enters STOP for a given fault class. This is the principle alluded to in the field report: "Hardware problems will only cause the PLC to stop if you haven't loaded the corresponding hardware error OBs into the PLC."

For a robust installation, a minimum set of OBs should be loaded even if empty: OB82, OB85, OB86, OB100, OB121, OB122. This converts a hard STOP into a logged and recoverable fault, allowing the process to be brought down through controlled logic in OB85/OB86 rather than the CPU dropping outputs to substitute values instantly.

6. Hardware vs Software Causes

The field report raises a valid point: replacing the CPU cleared the problem, but did the cause move with the CPU, or was it environment-related? The diagnostic answer rests on two questions:

1. Did the diagnostic buffer (on the failed CPU) show OB85/OB86 entries referencing a specific slot?
2. Did the new CPU exhibit the same STOP after the same operating hours, or is the new CPU still running clean after 30 days?

If the new CPU runs cleanly, the cause was internal to the original CPU: MMC wear-out, firmware checksum fault, retentive memory cell exhaustion, or aging electrolytics on the backplane connector. These faults are non-reproducible on a fresh CPU with a known-good MMC.

If the new CPU also enters STOP, the cause is environment: PS 305/PS 307 sagging under load, common-mode noise on the backplane, ground loops, or a marginal PROFINET/PROFIBUS device. Replace the original CPU first to keep the line running, then troubleshoot on the bench.

7. Bench Test Procedure for the Suspect CPU

Per the field-proven suggestion in the field report, a shop test of the removed CPU is the fastest path to a verdict. Use the following procedure:

1. Place the suspect CPU on a known-good rail with a known-good PS 307 (5 A or 10 A).
2. Insert the original MMC, or a freshly imaged MMC with the project's .s7p / .s7l blocks.
3. Toggle the mode selector to MRES for at least 3 seconds until the STOP LED blinks slowly, release, toggle once more within 3 seconds. The CPU performs a memory reset.
4. Toggle to RUN. If the CPU starts and runs OB1 with an empty program for 24–48 hours, the CPU is healthy. The issue was the project, the MMC, or the I/O.
5. If the CPU enters STOP during the empty OB1 run, the CPU is internally defective. Re-image the firmware via SIMATIC Automation Tool or STEP 7 to rule out a firmware issue; if the fault persists, scrap the CPU.
6. Load the original program and exercise the I/O on a simulator rack (SM 374 / dummy modules) to rule out field-side faults.

The empty OB1 test is the gold standard because it eliminates every user-written cause: no programming errors, no I/O access errors, no priority class errors. Any STOP during this test is conclusively an internal CPU fault.

8. MMC, Firmware, and Retentive Memory Considerations

For S7-300 CPUs with an MMC slot (CPU 312, 314, 315-2, 317-2, 319-3; the original CPU 312 IFM / 314 IFM had integrated memory and no MMC), the Micro Memory Card is a frequent STOP source:

• MMC read failure: Event ID 0x2x0F range. The CPU cannot load the user program and drops to STOP with the STOP and SF LEDs on, the MCE (Memory Card Error) LED may blink on older firmware.
• MMC write wear: SIMATIC MMCs have a finite write endurance. Using the MMC as a recipe storage area with frequent SFC 82 / SFC 84 writes (legacy) accelerates wear. Modern practice is to use recipes in the retentive load memory area, not the MMC.
• Firmware mismatch: A newer MMC written on a CPU with firmware V3.x may not run on a CPU at V2.x. Event ID 0x2x1F signals the incompatibility.
• Password-protected MMC: Forgetting the MMC password on a CPU 317/319 leaves the CPU in STOP with a "password error" diagnostic event. MRES does not clear the MMC password; only a PG with the password can unlock it.

To re-image the MMC, insert it into a PG with an external MMC reader, then use SIMATIC Manager > S7 Memory Card > Show Properties > Erase and Format (or the corresponding TIA Portal action) and reload the project.

9. Power Supply and Backplane Diagnostics

The S7-300 power supply module is often overlooked. Measure under load, not at idle.

Pull the backplane connector and inspect for greenish corrosion on the gold fingers. Re-seat every module. Confirm the shield bus is grounded at a single point per cabinet and the functional earth (FE) terminal on the PS is bonded to the cabinet PE bar.

10. Replacement vs Repair Decision Matrix

Use the following matrix to decide whether to scrap, repair, or keep the original CPU as a spare:

11. Verification Checklist After Repair

1. Power the rack, observe the LED sequence: all LEDs on briefly, then only RUN should be solid green within 10 seconds on a healthy CPU with a valid project.
2. Confirm SF, BF, FRCE, MAINT are off. The SD LED may be lit if the MMC is accessed (e.g., recipe write), but should be mostly off at steady state.
3. Force a restart from STEP 7 (CPU > Operating Mode > Complete Restart) and verify OB100 fires. Watch the diagnostic buffer for the restart entry.
4. Simulate a rack failure by removing a dummy module from a free slot; verify OB86 fires and the CPU does not STOP (assuming OB86 is loaded).
5. Monitor the diagnostic buffer for 72 hours; the buffer should be clean or contain only the routine restart entries.

12. Preventive Measures

• Load a minimal set of error OBs (OB82, OB85, OB86, OB100, OB121, OB122) in every project, even if empty.
• Keep the diagnostic buffer retention active; do not perform MRES as a recovery step without first exporting the buffer.
• Schedule the PS module for replacement every 8–10 years; electrolytic aging is the leading cause of brownouts on the backplane.
• Use original Siemens MMCs (6ES7 953-…) and avoid consumer-grade SD cards in industrial settings.
• Document the firmware version on every CPU and update SIMATIC Automation Tool inventory accordingly.

FAQ