S7-1200 Memory Architecture: Work vs Load Memory Explained

S7-1200 Memory Architecture Overview

Siemens SIMATIC S7-1200 controllers use a two-tier memory architecture that separates persistent storage from execution memory. This model is consistent across the S7-1200 family but is implemented differently in the larger S7-1500 and S7-400 families, where work memory is partitioned into separate code and data areas. In the S7-1200, all active runtime objects—organization blocks (OBs), function blocks (FBs), functions (FCs), data blocks (DBs), and instance data—draw from one common work memory pool sized in tens of kilobytes. A separate load memory region, resident on the SIMATIC Memory Card (SMC), holds the offline project archive, the compiled program image, the hardware configuration, and any firmware update packages. Understanding this division is essential before sizing the controller for a real workload. Reference: SIMATIC S7-1200 Programmable Controller System Manual.

Because the S7-1200 family shares the same memory model as the S7-300 and the older ET200S head modules, engineers moving between these platforms often assume that work memory and load memory are interchangeable. They are not. Work memory is fixed by the CPU part number; adding an SMC never increases the amount of code and data the CPU can keep in execution at any one moment. The SMC only increases the offline storage budget and the room available for recipes, web-server pages, and bulk DataLog files that can be read back later by an HMI or remote client.

S7-1212C Memory Specifications

The CPU 1212C is available in three supply variants (DC/DC/DC, DC/DC/RLY, AC/DC/RLY) but each variant ships with the same memory envelope. The headline figure printed in the data sheet is 50 KB of work memory. That 50 KB has to cover every block currently loaded into the runtime—OBs, FBs, FCs, instance DBs, global DBs, plus any retentive markers declared in the PLC tag table.

Confirm exact retentive and block-count figures against the firmware release installed in the controller using TIA Portal → Online → Accessible Nodes → Diagnostics, because firmware revisions occasionally revise these ceilings. The official firmware catalog and version matrix is published on the Siemens Industry Online Support S7-1200 portal.

Where 50 KB Disappears

A 50 KB work memory budget is consumed by four contributors:

1. Program blocks (OBs, FBs, FCs, types) compiled to native code. A non-trivial Modbus master routine with four slaves easily compiles to 8–14 KB.
2. Global DBs holding process tags. A 100-byte receive buffer replicated across four slaves plus parameter DBs for MB_MASTER instances adds another 1–2 KB.
3. Instance DBs for each FB call. A single MB_MASTER instance DB occupies roughly 1.5 KB; four instances approach 6 KB.
4. System overhead for the PLC tag table, the HW config, and the runtime diagnostics stack. TIA Portal reserves approximately 4 KB on the S7-1212C just for system data.

Once these four contributors are added, the practical ceiling for user program code and additional user DBs is often 25–30 KB. Designing the application around that ceiling, rather than the nominal 50 KB figure, prevents "memory full" diagnostics at commissioning.

Work Memory vs Load Memory in Detail

Work memory is volatile execution RAM. The CPU reads the compiled blocks from the SMC at power-up (or from internal flash if no card is fitted), decompresses them into work memory, and runs all scan cycles out of that RAM region. Retentive data, markers declared RETAIN, and persistent DBs are mirrored into a small non-volatile area so that a power loss does not wipe active process state.

Load memory is persistent storage located on the SIMATIC Memory Card. The SMC is the same physical card that stores firmware updates, recipe files, web pages for the integrated web server, and any archive logs enabled through DataLog instructions. Load memory size is dictated by the SMC model ordered; common SKUs include 4 MB, 12 MB, 24 MB, 256 MB, 2 GB, and 32 GB. The S7-1200 firmware uses a wear-levelled file system on the card, so user code is rewritten several times during each project download.

Why the Split Exists

The split allows a project to be archived on the card, transferred between controllers of the same family, and rolled back to a previous build without engaging TIA Portal. When the S7-1200 is configured for "transfer" mode, the CPU expects to find a program on the inserted SMC at boot and runs that program rather than whatever was last downloaded. This makes the SMC the canonical distribution medium for OEM machine builders shipping spare parts worldwide.

SIMATIC Memory Card (SMC) Sizing Rules

Choose an SMC capacity based on three factors:

1. Compile size of the active project including HW config, system data, and all blocks.
2. Headroom for upgrades, recipe files, and DataLog storage.
3. Margin for wear-levelling writes during repeated downloads in RUN mode.

Field experience across Siemens support cases shows that the minimum practical SMC size is roughly twice the offline compile footprint. For a CPU 1212C project that compiles to 49 KB (the figure reported by TIA Portal when system data is selected), an 8 MB SMC is ample. For projects that contain large recipe DBs, embedded web pages, or long DataLog intervals, stepping up to a 256 MB SMC is the conservative choice.

Confirm the SMC order number for your region in the Siemens Industry Mall. Different regions (EU, US, Asia) carry variant part numbers ending in -0AA0, -0AA1, or -0AA8; all variants are functionally identical. Reference: SIMATIC S7-1200 product page.

Reading Program Size in TIA Portal

Program Info is the authoritative reporting tool for memory consumption. Open the project tree, expand the target PLC, and double-click Program Info. TIA Portal generates two reports of interest.

Compile Footprint (Offline View)

Under Program Structure → Blocks, every block is listed with its work memory footprint in bytes. The right-hand summary shows the total. This figure approximates the bytes the CPU must reserve at start-up.

Runtime Footprint (Online View)

After downloading, open Online → Go Online, then return to Program Info and select the Online view. The CPU reports the actual bytes loaded into RAM for each block. Differences between offline and online values are normal because TIA Portal allocates additional headers and diagnostic structures after the program reaches the controller.

Where to Locate Load Memory Usage

Load memory is reported separately. Navigate to Online → Diagnostics → Memory. The dialog exposes three counters:

• Work memory used / total
• Load memory used / total
• Retentive memory used / total

These three numbers must remain below their respective totals or the CPU raises a "Memory card removed" or "Not enough memory in work memory" diagnostic. The diagnostic buffer can be read into a user DB by the RD_SINFO or GET_DIAG instructions for display on an HMI.

Online Diagnostics Without TIA Portal

Engineers without a TIA Portal client on the bench can still inspect memory through the CPU's built-in web server. Enable the web server in the device properties (default port 80), enter the administrator password, and open the diagnostics page. The S7-1200 reports work memory used, work memory total, and load memory in use on the inserted SMC. The figures are identical to those returned by TIA Portal.

For deeper inspection, use the RD_SINFO instruction inside the user program to read the diagnostic buffer into a DB and display it on an HMI. A standard pattern is to push the buffer into a 1 KB string DB every time OB82 (diagnostic interrupt) fires, capturing memory state together with the fault code.

S7-1200 Compared With ET200S Memory Model

The ET200S distributed I/O station uses an IM151 head module (CPU-less variant) or, in the older STEP 7 classic world, an ET200S CPU that hosted its own user program. The ET200S CPU's load memory was supplied by an MMC card (different part number than the S7-1200 SMC) sized in tens to hundreds of megabytes, while work memory was fixed at the head module's rated figure (typically 128 KB to 512 KB depending on the variant).

Both platforms share the "single work memory pool" topology. The two important differences for the engineer are the configuration toolchain and the absolute work memory ceiling. A legacy ET200S user migrating to S7-1200 should expect to encounter a smaller work memory budget; an S7-1200 user migrating to a 1500-series CPU should expect to encounter a partitioned code / data memory layout.

Modbus Master Memory Budget Example

Work through a representative Modbus master scenario to confirm whether 50 KB is sufficient. The application polls four slaves, each returning 100 bytes of holding registers on a 1-second cycle. Process tags are mirrored to an HMI but no DataLog or recipe storage is enabled.

Step 1 – Identify the Blocks Required

• 1× OB1 (cyclic) – 2 KB compiled
• 4× MB_MASTER instance DBs – 1.5 KB each = 6 KB
• 1× global DB for slave 1 receive buffer (100 bytes + header) – 1 KB
• 1× global DB for slave 2 receive buffer – 1 KB
• 1× global DB for slave 3 receive buffer – 1 KB
• 1× global DB for slave 4 receive buffer – 1 KB
• 1× FB "Process_Data" – 4 KB
• 1× FC "Heartbeat" – 0.5 KB
• PLC tag table – 1 KB
• HW config / system data – 4 KB

Step 2 – Sum the Footprint

Adding the figures: 2 + 6 + 1 + 1 + 1 + 1 + 4 + 0.5 + 1 + 4 = 21.5 KB. The application lands at roughly 22 KB of work memory, well below the 50 KB ceiling.

Step 3 – Plan the Load Memory

Compile footprint (which is approximately equal to load memory occupied) for a 22 KB work memory project is typically 28–34 KB. Add 4 KB of system data and the project needs 32–38 KB of load memory. A 4 MB SMC provides a comfortable 100× headroom; an 8 MB or 12 MB SMC is the practical minimum recommended in field guidance.

Step 4 – Validate in TIA Portal

Build the project, open Program Info, and verify both Work memory total and Load memory used stay below their totals. If either counter approaches 90 %, drop the SMC to a 12 MB part to recover load memory margin or step up to a CPU 1214C to recover work memory margin.

Memory Optimization Techniques

Apply these techniques when work memory approaches its limit.

Reduce Instance DB Footprint

Replace FBs with FCs wherever possible. FBs require instance DBs; FCs do not. A well-written FC using temporary (T) tags can deliver the same logic with zero persistent DB cost.

Strip Comments and Symbolic Names

TIA Portal keeps symbolic information in a separate resource that does not consume work memory at runtime. Symbols are useful during commissioning but they add load memory bytes only; the runtime engine compiles to a fixed binary image regardless. To reduce load memory, deselect "Symbolic name resolution" in the project options before downloading to a small SMC.

Use ARRAY OF BOOL Instead of Many Discrete Tags

An ARRAY[0..31] OF BOOL occupies 32 bits = 4 bytes, the same as 32 individual BOOLs. However, the array can be addressed symbolically in a loop, which removes the need for the compiler to generate lookup tables for each tag.

Consolidate Data Blocks

A scattered collection of small DBs (one tag per DB) inflates the DB header overhead. Merging related tags into a single global DB removes the header repetition and can reclaim 5–10 % of work memory.

Disable Unused OBs

Every OB present in the project is loaded into work memory regardless of whether it is invoked by the CPU. Removing OB121 (programming error), OB122 (I/O access error), and unused cyclic interrupts from the project tree reduces the offline compile footprint.

Selecting the Correct CPU for Work Memory Headroom

Use this decision matrix when work memory consumption exceeds 80 % of the CPU 1212C ceiling.

The CPU 1215C FW V4.4 (released 2019) is the first SKU to expose 125 KB of work memory through a firmware update rather than a hardware revision. Upgrading existing CPUs to that firmware release is documented in the S7-1200 firmware update instructions on Siemens Industry Online Support. Reference: SIMATIC S7-1200 Easy Book.

Troubleshooting Matrix

Frequently Asked Questions