Siemens S7-300 CPU 315-2 Memory Usage Checking in STEP 7

1. Overview: Why Memory Visibility Matters on the S7-300

The SIMATIC S7-300 platform uses a strictly partitioned memory model that separates the user program into load memory, work memory, and retentive memory. On a CPU 315-2 with the 64 KB work-memory class, every additional block, instance DB, or system data block consumes part of a finite budget. Unlike S7-1500 controllers that surface memory information graphically in TIA Portal's project tree, the S7-300 design environment (STEP 7 V5.x) requires engineers to interrogate the offline blocks folder and the online module to obtain a true picture of remaining capacity.

This reference consolidates the field-proven procedure for verifying memory occupancy before downloading to the S7-300, clarifies the differences between the PLCSim simulated memory model and a physical CPU 315-2, and adds the system-memory mathematics that allow sizing decisions to be made without trial downloads.

2. S7-300 CPU Memory Architecture

Siemens partitions the CPU memory into four cooperating regions. Understanding the role of each is essential because STEP 7 reports them independently and PLCSim models them with subtle differences from the real CPU.

The 64 KB value quoted for the CPU 315-2 refers to the integrated work memory total (code + data combined). The MMC supplies the load-memory footprint and the retentive area. The official function manual "Structure and Use of the CPU Memory" (referenced for the S7-1500 family) describes the same conceptual layering that also governs the S7-300.

3. CPU 315-2 Technical Specifications (Memory-Relevant Excerpt)

The values below are taken from the SIMATIC S7-300 CPU 31xC and CPU 31x technical-specifications manual published on the Siemens Industry Online Support portal. Engineers must verify the exact figure for the specific 6ES7 315-2Axx order number and firmware version installed, because Siemens has revised the integrated work-memory figures across firmware generations.

4. PLCSim Memory Model vs Real CPU Memory

S7-PLCSim simulates the CPU runtime, including the load/work/retentive partitioning, but it does so against the host computer's RAM. The limits that apply inside the simulated CPU are the limits declared by the simulated MLFB. This produces three behaviours that engineers working off-site (as in the original use-case) must understand.

1. Simulated work memory is bounded by the simulated MLFB. If PLCSim is started as a CPU 315-2 (6ES7315-2AG10-0AB0), it honours the 64 KB work-memory budget exactly as the real controller would.
2. Simulated load memory uses the host file system. The simulated MMC appears as a file (.s7p or directory tree) on the engineer's PC; its size is the size of the host file and not constrained by the physical 8 MB MMC ceiling.
3. Memory reads via PLCSim are valid for the simulated CPU only. If the field controller is a later MLFB with a larger work-memory budget, the download that succeeds in PLCSim will also succeed in the field. If the field controller is an earlier MLFB or a 64 KB variant, the same download may fault with "Not enough memory in the CPU" or "Memory overflow during download."

For these reasons, the PLCSim "online" memory readout is a faithful indicator of whether the offline program will fit into the simulated target, but it must never be assumed to predict a different physical MLFB.

5. Checking Offline Memory Consumption in STEP 7 V5.x

The most direct answer to the original field question is the offline-blocks inventory. STEP 7 V5.x reports the byte footprint of every block that would be downloaded, plus the totals the CPU 315-2 will need to reserve.

1. In the SIMATIC Manager, expand the S7 project and select the Blocks folder of the S7 program (do not open it; select the folder node).
2. Right-click → Object Properties → select the Blocks tab inside the Properties dialog.
3. Read the Required Memory values reported for: Length (Load memory), Length (Work memory), and Length (in MMC). STEP 7 lists both the sum of all blocks and the largest single-block contribution.
4. Compare the totals to the work-memory ceiling of the CPU 315-2 (64 KB combined for the older 2AF/2AG MLFBs).

This procedure answers the offline side of the question before any download attempt is made. The figures are deterministic: STEP 7 compiles the offline blocks container and reports the byte counts without involving the target.

5.1 Reading the Object Properties Dialog

The Blocks tab in Object Properties contains three columns that are commonly confused:

When the dialog shows Length (Load Memory) equal to the MMC capacity, the program will fit only if the MMC has been formatted to the maximum and the block layout allows it. When Length (Work Memory) exceeds 64 KB on the 64 KB-class CPU 315-2, the download will fail with an SF / BF diagnostic and the diagnostic buffer will log "Not enough work memory."

6. Checking Online Memory in STEP 7 and PLCSim

Once the offline procedure has confirmed that the program is theoretically small enough, the same information can be re-confirmed against the running controller — or against PLCSim when off-site.

1. Establish an online connection: PLC → Connect to Target System (in PLCSim this is "PLC → Connect to → PLCSim").
2. Open PLC → Module Information (or right-click the online CPU → Module Information).
3. Select the Memory tab.
4. Inspect the four gauges: Load Memory, Work Memory (Code), Work Memory (Data), and Retentive Memory. Each is reported in absolute bytes used and as a percent of the ceiling.
5. Cross-check the Diagnostic Buffer tab for any prior "Memory overflow" entries. Repeated overflows during STOP-to-RUN transitions indicate a retentive-data footprint that exceeds the configured retentive ceiling.

7. Sizing the User Program Against a 64 KB Budget

Because the CPU 315-2's 64 KB work-memory ceiling is tight, it is useful to know the typical byte overhead of common block types. The values below are nominal; STEP 7 will publish exact numbers in the Object Properties dialog after a successful compile.

For a 64 KB ceiling a useful rule-of-thumb is to budget no more than 40 KB for compiled code and 24 KB for data, leaving headroom for the local stack of nested OB calls and for diagnostic buffers. Always confirm against the actual numbers reported by STEP 7 rather than against the rule-of-thumb.

8. Retentive Memory Configuration

The CPU 315-2 supports retentive bit memory, timers, and counters. The retentive area is configured in HW Config under CPU Properties → Retentive Memory or, equivalently, via the PLC tag table using the "Retentive memory" button described in the Siemens function manual on CPU memory.

1. Open HW Config and place the CPU 315-2.
2. Double-click the CPU → Retentive Memory tab.
3. Define the count of retentive M bytes, retentive T instances, and retentive C instances. Set the start of the retentive DB area by specifying a starting DB and a byte count.
4. Compile and download the hardware configuration. The retentive settings persist through power-cycle only if the MMC is present and, on older CPU 315-2 batches, the optional backup battery is fitted.

Retentive data is stored inside the work-memory region; setting an overly large retentive area shrinks the volatile budget available for runtime DBs and may trigger "Not enough work memory" on the first STOP-to-RUN after a download.

9. Troubleshooting Matrix

10. Field-Proven Workflow Before Off-Site Download

The following workflow ensures that an engineer developing the program off-site against PLCSim cannot accidentally produce a download that fails against the real CPU 315-2.

1. Open the SIMATIC Manager project whose target MLFB matches the field controller — do not rely on a "generic CPU 315" placeholder.
2. Confirm the MLFB inside HW Config: PLC → Module Information shows the same 6ES7 315-2Axx order number as the label on the field controller.
3. Run the offline Object Properties → Blocks tab check (Section 5). Record the three byte counts.
4. Launch PLCSim, start the matching MLFB, download the program, and re-check Module Information → Memory. The PLCSim view must agree with the offline check within a few bytes (the few bytes difference is the SD block bootstrap).
5. Only after the PLCSim readout is below the 64 KB (or 256 KB, depending on MLFB) ceiling should the engineer dispatch the program to the field.
6. On-site, perform the same Module Information → Memory check against the physical CPU before and after the download. If the post-download Work Memory Used gauge approaches the ceiling, abort further changes and plan a migration.

11. Comparison: S7-300 vs S7-1500 Memory View

Engineers transitioning from STEP 7 V5.x to TIA Portal often expect the same dialogs to behave identically. They do not. The S7-1500 (and S7-1200) memory model is exposed by the TIA Portal manual collection with the same load/work/retentive split, but TIA Portal adds a project-tree "Program information" view that aggregates the same numbers without the Object Properties detour. S7-300 with STEP 7 V5.x has no equivalent project-tree aggregate; the engineer must use either the offline Blocks tab or the online Module Information → Memory tab.

12. Notes on Bit Memory vs Process Image

The Siemens support article on memory bits clarifies a frequently confused point: bit-memory area M (for example M0.0) is a CPU-resident RAM location with no physical I/O module behind it, whereas the input area I (for example I0.0) maps to a real digital-input module. M memory is therefore the recommended vehicle for HMI command bits, internal flags, and sequence latches; I memory is reserved for the actual process-image-of-the-inputs read from the I/O backplane.

The M area's size is fixed by the CPU's system-memory definition and is reported alongside the work-memory figures. On the CPU 315-2 the default M area is 256 bytes but is configurable. Reducing M area frees a small amount of system memory; on a 64 KB work-memory budget the saving is negligible unless the project has hundreds of flags.

13. Program Info — The Aggregated View

STEP 7 V5.x also exposes an aggregated view via PLC → Program Info (or Options → Reference Data → Display after generating them). Program Info splits the memory usage into Load Memory, Work Memory, and Retentive Memory exactly as the online Module Information → Memory tab does, but it draws the data from the offline compile rather than the live controller. This makes Program Info a third verification point and a useful cross-check against the Object Properties → Blocks tab.