Troubleshooting S7-400 CPU 414-5H Load Memory Sudden Increase

Troubleshooting S7-400 CPU 414-5H Load Memory Sudden Increase

During commissioning of a Biomass Plant running a SIMATIC S7-400H redundant controller, engineers reported that the load memory usage of a CPU 414-5H jumped from 42% to 67% within two days even though only minor online edits had been made (signal bypassing, a single "always open" contact, and online monitoring). Work memory (user memory) remained at 11%. A second, recurring fault was also reported: a momentary HMI pushbutton bit remained latched ON even though the physical switch and the logic were verified as non-latching. Both phenomena are characteristic of S7-400 behavior in RUN mode editing and HMI tag configuration, and both are resolvable without a full station stop.

1. S7-400 CPU 414-5H Memory Architecture

Before chasing the symptom, the engineer must understand how Siemens partitions memory in an S7-400 CPU. The three logical areas are independent and behave differently during online edits.

For the CPU 414-5H, typical sizing per the SIMATIC S7-400 Module Data manual is:

• Work memory, code: 4 MB
• Work memory, data: 4 MB
• Load memory: integrated RAM (~1 MB range, firmware-dependent) plus the plug-in memory card
• Bit memory (M): 8 KB (8192 flags)
• Process image: configurable, default 512 bytes inputs / 512 bytes outputs
• Number of process images: 8 (OB1, OB10, OB40, etc.)

The key engineering rule is: load memory holds every block version that has ever been downloaded until the CPU garbage-collects it. RAM-based load memory is a heap; a STOP-to-RUN transition or a manual "Compress" operation is what reclaims the dead blocks. FEPROM memory cards retain deleted versions until they are explicitly overwritten or reformatted.

2. Problem Statement: Load Memory Jumps from 42% to 67%

The reported symptoms were:

1. Day 1: Load memory = 42%, Work memory = 11% (baseline)
2. Day 2: Load memory = 67%, Work memory = 11% (no major edits, only online monitoring, signal bypass toggles, one new "always open" contact added in a downloaded FB)
3. Day 3: Load memory = 14% reported, but engineers interpreted the percentage as "14% used" not "14% free". The actual readout on the Memory tab is the used fraction.

Two facts pin the cause down:

• Work memory did not change. Work memory is where the active blocks live. If user code size had grown, the work-memory bar would have moved in lockstep. It did not.
• Load memory is the only area that grew. Load memory holds both the active and the previously active block images during a RUN-mode download.

This is the textbook fingerprint of an online edit performed in RUN without a subsequent compress or restart.

3. Root Cause: Online Block Download in RUN Mode

When STEP 7 / TIA Portal downloads a modified block to an S7-400 CPU in RUN mode, the CPU must guarantee rollback if the new block fails to initialize. It therefore writes the new block into a free area of load memory first, then atomically swaps the work-memory pointer. The old block image remains valid in load memory as a passive copy.

For each online modification (FB, FC, OB, DB), the load memory footprint grows by at least one extra block image. The S7-400 firmware will only reclaim that image on one of the following triggers:

1. STOP -> RUN transition (full restart or warm restart)
2. Manual Compress operation from STEP 7
3. MRES (memory reset) on the CPU
4. Firmware garbage collection when the load memory exceeds an internal watermark

A 25 percentage-point jump from 42% to 67% on a CPU 414-5H with 4 MB of work memory implies roughly 1 MB of new passive block images. That is consistent with two or three online edits of a moderately sized FB plus several DB regenerations that the engineer did not register as "edits" (for example, block-interface changes that force a re-download of every instance DB).

4. Diagnostic Procedure: Reading the Memory Tab

Before any remediation, capture the current state. The Memory tab is the authoritative readout.

1. In SIMATIC Manager, right-click the S7-400 station -> Online -> Module Information (or PLC -> Module Information in TIA Portal).
2. Open the Memory tab.
3. Record the following four values: Load memory RAM (used / total), Load memory FEPROM (used / total), Work memory Code (used / total), Work memory Data (used / total).
4. Switch to the Diagnostic Buffer tab and look for entries of class Module with text Download of block .... Each entry corresponds to one retained block image.

Sample values observed during this commissioning (illustrative, not actual device readings):

Confirm the diagnosis: if load memory grew while work memory did not, the growth is passive block images, not real program growth. Compression is the safe fix.

5. Resolution: Compress Load Memory on the S7-400

There are three accepted ways to reclaim the wasted load memory. Choose based on how disruptive a process interruption is acceptable.

5.1 Method A - Compress in STOP (cleanest)

1. Notify operations, place the unit in a safe state.
2. In SIMATIC Manager: Online -> CPU Operating Mode -> STOP.
3. Right-click the Blocks folder in the online view.
4. Choose Compress. The dialog shows the bytes that will be reclaimed.
5. Confirm with OK. Compression in STOP takes a few seconds for a 4 MB program.
6. Switch the CPU back to RUN via CPU Operating Mode -> RUN or RUN-P.

5.2 Method B - Compress in RUN (no process interruption)

STEP 7 / TIA Portal can perform a "compress in RUN" online. It is slower and slightly riskier than the STOP variant because the CPU is repacking live memory, but it does not interrupt the process.

1. Online -> Compress on the S7 program.
2. Accept the prompt "CPU will be in RUN during compression; this may take several minutes".
3. Monitor the Memory tab until the load memory percentage drops.

5.3 Method C - MRES (destructive)

Only for use when the program is fully backed up and reloadable. MRES wipes work memory and clears load memory; the S7-400 will then request a fresh download. This is the option of last resort during commissioning, not a routine fix.

6. Secondary Issue: A Bit Latches ON from an HMI Pushbutton

The commissioning team also reported a recurring bug: a momentary HMI pushbutton that should only stay TRUE for the duration of the press would latch TRUE indefinitely. They had observed the same symptom on three previous Siemens systems. There is always a deterministic cause, and on S7-300/400 it is almost always one of three things.

6.1 Candidate 1: HMI "Set Bit" vs "Set Bit in Tag"

This is the most common culprit. The HMI (WinCC flexible, TIA Portal HMI, or third-party) usually offers two button-event actions:

Open the HMI project, locate the button, and inspect the Events tab. If only a Press event is configured with a "Set Bit" action and no symmetric Release event with a "Reset Bit" action, the bit will stay latched the moment the connection is briefly dropped. This is the single most common Siemens "stuck bit" failure pattern in field service.

6.2 Candidate 2: Overlapping Memory Locations

If the bit sits inside a DB, it is possible that another block is writing the same byte, word, or double-word. The 414-5H will not flag this as an error because the access is legal; the second writer simply overwrites the first.

1. In SIMATIC Manager, right-click the suspected tag.
2. Choose Go To -> Location (or Cross-reference).
3. In the cross-reference window, check the Overlapping Access to Memory Areas checkbox.
4. STEP 7 will list every read or write that touches the byte, word, or double-word containing the bit. Any write that does not target the bit directly is suspect.

For example, if the tag is DB100.DBX0.3 and another block uses DB100.DBW0 or DB100.DBD0 as a status word, the bit will flicker or stick depending on what the other block writes.

6.3 Candidate 3: Process Image vs Periphery Access

On the S7-400H, multiple process images exist. The default process image is updated once per OB1 scan. If the bit is read from the periphery (PIB, PID, PIW, PID) instead of the process image (IB, ID, IW, ID), the update is only triggered when the address is explicitly accessed. In a redundant system where the OB1 schedule is short, the perceived behavior can look like a "stuck" bit.

Confirm in the hardware configuration (HW Config):

1. Open the S7-400 station in HW Config.
2. Select the digital input module.
3. In the Addresses tab, check the Process Image column. The module should be assigned to OB1 process image (PIP 1) or whichever OB the calling logic uses.
4. If the address is excluded from the process image, move the read to the process image or trigger an explicit UPI call.

7. Cross-Reference Workflow for the Stuck Bit

The definitive workflow for an S7-400 bit that appears to latch:

1. Capture the symptom with a VAT or HMI trend over at least 60 seconds.
2. Identify the absolute address: input (I), output (Q), flag (M), or DB tag.
3. If the address is an input:
   • Read the corresponding LED on the SM module.
   • With a meter, measure the field-side voltage at the channel terminal.
   • If the field-side voltage is correct but the LED or the input bit is wrong, the SM or wiring is the fault.
4. If the address is internal (M, DB), open the cross-reference and enable Overlapping Access to Memory Areas.
5. Verify the HMI event configuration: is there a symmetric Release event that resets the bit?
6. Trace the network online with a watch table; set breakpoints with Monitor/Modify to capture the exact cycle that flips the bit.

8. Compress Triggers and Edge Cases

A few field-observed edge cases that will save an engineer time during a Biomass Plant startup:

9. Verification Checklist

After applying the compression and addressing the stuck-bit root cause, the engineer should run the following checks before returning the system to operations:

1. Open Module Information -> Memory. Load memory < 50% and trending down or stable.
2. Open Diagnostic Buffer. No new "Download of block" entries without a paired compression.
3. Force a HMI button to momentary press 50 times in a loop; confirm the DB bit never latches.
4. Cycle power to the HMI panel. Confirm the bit does not stick on reconnect.
5. Run a 24-hour soak test. Confirm the load memory percentage does not drift upward by more than 1-2%.
6. Archive the project and the memory-card image per the plant's backup policy.

10. Frequently Asked Questions