S7-300 Diagnostic Buffer Resolving CPU Errors After Program

S7-300 Diagnostic Buffer: Resolving CPU Errors After Program Download

When an engineer transfers a STEP 7 project to a SIMATIC S7-300 CPU, two questions immediately surface: why does the online block list contain objects that do not exist in the offline program, and how is the red CPU fault indicator interpreted? Both questions are answered by understanding the S7-300 memory model and the integrated diagnostic buffer. This reference consolidates the field procedures, block taxonomy, and error codes that engineers encounter the first time they commission a download to an S7-300 CPU such as the CPU 315-2 PN/DP or CPU 317-2.

Overview of the S7-300 Download and Online Block Model

The S7-300 separates program storage into three physical regions: load memory (typically the MMC card or, on older CPUs, integrated RAM), work memory (volatile RAM executing the cyclic OB1), and system memory (timer, counter, bit, I/O, and local stack areas). The online view in STEP 7 V5.x or the TIA Portal reflects what is currently stored in load memory, not the offline source on the programming device. After a successful Download to Target System (Station), the online block tree therefore shows three categories of blocks:

• User blocks: OB, FB, FC, DB that exist in the offline project and were just downloaded.
• System blocks: SFB, SFC, SDB that the firmware generates or instantiates during hardware compilation.
• Residual blocks: older FB/FC/DB instances from a previous project that were not deleted from load memory before the new download.

Identifying the CPU Error: The SF LED and Diagnostic Buffer

The S7-300 has two diagnostic front-panel indicators that matter during commissioning: SF (group fault, red) and BF (bus fault, red). The SF LED is generic; it does not specify the cause. To identify the precise fault class, fault code, and timestamp, the engineer must open the diagnostic buffer.

The diagnostic buffer is a ring buffer of the last 100 fault and operating events held in non-volatile memory on the MMC. Each entry contains:

• Sequential event ID.
• Timestamp (CPU date/time, to millisecond resolution).
• Event class: 1 = standard OB / startup, 2 = synchronous error, 3 = asynchronous error, 4 = stop event, 5 = mode change, 6 = communication, 7 = H/F/F-I/O fault, 8 = diagnostic for module, 9 = standard OB event, A = user-defined.
• Fault code (hexadecimal).
• Block and address context where the fault was raised.

Opening the Diagnostic Buffer in STEP 7 V5.x

1. Select the S7-300 station in SIMATIC Manager.
2. Right-click the target CPU and choose Online > Accessible Nodes if the online partner is not already defined.
3. Establish an online connection (MPI/PROFIBUS or Ethernet via TCP/IP).
4. Highlight the CPU online object.
5. Press Ctrl+D, or use the menu PLC > Diagnostic/Setting > Diagnostic Buffer.
6. Click the most recent entry to expand the additional details (associated OB, fault location, register states).
7. Click Open Block to jump directly into the offline block that raised the fault.

In TIA Portal, the equivalent path is Online > Diagnostics > Diagnostic Buffer after expanding the device tree under Online > Accessible Devices.

Common CPU Errors Reported After Program Download

The first diagnostic entries after a download typically fall into one of the following categories. Each fault code maps to a single root cause that must be corrected before the CPU can return to RUN.

System Blocks (SFB, SFC, SDB): What They Are and Why They Appear

The S7-300 firmware provides a library of pre-implemented blocks that are integrated into the operating system. They are not loaded from the engineering station during download; instead, they are generated automatically when STEP 7 compiles the hardware configuration (HW Config) and writes the corresponding system data blocks.

System Functions (SFC)

SFCs are operating-system functions callable from the user program. They execute firmware-level tasks such as time-of-day handling, copy operations, and rack diagnostics. Examples include:

System Function Blocks (SFB)

SFBs are operating-system function blocks that retain their instance DB across cycles. They implement complex services that require state memory:

The exact set of SFBs depends on the CPU firmware version. A CPU 315-2 (6ES7 315-2EH14) exposes a larger SFB set than a CPU 312 (6ES7 312-1AE14). Reference the CPU 31xC and CPU 31x operating instructions for the exact list per order number.

System Data Blocks (SDB)

SDBs are generated when the hardware configuration is compiled. Each SDB describes one logical component of the configuration: rack assignment, module parameters, PROFIBUS/PROFINET topology, S7 connections, and global data definitions. Common SDB numbers include:

• SDB 0 – CPU parameters (priority, watchdog, clock).
• SDB 1000+ – Per-module parameter records.
• SDB 2000+ – PROFIBUS DP master / slave configuration.
• SDB 3000+ – PROFINET IO device assignment.
• SDB 4000+ – S7 connection definitions (PUT/GET, ISO-on-TCP).

When the online view lists SDBs that the offline project does not show explicitly, this is normal: SDBs are an artifact of compilation and reside only in load memory.

Why Extra User Blocks Appear Online

Beyond the firmware-generated system blocks, a download may also reveal previously downloaded user FB, FC, and DB blocks that the current offline project no longer contains. Three mechanisms produce this state:

1. Incomplete overwrite: STEP 7 deletes blocks from load memory only when the Delete checkbox is set in the download dialog. A plain download re-loads blocks present in the offline tree but leaves orphan blocks intact.
2. Block number reuse: An FB or FC was removed from the offline tree, but a download left the previous version resident. Loading only the active blocks will not overwrite deleted blocks.
3. Forgotten instances: Instance DBs from previous FB versions persist because they were never explicitly deleted; renaming an FB does not garbage-collect the old instance.

Housekeeping Procedure Before a Download

1. Right-click the S7-300 station and choose PLC > Download User Program to Memory Card with the Replace MMC contents option. This wipes the entire load memory and writes only the current project.
2. Alternatively, in the download dialog, enable Overwrite all blocks and confirm deletion of unmatched blocks.
3. After the download, perform PLC > Compare Blocks to verify online/offline equivalence.

Load Memory, Work Memory, and the MMC

For S7-300 CPUs, the load memory is implemented on the SIMATIC Micro Memory Card (MMC). Work memory is integrated RAM sized per CPU order number; it is not expandable. When a project is downloaded, the SFCs SFC 83 / 84 / 85 (READ_DBL, WRIT_DBL) may be used by the firmware to copy from load memory to work memory. The user program always executes from work memory; load memory holds the project source.

Step-by-Step: Diagnosing and Clearing CPU Errors After Download

1. Establish online connection. Open SIMATIC Manager (STEP 7 V5.x) or TIA Portal. Use Online > Accessible Nodes and identify the CPU by IP/MPI address.
2. Read the diagnostic buffer. Press Ctrl+D with the CPU selected. Sort entries by ID descending.
3. Identify the most recent STOP event. Click the entry; the right pane will list the event class (typically 1 to 4), fault code, and block context.
4. Open the offending block. Click Open Block from the diagnostic buffer toolbar; STEP 7 opens the offline block and jumps to the network/line.
5. Cross-reference. Right-click the symbol or block number and choose Go To > Cross-Reference to identify callers.
6. Resolve the fault. Typical corrections include adding missing OBs (OB82, OB86, OB121), correcting DB number conflicts, fixing indirect addressing, or repairing PROFIBUS/PROFINET wiring.
7. Recompile. Station > Consistency Check then Save and Compile. Correct any SDB generation errors flagged by the compiler.
8. Re-download. Use the full Download to Target System. Confirm the dialog lists all expected blocks.
9. Switch to RUN. From the CPU online view, click RUN or use the mode selector on the front panel.
10. Verify. Observe the SF LED is off; check the diagnostic buffer again for new entries; confirm RUN state in the operating mode field.

Verification Checklist

Troubleshooting Matrix

Cross-Platform Notes

The block taxonomy discussed here is specific to the SIMATIC S7-300 family. For S7-1200 and S7-1500, the equivalent system blocks are accessible through the TIA Portal libraries and use FB/FC prefixes within the "System" directory; the conceptual model is the same but the firmware integration is tighter and the diagnostic buffer is accessed through Online > Diagnostics > Diagnostic Buffer on the device view.

For PLCs from other manufacturers, the same logical separation applies. Automation Direct CLICK series PLCs, for example, do not expose a diagnostic buffer of the S7 style; program downloads are managed through the CLICK programming software and the editing environment provides a compile log instead. Reference the Automation Direct CLICK software documentation for the equivalent transfer workflow on that platform.

Safety and Operational Considerations

During commissioning, a CPU in STOP removes process control. If the controlled equipment has no hard-wired safety path, an unexpected STOP after download can drive the process to a hazardous state. Best practice on first-time download:

• Bring the process to a safe state before initiating download.
• Verify mode selector is at STOP or RUN-P.
• Ensure OB82, OB86, OB121 are present so that single I/O faults do not drive STOP.
• Use a CPU with RUN-P capability to allow online edit while in RUN.
• After download, observe the SF LED and the diagnostic buffer for at least one full cycle before resuming normal operation.

Frequently Asked Questions