Resolving Step 7 S7-400 CPU 416-3 DP Memory Full Download Errors

When SIMATIC Manager rejects a project download with a memory-full diagnostic on an S7-400 CPU 416-3 DP, the fault almost never originates from an undersized Memory Card (MMC). The cause is a load-memory region that has accumulated redundant block revisions, online-session stubs, or symbolic block fragments, combined with a work-memory ceiling that STEP 7 reports as a generic "insufficient memory" when the compiled block set exceeds the CPU's runtime code/data budget. This reference documents the S7-400 memory model, the diagnostic surfaces in STEP 7 V5.5 (and the TIA Portal migration path), the precise compression and download workflows, and the operating-mode dependency that restricts online monitoring of function blocks (FCs) to two concurrent blocks per programming device in process operation.

1. Problem Summary

A service engineer edits an S7-400 project offline in SIMATIC Manager, increments several FCs and DBs, and attempts to download the changes. STEP 7 returns a download dialog followed by an error such as:

Error downloading to the target system
Memory area for blocks is insufficient
-- or --
Internal error: Memory card write failed
-- or --
The system cannot perform the download. Free load memory: 0 bytes.

Three symptoms commonly accompany the message:

1. The Compress button in the download dialog does not free enough space; the same error recurs.
2. Direct download to the MMC succeeds, but a subsequent download to the CPU still fails because the CPU mirrors the MMC into internal RAM and the RAM mirror is also exhausted.
3. While online, opening a third FC for monitoring produces a notification: "You have already opened 2 FCs for monitoring. Close one FC to open another."

Each symptom maps to a distinct mechanism inside the S7-400 memory hierarchy. Resolving all three requires understanding which memory region is constrained and which tool-level operation reclaims it.

2. S7-400 Memory Architecture

The S7-400 separates executable and data areas into three regions. STEP 7 reports each region independently in Module Information (Ctrl+D on the CPU node in the project tree). The error message a user sees is the result of a region-specific violation, not a global "card too small" condition.

Download-to-target failures of the form "memory area for blocks is insufficient" are load-memory violations. STEP 7 compiles the offline project, computes the new block set, and compares the required bytes to the free bytes on the MMC and in the CPU's RAM mirror. If either ceiling is exceeded, the download is rejected before any block is written.

3. CPU 416-3 DP Hardware Reference

The CPU 416-3 DP family includes part numbers 6ES7416-3XL00-0AB0 (V3 firmware, smaller work memory), 6ES7416-3XR05-0AB0 (V5 firmware, 5.6 MB code + 5.6 MB data), and 6ES7416-3ES06-0AB0 (V6 firmware, same memory budget, additional diagnostics and security functions). The figures below apply to the V5/V6 hardware revisions; the V3 revision has a smaller work-memory budget and tighter online-monitoring limits, so the part number stamped on the front panel must be confirmed before applying them.

4. Root Cause Analysis

Five mechanisms consume load memory and trigger the download error. Identifying which one applies is the first diagnostic step.

4.1 Accumulated online session blocks

Each Download to target system operation writes a new timestamped block revision. STEP 7 does not delete the previous revision from the MMC until the next compression cycle. A project edited over many months can accumulate dozens of FC/DB revisions, each consuming load memory. The number of revisions is reported in Module Information → Memory → Number of fragments; a value above 50 indicates a heavily fragmented MMC.

4.2 Symbolic block stubs

Blocks written from STEP 7 include a symbolic interface description. If the project contains UDTs or symbol tables that have been edited offline but never recompiled, STEP 7 writes placeholder blocks whose symbolic information is inflated. Run Blocks → Check Block Consistency to detect and rebuild these stubs before download.

4.3 Comment and source blocks

The Download with comments option writes the entire comment database to the MMC. A large STEP 7 project with multilingual comment tables can consume several MB of load memory that the CPU never uses for execution. Disabling this option typically recovers 1–5 MB on a mid-size project.

4.4 Work-memory exhaustion disguised as a load-memory error

If the offline project compiles to a block set whose executed blocks exceed the work-memory code area, STEP 7 reports the error at download time even though the MMC has free load memory. The error wording is identical; the diagnostic is in Module Information → Memory → Work memory (code). Compare the used value against the 5.6 MB ceiling.

4.5 MMC fragmentation

Even when total free space on the MMC exceeds the new block set, fragmented free regions may be too small to hold a single large block. Compression is the only way to coalesce the free regions. The number of fragments is the key indicator; the trigger threshold is typically 5–10 fragments for a 4 MB project on a 64 MB MMC.

5. Diagnostic Procedure — Module Information

Open SIMATIC Manager, expand the project tree, right-click the CPU node, and select PLC → Module Information (or press Ctrl+D after selecting the CPU). The Memory tab reports the three regions independently.

1. Select the Memory tab. Note the values for Load memory (used / free on the MMC) and Work memory (code used / data used). The free-bytes value is the budget STEP 7 checks against the compiled block set.
2. Switch to the Performance tab. Note the values for CPU load due to communications and CPU load due to test functions. Values above 70% indicate the CPU is resource-constrained; the operating-mode switch in §8 will not fully recover monitoring capacity at that load.
3. Open the Diagnostic Buffer tab. Look for events of the form "Memory area for blocks exhausted" or "Work memory exceeded". The buffer preserves the exact event from the time of the failed download, including the timestamp and the affected block number.
4. Return to the project tree and select PLC → Accessible Nodes to enumerate all blocks currently loaded on the CPU. Compare against the offline project. Blocks present online but missing offline are candidate garbage blocks (§10).
5. Open the Stacks tab. A BSTACK or USTACK entry referenced by the diagnostic buffer confirms whether the failed download left the OB1 cycle in a recoverable state.

6. Memory Compression Workflow

Compression is a CPU-side operation. It writes the current active block set contiguously to the MMC and discards the free-space gaps. The procedure:

1. Establish an online connection to the CPU (PLC → Connect to Target System).
2. Place the CPU in STOP. Compression requires the CPU to be stopped; the operation is invasive and resets process outputs to their configured substitute values. Confirm the plant is in a safe state.
3. Open PLC → Compress (User Memory) from the SIMATIC Manager menu. A progress dialog reports the new contiguous block set.
4. Wait for completion (typically 30–120 s for a fully populated 64 MB MMC). The CPU remains in STOP throughout.
5. Re-open Module Information and verify that Load memory free has increased and that Number of fragments has dropped to 1.
6. Switch the CPU back to RUN only after the verification step confirms recovery.

Compression does not delete user blocks. It removes only the free-space gaps and the diagnostic buffer. If a block is missing from the offline project but present on the CPU, it survives compression and remains a candidate for the §10 cleanup procedure.

7. Memory Card Direct Download Procedure

When load memory is so fragmented that even a complete reload cannot find a contiguous slot, the standard recovery path is to download the project directly to the MMC. The MMC can be programmed in the programming device's Prommer (an external MMC reader/writer) or, on later CPUs, via PLC → Download to Memory Card in SIMATIC Manager.

1. Insert the MMC into the programming device's Prommer (e.g. Field PG with internal Prommer, or external USB Prommer for S7-400 MMCs).
2. In SIMATIC Manager, select the S7-400 station, right-click the CPU, and choose PLC → Download to Memory Card.
3. Select the target Prommer slot and confirm. STEP 7 writes the active offline project, including all SDBs from HW Config, directly to the MMC.
4. Insert the MMC into the CPU slot. Power-cycle the CPU. The CPU reads the MMC, populates the RAM mirror, and transitions to RUN if the project is consistent.
5. Verify the download by opening Module Information → Memory from the online connection.

8. Online Monitoring Limits — Test vs Process Operation

The "2 FCs only" limit observed in the field report is a CPU-side constraint that depends on the operating mode and on the test-function load it implies. The CPU 416-3 DP allocates monitoring resources based on the active operating mode:

In process operation the CPU does not reserve monitoring resources because it cannot guarantee deterministic execution while servicing test queries on every OB1 cycle. STEP 7 enforces a two-block cap as a safety net; lifting the cap requires the operator to switch the mode selector to RUN-P, which authorizes the CPU to spend cycles on test queries. The cap is a software discipline, not a hardware ceiling — the CPU 416-3 DP can service more queries if test operation is enabled.

If the same PG sees only 2 FCs and a second PG connected to the same CPU sees 8, the first PG is in process operation and the second is in test operation. The constraint is per PG-session, not global to the CPU. The CPU itself is not resource-constrained in the way the symptom suggests; the operating-mode discipline is the gating factor.

9. Multi-PG Session Behavior

The CPU 416-3 DP supports up to 64 online connections in parallel, but test-function resources are partitioned. Each PG in test operation consumes a slice of the test-function budget; once the budget is exhausted, additional PGs fall back to process-operation monitoring (2-block cap). The same mechanism explains why one PG can open 8 FCs and another opens 2 — the second PG is a fallback participant with process-operation semantics.

The recovery path:

1. Identify all PGs currently connected (PLC → Accessible Nodes from a third PG, or check the Connections tab in Module Information).
2. Disconnect PG sessions that are not actively monitoring (PLC → Disconnect). Each released connection returns its test-function budget to the pool.
3. Reconnect the remaining PGs in test operation (mode selector RUN-P). All PGs should now report the same monitoring capacity.

If only a single PG is connected and the cap persists, the mode selector on the CPU is the gating factor. Confirm the selector is in RUN-P, not RUN. The difference is mechanical: the key switch on the front of the CPU 416-3 DP has three positions (RUN, RUN-P, STOP). RUN-P is required to authorize test functions, and there is no software menu to override the key-switch position.

10. Block Cleanup Without Deleting User Logic

The field report raises the question of how to recover load memory without deleting user blocks. The answer is a tiered cleanup that targets only the waste STEP 7 generates, not the executable logic.

10.1 Delete garbage blocks

Blocks that exist on the CPU but not in the offline project are "garbage" — they consume load memory and work memory but contribute nothing to execution. To list and delete them:

1. Open PLC → Accessible Nodes.
2. Expand the CPU node and compare the online block list to the offline project blocks (right-click → Compare).
3. Mark blocks that are "online only" — these are candidates for deletion.
4. Right-click each candidate and select Delete. STEP 7 confirms the block is unused before deletion; if any FC, FB, or DB is referenced by an active block, the deletion is rejected.
5. Run PLC → Compress (User Memory) after deletion to coalesce the freed space.

10.2 Strip comment and source blocks

Disable Download with comments in Options → Block Check Consistency. Re-download. The MMC footprint drops by the size of the comment database, typically 1–5 MB on a large project.

10.3 Archive and re-create the offline project

If compression and garbage-block deletion are insufficient, archive the offline project (File → Archive) and then re-create the project from the archive. This rebuilds the STEP 7 project database and removes the offline-side bloat that compression cannot address (revisions kept for the version-history view, orphaned SDBs, etc.).

10.4 Use Monitor/Modify Variables instead of opening more FCs

If the goal is to inspect runtime values, opening a fourth FC is rarely the right tool. PLC → Monitor/Modify Variables (or the VAT table view) lets you read and write arbitrary tags in the CPU without consuming a monitored-block slot. This is the recommended substitute when the mode selector cannot be moved to RUN-P (e.g. on a machine that must remain in process operation for safety reasons).

11. Operating-Mode Verification and Resource Check

Before commissioning, run a resource audit from Module Information:

1. Open the Performance tab. Confirm CPU load due to test functions is < 50% in the worst case. Above 50%, test functions risk impacting the OB1 cycle time, and the CPU may throttle additional monitoring requests.
2. Open the Memory tab. Confirm Load memory free is at least 20% of the MMC capacity. Below 20% the next incremental download is likely to require compression.
3. Open the Diagnostic Buffer. Confirm no entries of the form "Work memory exceeded" or "Memory area for blocks exhausted" in the last 24 hours.
4. Switch the CPU to RUN-P. Open a third FC for monitoring. If the third FC opens without the "close one FC" notification, the operating mode and resource budget are healthy.

12. Recovery Procedure — Decision Flow

13. Field-Proven Procedure Summary

Use the following sequence to recover a CPU 416-3 DP that is rejecting downloads with a memory-full error:

1. Connect online, switch to STOP, run PLC → Compress (User Memory). Retry the download.
2. If the download still fails, identify and delete garbage blocks via Accessible Nodes. Re-run compression. Retry.
3. If the download still fails, disable Download with comments in Options. Retry.
4. If the download still fails, archive the offline project and re-create from archive. Retry.
5. If the download still fails, download directly to the MMC (§7). Power-cycle the CPU. Reconnect online and verify with Module Information.
6. Address the "2 FCs only" monitoring symptom by switching the CPU mode selector to RUN-P and disconnecting idle PGs.
7. Document the final memory state in Module Information for the next service event.

14. Frequently Asked Questions