S7-1200 Retentive Memory: Configuring Past the 2048-Byte Limit

Overview of S7-1200 Retentive Memory

The S7-1200 compact controller retains a strictly bounded portion of its working memory across a power cycle. Operators expect machine parameters, recipe values, and tuning constants entered from an HMI to survive a weekend outage or a month-long shutdown without reloading. Engineers hit a hard limit when the combined size of the retentive M area plus the retentive bits inside global DB blocks exceeds the CPU-specific value configured at non-volatile storage. On first-generation S7-1200 firmware, that ceiling sits at 2048 bytes; on later firmware loads, the value grows with the CPU part number, but only if the firmware is updated and the hardware is replaced or upgraded in place.

This reference explains the memory model, the exact configuration path in TIA Portal, the failure modes at compile and download, and four field-proven workarounds for projects whose configuration dataset is much larger than the native retain budget.

S7-1200 Memory Architecture and Retain Boundary

The S7-1200 partitions load memory (typically the internal flash or an optional SIMATIC memory card), work memory (volatile RAM), and a retentive region carved out of work memory that is buffered to maintain its value when CPU power fails. The buffered area is defined by two parameters:

1. Retentive M bytes — the trailing portion of the bit memory (MB) area whose content survives power off.
2. Retain attribute — the per-DB flag in the block properties that marks a global data block (or selected tags of it) as retentive.

The CPU accepts a download only when retain_M_bytes + retain_DB_bytes ≤ max_retain_capacity, where max_retain_capacity is the value configured under PLC properties > General > Retentive memory. Older controllers default to 2048 bytes; newer firmware expands this value but the compiled retain footprint must still fit.

CPU model and firmware dependent limits

The exact headroom varies with the CPU order number and firmware version. Always verify against the active device configuration, not the catalog brochure.

Verify the live value through Online > Diagnostics > Memory or by reading "MemoryUsage" and "RetentiveMemorySize" via the Web server diagnostic pages. Do not rely on documentation alone when the on-disk image has been touched by a service pack.

Symptoms When Retentive Memory Is Exceeded

Two distinct failure modes surface in TIA Portal:

1. Compile-time check — the compiler emits a warning, "The retentive data area exceeds the maximum supported by the CPU," only when the device configuration is loaded. A program can compile cleanly on a PC without the device connected and still fail at download.
2. Download-time rejection — the CPU returns error SF 0x02 / BF 0x01 in the diagnostics buffer with text "Retentive data cannot be saved because the retain area of the CPU is too small." The project transfer aborts and the existing program keeps running.

Engineers frequently interpret a green compile as an approval to deploy. On S7-1200, the retain capacity check is a download-time gate, not a compile-time one, so the missing step is PLC > Download to device > Hardware detection or simply opening the device view against the offline/online snapshot.

Configuring Retentive Memory in TIA Portal

Open Project tree > CPU_xxx > Properties, then expand the navigation tree under General and select Retentive memory. The dialog exposes three settings:

• Retentive area in bits (MB) — a start offset and a length. Increasing the offset and length grows the M retain budget but consumes the global ceiling.
• Number of retentive bytes from MB0 — the trailing bytes from the start of MB upward.
• Number of retentive DB bytes — the total that the active set of global DBs requests through their retain attribute.

For each global DB that must retain values across a power cycle, open the block, expand Properties > Attributes, and set Retain = Set / Retain. To retain only selected tags, choose Set in IDB or use a partially retentive DB declaration on CPU firmware that supports Non-retentive on a per-tag basis (V4.4+).

Code patterns

A typical machine configuration DB might look as follows in Structured Text:

DATA_BLOCK "DB_MachineConfig"
{ S7_Optimized_Access := 'FALSE' ; S7_SetpointJob_TC := 'FALSE' }
VERSION : 0.1
NON_RETAIN
  VAR
    bFirstRun : BOOL;     // cleared on every restart
  END_VAR
RETAIN
  VAR
    rFormatLength   : REAL  := 1500.0;  // mm
    rTensionTarget  : REAL  := 25.0;    // N
    iBatchCounter   : DINT;             // production counter
    aRecipes        : ARRAY[1..50] OF "RecipeRecord"; // 50 format slots
  END_VAR
END_DATA_BLOCK

TYPE "RecipeRecord"
  VERSION : 1.0
  STRUCT
    rSpeed    : REAL;
    rTemp     : REAL;
    sName     : STRING[32];
  END_STRUCT;
END_TYPE

If aRecipes alone exceeds 2048 bytes, the CPU refuses the download. The fix is rarely “buy a bigger CPU”; it is reorganizing the data into the workaround patterns below.

Workarounds for Large Configuration Datasets

Four engineering options fit the S7-1200 ecosystem. Pick one based on the dataset size, the available hardware (memory card or not), and how often the operator changes values.

Workaround 1 — Reduce and deduplicate retentive data

Audit the project and shrink the retain footprint before re-architecting. Common reductions:

• Replace per-format REAL ramps with INT percent points (2 bytes per signal instead of 4).
• Use STRING[16] recipe names instead of STRING[64]; each saved character trims a byte.
• Store coarse machine configuration in retain DB; load detailed recipes on demand from RecipeView files on the HMI (see Workaround 3).
• Replace status flags that are derived on every restart (bFirstRun, bInitialized) with non-retain tags.

This is the cheapest fix and typically drops a 4 KB recipe DB below the 2 KB ceiling.

Workaround 2 — Upgrade firmware and CPU

If the project is on a CPU with firmware V3.x or earlier, upgrading to V4.4 or later raises the retain ceiling to 10 240 bytes on most 1214C/1215C/1217C parts. The procedure:

1. Insert a SIMATIC memory card with the upgrade file shipped by Siemens (a SIMATIC SD of 4 MB or 24 MB depending on the bundle).
2. Insert card into the powered CPU; the firmware update triggers automatically — the RDY LED flashes yellow-green during the process. The CPU must remain powered for the entire update (~3–5 minutes).
3. Update the device description in TIA Portal so the project targets the new firmware version. Re-compile and re-download the user program.

Workaround 3 — HMI recipe + PLC recipe DB hybrid

The cleanest pattern on a 2048-byte-limited S7-1200 is to keep only the active recipe in the PLC's retentive DB and store the rest of the recipe library on the HMI's project storage (or on the optional SIMATIC SD card). On recipe change-over, the HMI writes the selected recipe into the PLC's single retain slot and the CPU retains only the currently loaded set.

Implementation outline:

1. Define one DB_ActiveRecipe with the Retain flag set. Keep its size well under the retain budget.
2. Configure HMI Tags > Recipes in TIA Portal so each recipe is stored as a file on the panel.
3. In the HMI event OnRecipeLoaded, write the recipe data to the PLC DB using the standard recipe transfer area.
4. On PLC startup (OB100 / Startup), read the active recipe index from retain memory and pull the corresponding record from HMI if needed.

This pattern keeps the retain footprint to a few hundred bytes while supporting hundreds of format recipes on the HMI's local storage. See the SIMATIC HMI Recipes Programming Manual for the data flow diagram.

Workaround 4 — Data log file on the SIMATIC SD card

For machine parameters that change rarely (commissioning constants, calibration offsets), write them into a CSV file on the SD card using the DataLog instructions from the S7-1200 Programmable Controller System Manual. On the next startup, a startup OB reads the file back into a non-retentive DB; the SD card is non-volatile so the values persist.

Avoid using DataLog files as the primary storage for frequently edited recipe data — SD write cycles are limited (~100k per cluster). Use them for stable, infrequently changed data.

Recipe DB Pattern with Optimized Access

For firmware V4.4+, enable Optimized block access on the recipe DB. This unlocks per-tag retentive settings directly in the data view: each tag has its own Retain column that you can toggle without recompiling the entire block. The retain cost is computed from the sum of retained tags and is visible in the project tree.

Practical recipe data block:

DATA_BLOCK "DB_Recipes"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 1.0
NON_RETAIN
  VAR
    iActiveIndex : INT;     // 0..49
  END_VAR
RETAIN
  VAR
    rSpeedSetpoint  : REAL  := 50.0;
    rTorqueLimit    : REAL  := 120.0;
    rPullLength     : REAL  := 0.0;
    sRecipeName     : STRING[16] := 'DEFAULT';
  END_VAR
END_DATA_BLOCK

With optimized access enabled, the operator's edits from the HMI write directly into the retain slice of the DB. On power-cycle restoration, only the bytes flagged retain are pushed back into the working set.

Commissioning and Verification Checklist

Before signing off a machine that depends on retentive parameters:

1. Open Online > Go online and read Diagnostics > Memory. Verify Retentive memory used ≤ Retentive memory available.
2. Watch the diagnostics buffer entries during a forced power cycle: the message Retentive data restored should appear on the next startup.
3. From the HMI, change every operator-editable parameter, force a power cycle for at least 30 s (longer than the CPU's typical buffer time of 10–20 ms supercap, then 200–400 ms with the optional battery), and confirm each value returns.
4. Run an MRES on the retentive area to verify the reset path; restore from the HMI recipe backup.
5. Document the retain budget per DB in the project handover, so the next change does not silently push the project above the ceiling.

Migration Path: Why S7-1500 Avoids the Limit

The S7-1500 does not share the tight S7-1200 retain boundary. Retain memory scales with the CPU's work memory; a 1511/1513 ships with several hundred kilobytes of retain headroom, and a 1516/1517 carries multiple megabytes. Migrating an over-budget S7-1200 project is therefore an alternative when the field installation allows it. The trade-offs are:

Use the SIMATIC S7-1500 System Manual as the reference for migration paths.

Troubleshooting Matrix

Additional Field-Proven Caveats

• MRES wipes the entire retentive area. Operators must re-trigger commissioning, or an HMI-side backup must restore values via recipe transfer on the next startup OB.
• The S7-1200 optionally ships with a battery board (BB 1297) on 1214C/1215C/1217C. With the battery fitted, retain hold-up extends from milliseconds to months; the battery must be replaced every 4–5 years.
• The TR / CLR instructions on counters and timers do not automatically clear retentive instances. To ensure IEC counters and timers are non-retain, open the instance DB of the FB and switch the IEC timer/counter tag from RETAIN to NON_RETAIN.
• Programs that reference PEEK / POKE indirect access must be audited: a pointer can read retain bytes beyond the configured range and trigger the same download-time diagnostic as a DB block.
• The CPU's serial / Ethernet security settings do not interact with the retain limit. It is purely a memory accounting question.