S7-400H CPU 417H Load Memory Filling After Online Modifications

Overview

The SIMATIC S7-400H CPU 417H (order number 6ES7417-4HT14-0AB0 and predecessors) is the high-availability redundant controller used in critical process applications. A recurrent field issue on long-running commissioning campaigns is that the load memory (the area holding all block types, comments, symbols and system data) grows by 10–20 % per online modification until a download is no longer accepted and the engineering station (ES) can no longer reach the controller. The work memory and code footprint typically grow by less than 0.5 % per change, which proves the growth is in load-memory housekeeping, not in logic. This article details the architecture, root cause, the limits of the manual and SFC 25 (COMPRESS) approach, the FEPROM vs RAM card decision, and a deterministic procedure that keeps a CPU 417H pair online across many online modifications.

S7-400H CPU 417H Memory Architecture

Understanding the four memory areas is essential before diagnosing load-memory growth. The CPU 417H separates them strictly:

The load-memory card is a separate physical module (MMC predecessor — actually called memory card in the S7-400 family, since it is a 72-pin SIMATIC memory card, not the MMC used in S7-300/1200/1500). Two card types are available:

• FEPROM (Flash-EPROM) — non-volatile, retainable, slower write cycles (~100 000 per block guaranteed). Used when a permanent record of the program is required.
• RAM card — battery-backed, unlimited write cycles, faster. Used for high-flux development and online modification.

During every Download or Online → Download to target device, STEP 7 writes the new block to the load memory of the active CPU; the previous active version is retained as a passive block to support online modification tracking. Each modification therefore leaves a residue in the load memory until compression consolidates the layout.

Problem: Load Memory Filling After Online Modifications

Symptom pattern reported in the field and reproduced in the Siemens support database:

1. Initial cold download on a CPU 417H with a 16 MB FEPROM card populates load memory to roughly 30–40 %.
2. After 3–5 online modifications (logic tweaks, comment edits, symbol additions) the load memory rises to 60–80 %.
3. After 10–15 modifications the load memory reaches 95–99 % and STEP 7 reports: “Insufficient memory in the CPU”, “Online: download not possible”, or the PLC is no longer reachable through the routing node.
4. Manual Compress via PLC → Module Information → Memory → Compress releases only ~30 % of the growth (compression is rarely 100 % efficient while the CPU is in RUN).
5. After 3–4 days of heavy commissioning, the CPU is forced into STOP; a full reset (MRES) and complete reload is the only way to recover.

Work memory and code size barely move, which proves the growth is fragmentation and passive-block retention in load memory, not logic growth.

Root Cause Analysis

Three architectural behaviours combine to produce the symptom:

1. Passive block retention. Every online modification (block type, instance DB, SDB, SFC, SFB, F-block) is written as a new version in load memory. The old version is marked as passive, not deleted. This is intentional — it allows online delta downloads and view of historic versions — but it consumes load memory until a Compress consolidates the area.
2. Compression requires STOP or undisturbed RUN. The SFC 25 “COMPRESS” function and the equivalent Compress dialog in STEP 7 only achieve full compaction if the user program is not actively writing to the same area. With monitoring blocks, forces, VATs and HMI variable polling active, compression recovers roughly 2/3 of the fragmented space, not 100 %.
3. Active monitoring tools block the cleanup. STEP 7 explicitly refuses to compress when monitoring functions (monitoring blocks, force table, VAT) are open and bound to the CPU. This is documented in the S7-400 system manual, chapter Load memory / Compress.

The combination of (1) residue accumulation, (2) partial compression, and (3) monitoring blocking full compression explains the 10–20 % per modification growth pattern. A FEPROM card cannot be defragmented in place — the card must be read completely, compressed in the ES, and re-flashed, or compressed inside the CPU if it has enough free space to absorb the temporary duplicate.

Compression Limits on the CPU 417H

The CPU 417H supports compression through two paths:

The CPU 417H hardware supports compression in RUN, but only up to a point. The 16 MB FEPROM card has the smallest free-area margin of the supported card sizes; if load memory is above ~85 % occupied, the compression routine may not be able to create the temporary duplicate layout it needs and the call is rejected with RET_VAL = 80A1 (resource problem) or RET_VAL = 80B1 (insufficient load memory). The Siemens manual for SFC 25 lists these error codes in the standard SFCs reference.

FEPROM vs RAM Memory Card Decision

The card type directly drives the growth pattern. The selection rule for a CPU 417H in heavy online-modification phases is unambiguous:

The flash write cycle limit on a 16 MB FEPROM card is on the order of 100 000 erasures per sector, which is generally more than enough for a plant’s life cycle, but during a 3-day commissioning window the CPU may receive 20–40 modifications/day, each of which writes a new block. The flash wear is not the failure mode; the failure mode is the load-memory fragmentation that the FEPROM card cannot defragment without a complete read/rewrite. A RAM card lets SFC 25 actually move blocks around in place.

STEP 7 Procedure: Force a Full Compression

1. Save the project on the ES.
2. Close all monitoring windows in STEP 7 (block view, watch tables, force tables). The CPU will not accept a full compression while ES sessions hold block handles.
3. Disconnect any HMI/SCADA tag polling that opens VAT-equivalent handles (WinCC, FactoryTalk, PCS 7 OS — pause the OS server or set the OS to Process mode offline).
4. In SIMATIC Manager / TIA Portal, right-click the CPU → Target system → Memory → Compress.
5. Confirm the prompt. The CPU will briefly enter a state where online access is paused (typically 5–30 seconds on a CPU 417H, depending on project size and fragmentation).
6. After the dialog reports success, open Module Information → Memory and confirm the load-memory free area has increased.

If the dialog returns “Compress not possible” it is almost always because a monitoring connection is still open. Re-check that no ES, no OS server, and no ProTool/ProAgent session holds an active online handle to the CPU.

SFC 25 (COMPRESS) in the User Program

For redundant CPU 417H pairs you can call SFC 25 from a time-of-day or cyclic OB to compress load memory without engineering intervention. Sample structured text:

// OB35, cyclic 1 s, CPU 417H primary
// SFC 25 "COMPRESS" — consolidate user program in load memory
// Trigger window: between 02:00 and 02:05 every Sunday, low-activity time

IF (DTC_HH >= 2) AND (DTC_HH < 3) AND (DTC_WEEKDAY = 0) THEN
    // Close monitoring/force sessions before the call is effective
    // (engineering must close the ES side)
    iRetVal := COMPRESS();   // SFC 25 call, no inputs

    IF (iRetVal <> 0) THEN
        // RET_VAL <> 0 indicates a problem — push to log DB
        iCompressError := iRetVal;
        bCompressFailed := TRUE;
    ELSE
        bCompressOK := TRUE;
    END_IF;
END_IF;

Common SFC 25 RET_VAL codes relevant to the CPU 417H:

The SFC 25 reference page in the STEP 7 V5.x standard SFCs manual gives the full set; the values above are the subset you will hit in this scenario.

Procedure: Replace FEPROM with RAM Card for Commissioning

1. Bring the CPU 417H to STOP via the mode switch or PLC → Stop in STEP 7. In an H-system, switch both H-CPUs to STOP; the process is interrupted.
2. Remove the FEPROM card from the active CPU. The plug is on the front, behind a small cover.
3. Insert a battery-backed RAM card of the same size or larger (16 MB, 32 MB, or 64 MB). Verify the battery LED.
4. Power on the CPU; if the program is still on the FEPROM card, copy RAM ← FEPROM via PLC → Copy RAM to ROM in the opposite direction (now RAM card is destination).
5. Switch back to RUN.
6. Test SFC 25 — it should now fully compact on each call.

Procedure: Online Modification Best Practice

Adopt these rules to keep the load memory from growing between scheduled compressions:

1. Batch modifications. Accumulate logic changes for an hour, then download once. Ten small downloads create ten times the residue of one batched download.
2. Avoid changing comments and symbols online. Comment and symbol changes still write new block versions. If you must change a comment, do it in the project offline and reschedule the next download window.
3. Delete unused blocks. Use Options → Block consistency check to identify blocks with no reference. Delete them in the offline project, then download the entire container.
4. Schedule a nightly compress. If the process is hot and cannot tolerate a STOP, call SFC 25 in a low-traffic time-of-day window. The compression is partial but it caps growth.
5. Cap the SDB count. Each H-station configuration and each CP generates SDBs. Verify the SDB count with Module Information → Communication after each hardware change. Orphaned SDBs from removed stations are a common hidden load-memory consumer.
6. Keep monitoring sessions short. When a commissioning engineer finishes a debug session, fully close the online window. Each open block view holds a memory handle that blocks compression.

Verification: Confirm Load Memory Health

After any intervention, verify the load memory state in PLC → Module Information → Memory:

Run Module Information → Diagnostic Buffer and look for events “Load memory compressed”, “Insufficient load memory”, or “Online: download rejected”. The timestamps of these events let you correlate the growth with a specific change window.

Redundancy Considerations for the S7-400H Pair

On an H-system, both CPUs share the role of master and reserve. The load-memory growth pattern occurs on both because both receive the same online modification through the redundant link. The relevant behaviours:

• Online download to a redundant pair is performed on the master; the reserve CPU is updated through the redundant link automatically.
• SFC 25 must be called on both CPUs to be fully effective, or you can call it only on the master and trigger the reserve to update with SFC 90 (H_CTRL) parameter “reserve role” handling. Most implementations call SFC 25 in OB1 on each CPU independently.
• If the master fills and the reserve has more free space, link-up is not blocked, but a master-failover will not give you extra headroom — the reserve has the same fragmented layout.
• For H-systems, Siemens recommends both CPUs be equipped with the same memory card type and size. Mismatched cards will fail redundancy check during startup.

Troubleshooting Matrix

Preventive Maintenance Schedule

Embed these checks in the plant maintenance plan for any S7-400H fleet:

1. Daily: HMI/SCADA panel showing load memory %; alarm at 70 %.
2. Weekly: Review Module Information → Diagnostic Buffer on both H-CPUs for “Insufficient load memory” events.
3. Monthly: Run a manual compress from STEP 7 in a planned low-load window.
4. Quarterly: Verify both CPUs have the same card type and size; verify the battery LED (RAM card) is green.
5. Per major project change: After a large online modification (>50 blocks), stop the CPU, swap to a RAM card if the project is not yet signed off, run SFC 25, swap back to FEPROM at project sign-off.
6. Annually: Replace the RAM-card backup battery (typical life 2–3 years, replace preventively).

References for Further Engineering Use

Authoritative sources for the procedures and error codes above are the Siemens SIMATIC S7-400H system manual, the CPU 417H device manual, and the STEP 7 V5.x standard SFCs reference. Use the Siemens Industry Online Support portal to retrieve the latest revisions of each document for the firmware version installed in your fleet:

• Siemens Industry Online Support — entry point for SIMATIC S7-400H manuals, FAQs and firmware downloads.
• SIMATIC S7-400H Fault-Tolerant Systems manual (entry 1116940) — covers the H-system startup, link-up, and memory-card handling.
• SIMATIC S7-400 CPU 417H device manual (entry 18652677) — load memory sizes, FEPROM/RAM card ordering data, and battery behaviour.
• SIMATIC S7-400 System Manual (entry 18627128) — load memory, compression routine, and the “Insufficient load memory” diagnostic event.
• STEP 7 V5.x Standard SFCs reference (entry 109751826) — SFC 25 “COMPRESS” interface, RET_VAL codes, and execution preconditions.

Verify the firmware release notes for your specific CPU 417H variant (e.g. 6ES7417-4HT14-0AB0) before relying on a RET_VAL mapping; Siemens occasionally revises error code semantics in major firmware updates (V4.x, V5.x, V6.x lines of the CPU 417H firmware).