S7-314C-2PTP Work Memory Full: Adding Modbus TCP Blocks Fix

Problem Overview

An S7-314C-2 PTP CPU reports "Work memory full — Do you want to compress?" the moment the engineer drags a Siemens Modbus/TCP block library onto the project and attempts download. STEP 7 / SIMATIC Manager then refuses the partial download with a second dialog: "Unable to download all blocks." The configuration that produces the symptom is the same configuration that recurs in almost every brownfield S7-300 migration to Modbus TCP:

• CPU type: S7-314C-2 PTP (compact CPU with on-board serial interface), MLFB family 6ES7 314-6BGxx / 6ES7 314-6BHxx.
• Installed work memory (loadable program + data): 96 kB.
• Existing user program footprint: ≈91 kB of work memory (~95 % utilisation — the user cannot shrink it because the program was authored by a third party and the plant owner will not authorise code changes).
• Modbus TCP add-on library (FB65/FB66/UDT/UDF blocks plus instance DBs for the CP-343-1 Lean): ≈35 kB additional work memory.
• CP-343-1 Lean (6GK7 343-1CX10-0XE0) already present and licensed for Modbus TCP PN CPU.
• One HMI connected via MPI on the same segment.

Net required work memory ≈ 91 + 35 = 126 kB. Net available work memory = 96 kB. Deficit = ≈30 kB. The CPU simply cannot hold the augmented program.

Root Cause: Work Memory vs. Load Memory

The most common misconception in this scenario is that the Micro Memory Card (MMC) determines program capacity. It does not. The CPU has three separate memory regions:

For the S7-300 family the partitioning between load and work memory is a hardware characteristic of the CPU — not a setting, not a parameter, not something a firmware upgrade alters. Swapping an MMC from 512 kB to 4 MB enlarges the offline storage and the source archive, but the integrated RAM that holds the running program stays exactly the same 96 kB.

This is why the engineer's first instinct ("replace the 512 kB MMC with a 1 MB MMC") is technically wrong: load-memory usage in the example was only 22 %, and even at 100 % load-memory fill the integrated work memory remains 96 kB. The download still fails.

Modbus TCP Block Footprint on CP-343-1 Lean

The "35 kB of add-on blocks" seen in the dialog is dominated by the SIMATIC Modbus/TCP PN CPU library and the connection / instance data blocks generated when the CP-343-1 Lean is parameterised:

The exact cost varies with STEP 7 version (V5.4 SP5 vs. SP6+), library patch level, and number of simultaneous partners. The 35 kB figure reported by the engineer is consistent with two simultaneous Modbus partners, four connection DBs, and a recent SIMATIC Modbus/TCP PN CPU library.

Solution 1 — Upgrade the S7-314C-2 PTP In-Place to a Higher-Memory Variant

This is the lowest-risk, lowest-cost fix because the replacement CPU is pin-compatible, program-compatible, and retains both on-board serial interfaces (PtP and MPI/PROFIBUS-DP) so the wiring, MPI HMI, and serial devices do not have to move.

The firmware generation also moves forward from V2.x to V3.3, which is itself a benefit: V3.x firmware supports the latest Modbus/TCP PN CPU library without the secondary "ob77 / ob82 trigger" workarounds required on V2.6 firmware.

Migration procedure:

1. Document the existing hardware configuration from HW Config (rack, slot, all module order numbers, I/O addresses, diagnostic addresses, CP-343-1 Lean IP/subnet, CP firmware version, CP order number 6GK7 343-1CX10-0XE0 vs. -0EX30 — they share the same Modbus TCP license).
2. Do an offline archive of the S7-300 project (File → Archive → User-defined archive) plus an online backup (PLC → Upload Station to PG). Both copies become the rollback artefacts.
3. Insert the new CPU into the rack. Power down, swap, power up. The CPU will report "STOP — no MMC inserted" until you transfer the card.
4. Update the HW Config of the offline project to the new order number (6ES7 314-6BH04-0AB0). The slot, I/O addresses, diagnostic addresses, CP, and PROFIBUS/MPI parameters stay identical — STEP 7 will reassign the same addresses because the symbol table drives the assignment.
5. Compile HW Config, then download the entire station (target system → "Download to Target Device → Entire Station" with "Replace object during download" enabled). This pushes the new CPU identity, the augmented block library, and the Modbus connection DBs in one pass.
6. Transfer the licence key for "Modbus TCP PN CPU" to the new CPU's MMC via S7-PCT, Automation License Manager, or the license tool inside SIMATIC Manager.
7. Run a CPU memory diagnostic: PLC → Module Information → Memory should now report ≈126 kB used / 192 kB total work memory, ≈66 % utilisation.
8. Cold-restart the CPU and verify the Modbus TCP connection via the CP-343-1 Lean diagnostic page.

Solution 2 — Add a Companion S7-315-2 DP/PN as a Gateway

If the plant owner will not entertain even a same-footprint CPU change, the engineer can introduce a separate S7-315-2 DP / PN that hosts the Modbus TCP program, with the existing S7-314C-2 PTP acting only as an "interfacing module" that mirrors inputs to the new CPU and re-emits outputs back to the field. The two CPUs exchange data over MPI or PROFIBUS using global data (GD) or configured PUT/GET (S7 communication) on ISO-on-TCP.

Working example of a PUT block on the new S7-315-2 that pulls 32 bytes of input status from the old S7-314C-2 PTP every scan (illustrative — adapt the ID / pointers to your project):

// FB14 "PUT" — read input image from old CPU into DB100 on new CPU
CALL  FB14 , DB14
REQ    := TRUE                       // pulse-driven from OB35
ID     := W#16#0001                   // connection ID (matches NetPro)
DONE   := M10.0
ERROR  := M10.1
STATUS := MW12
ADDR_1 := P#E0.0 BYTE 32             // source area in old CPU
SD_1   := P#DB100.DBX0.0 BYTE 32     // target area in new CPU
LEN    := 32

Mirror logic in the old CPU writes the result to its outputs via FB15 "GET" (single-sided fetch). The cycle-time penalty for a 32-byte GD circle on MPI at 187.5 kbit/s is typically 30–60 ms per direction.

Solution 3 — Off-Load Modbus TCP to a Standalone Gateway

If neither CPU swap nor companion CPU is acceptable, the Modbus TCP engine can be moved off the S7-300 entirely onto a Siemens PN/MODBUS gateway (e.g. 6BK1700-0BA20-0AA0 Modbus/TCP → Modbus RTU/ASCII gateway, or the IE/PB Link PN IO with Modbus master capability). The gateway is configured in primary-setup-tool-style wizards, sits on the same PROFINET segment as the CP-343-1 Lean (or replaces the CP altogether if the plant elects to talk Modbus TCP directly to the gateway and let the gateway proxy Modbus RTU over an on-board serial port back into the S7-314C-2 PTP via its PtP interface).

This route preserves the S7-314C-2 PTP completely. It costs less hardware than a second CPU but introduces a third-party gateway whose lifecycle, security patches, and DCS-side diagnostic integration sit outside the SIMATIC world. For most brownfield plants this is acceptable; for sites under ISA-99 / IEC 62443 audit, the gateway must be documented in the cyber-security zone model.

Step-by-Step Verification After Upgrade

1. Open PLC → Module Information → Memory on the new CPU. Confirm used work memory is now ≤ 65 % of the new total.
2. Open PLC → Module Information → Diagnostic Buffer. Confirm clean cold-restart, no OB121 / OB122 programming errors, no SFC51 diagnostic entries referring to the Modbus blocks.
3. From the CP-343-1 Lean diagnostic page (PLC → Module Information → CP, or web-based diagnostics via the CP's IP) confirm: Connection state = ESTABLISHED, Active partner = configured DCS IP, Bytes sent / received incrementing.
4. Force one read job and one write job from the user program; verify DCS registers are updated and STATUS returned by FB65/FB66 equals W#16#0000.
5. Monitor OB1 scan time (OB1_PREV_CYCLE_TIME in OB1) for 60 minutes. Acceptable budget: cycle time should remain < 100 ms; the upgrade from a 95 % utilised 96 kB CPU to a 66 % utilised 192 kB CPU typically reduces cycle time because the CPU no longer spends cycles on memory management.
6. Test a power-cycle: remove power for 10 s, restore, confirm CPU returns to RUN with retain values intact and Modbus connection re-establishes within 30 s.

Cycle-Time and Performance Considerations

Work-memory utilisation above ~80 % does not merely block new downloads — it also slows scan time because the S7-300 firmware uses a paging algorithm that thrashes between RAM pages when the working set is large. A CPU running at 91 % utilisation can show scan times 1.4–1.8× that of the same program on a CPU at 50 % utilisation, even at identical clock speed. The 96 kB → 192 kB upgrade therefore also pays a performance dividend:

The above is illustrative and depends on DB count, FB nesting depth, and bit-memory footprint. Always measure after the upgrade rather than rely on a calculator.

Common Misconceptions to Clear With the Customer

• "Buy a bigger MMC." The MMC is load memory only. It cannot add a byte of work memory.
• "Compress and try again." Compress reclaims only previously deleted blocks' residual footprints; it does not create memory.
• "Update the firmware." Firmware updates in the same MLFB family do not change work-memory size; they only fix bugs and add new instruction support.
• "Just edit the existing program to free 30 kB." Often impossible because the program was authored by a third party whose IP the customer cannot expose. CPU upgrade is the only legal path.
• "Migrate to S7-1500." Architecturally cleaner, but a full S7-1500 migration is a project of its own; the S7-314C-2 PTP → S7-314C-2 PTP -6BH04 swap is the correct drop-in fix when the only goal is to host the Modbus TCP blocks.

Troubleshooting Matrix

Frequently Asked Questions