S7-300 Retentive Data Blocks: Retain PID and Process Values Through Power Loss

Retention of process parameters across uncontrolled events (power loss, project download, memory reset, CPU restart) is one of the most frequently asked questions on S7-300 deployments that include closed-loop control. PID tuning constants, totalizers, recipe indexes, shift counters, and operator-entered setpoints live inside Data Blocks (DBs); whether those values survive a brownout depends on a specific combination of CPU hardware, STEP 7/TIA Portal project attributes, and the presence of a working backup battery. This reference consolidates the official Siemens behavior, the configuration screens in both STEP 7 V5.x and TIA Portal, the impact of MRES, the impact of full versus delta downloads, and the recommended HMI-side strategy for tag persistence.

1. S7-300 Memory Model: Load, Work, and Retentive

An S7-300 CPU has three physically separate storage regions, and understanding the difference is the only way to predict what survives a power loss.

The MMC (Micro Memory Card) is a FEPROM device plugged into the CPU; on CPUs without an MMC slot the load memory is internal Flash. FEPROM retains data without battery and is the source of truth for the project after power-up. The actual values of DBs are normally held in work memory; whether they survive a power loss depends on two independent things: (a) the backup battery state and (b) the Non-Retain attribute of the DB.

Refer to the SIMATIC S7-300 CPU 31xC and CPU 31x: Technical Data manual for the load memory size, retentive memory size, and battery life spec of each CPU variant. Battery life on a CPU 315-2 DP at 25 °C is approximately 1-2 years; this drops sharply above 40 °C ambient.

2. Default Retentive Behavior of Data Blocks

In STEP 7 V5.x, every newly created Shared DB (DB) and Instance DB (iDB) is, by default, retentive. The Non-Retain attribute is the opt-out switch; if the engineer never touches it, the DB behaves as retentive subject to the rules in Section 4. In TIA Portal, the default differs by DB type: Shared DBs default to retentive, but the data block created for a block-optimized FB (where applicable in the S7-300 context with compatible firmware) defaults to Non-retain. Always verify the attribute on the DB that holds PID tuning.

3. Configuring DB Retentivity in STEP 7 V5.x

Open the Data Block in the LAD/FBD/STL editor, right-click the DB header, and select Properties. The Attributes tab exposes a single checkbox: Non-Retain. Leaving it unchecked marks the entire DB as retentive. There is no per-tag control at the V5.x level for S7-300; the attribute is whole-DB.

Additionally, in HW Config → CPU Properties → Retentive Memory, declare how many bytes of M, T, and C are retentive. This screen does not control DB retentivity directly, but it determines whether a given DB's actual values have somewhere to live while the battery is discharging. A typical configuration for a PID station looks like:

Refer to the STEP 7 V5.5 Programming and Operating Manual for the precise UI path and the S7-300 Automation System: Module Data reference for the maximum retentive ranges per CPU.

4. Configuring DB Retentivity in TIA Portal (S7-300 target)

In TIA Portal V16+, the equivalent attribute is on the DB's Properties → Attributes tab under the section Retain. The checkboxes are:

• Set in IDB (Set in instance DB) – controls whether the attribute is inherited from the FB's iDB settings.
• Non-retain (Reset to initial values on restart) – when checked, the DB's actual values are replaced by the initial values on every STOP→RUN transition.

For a Shared DB that holds operator-entered setpoints, leave both unchecked. For an instance DB of FB 41/42/43 (PID Compact / Continuous / Step), the retentivity is a property of the iDB, not of the FB itself, so configure it on the iDB. TIA Portal does not expose per-tag retentive bit selection for S7-300 (this per-tag selection is an S7-1500 capability); the S7-300 retains the whole-DB model.

5. Memory Reset (MRES) Behavior on S7-300

The S7-300 mode selector has three positions: RUN, STOP, and MRES. MRES is initiated by a specific toggle sequence (STOP → MRES → STOP → MRES within a few seconds). Its effect on memory is:

Key takeaways from the matrix:

• MRES does not erase the load memory; it only forces a re-copy from FEPROM to RAM.
• MRES preserves retentive DBs only if the backup battery is healthy and the DB is not flagged Non-Retain.
• A full download from PG/PC always wipes actual values regardless of DB attributes, because the FEPROM is rewritten with the PG image.

6. Project Download: Full vs. Delta vs. Block-Level

STEP 7 and TIA Portal distinguish three download granularities, and the answer to the engineer's question — "will my DB values be lost if I re-download?" — depends on which one is performed.

6.1 Full download of the entire station

Triggered by selecting the CPU and choosing Download to Device → Stop and download to target system with Consistent download enabled. The entire FEPROM is rewritten. All actual values in the load memory are replaced by the PG image; on power-up, the CPU copies the PG initial values into work memory. Retentive DB actual values are lost. This is the only download mode that loses everything, and it is the correct behavior for a commissioning transfer.

6.2 Block-level download (Download blocks only)

In STEP 7 V5.x, selecting individual blocks in the project tree and choosing Download performs a block-level transfer. The CPU's FEPROM is patched in place; the load memory and the actual values of untouched blocks remain. If you only download the OB1 and not the PID's instance DB, the PID actual values are preserved. If you download a new version of the same DB, the CPU behavior depends on the SZL flag and the structure ID: a structurally identical re-download leaves actual values intact; a structural change (e.g. a new tag) resets the DB to initial values.

6.3 Delta download in TIA Portal

TIA Portal performs a dependency-aware delta: blocks that have not changed are not re-transferred. The download dialog shows a comparison view; expanded DB changes can be reviewed line-by-line. The actual value preservation rule is the same as the block-level download — identical structure keeps values, structural change resets them.

For sensitive PID values, prefer a delta download over a full station download. The S7-300 Module Data reference documents the exact structural-change behavior under the Block consistency section.

7. PID Block (FB 41 / FB 42 / FB 43) Retention

The standard PID blocks from the STEP 7 Standard Library store all tuning parameters in their instance DB. The relevant tags for retention are:

Because all of these live in the instance DB, configuring the iDB as retentive (i.e. uncheck Non-Retain) is the entire retention story. The PID block is started in OB35 (or another cyclic OB), and on STOP→RUN the iDB keeps its actual values if the DB is retentive, giving a bumpless restart where the manipulated variable resumes at the last output rather than at zero.

For a TIA Portal deployment, the same logic applies to PID_Compact (FB 1130 and its family) on S7-300 with firmware ≥ V3.x supporting TIA export. The instance DB remains the storage target.

8. Backup Battery: When Retention Really Survives

All retention claims are conditional on the backup battery. The S7-300 uses a single lithium backup cell (order number 6ES7971-1AA00-0AA0 for the 3.6 V / 2.5 Ah cell) housed in a holder on the CPU. The BATTF LED on the CPU front lights when the battery is below threshold or missing. On the CPU 315-2 DP, the diagnostic buffer entry Battery exhausted is written before the cell actually dies, giving a window for replacement.

Recommended battery handling procedure:

1. Read the diagnostic buffer monthly via PLC → Diagnostic Buffer; look for Battery exhausted or Battery failure entries.
2. Replace the cell within 1-2 weeks of the first warning. The CPU retains retentive data for the duration specified in the data sheet, typically a few hundred hours, but this degrades with age.
3. Always perform battery replacement with the CPU powered up; otherwise the buffering path is open and the FEPROM takes over but the retentive RAM is lost.
4. Document the battery date-of-install on the panel label. Calendar replacement at 50% of rated life is the conservative policy.

9. HMI-Side Persistence: Tag Values, Recipes, and Flash Endurance

If the engineering goal is to retain operator-entered values across a HMI power loss (independent of PLC retention), the HMI has its own persistence mechanisms. On WinCC Flexible, TIA Portal Comfort/Advanced, and WinCC RT, the typical approach is one of three:

9.1 Persistent tag

On a SIMATIC Panel (Comfort, KTP, Mobile) the tag property Acquisition mode → Persistent writes the value to internal flash on each change. On a PC-based runtime (WinCC RT, WinCC Professional RT) the persistence target is a local file under the project folder. Both have a finite write budget.

9.2 Recipe data record

Recipes are the higher-level mechanism: a structured set of tags stored in flash, downloaded to the PLC on demand. Recipes are the right choice for setpoints that change infrequently (one to a few times per shift) because the write budget is per-record, not per-tag change.

9.3 PLC mirror write

The recommended pattern for tight coupling is: the HMI writes the value to a retentive PLC DB, and the DB is the source of truth. The HMI then reads the value back on next power-up, so the HMI does not need its own persistence. This is the cleanest architecture because retention is the PLC's job, and the HMI becomes a stateless view.

10. EEPROM and Flash Write-Cycle Limits

All non-volatile storage media in a PLC and a HMI have a finite write endurance. The MMC (FEPROM) in an S7-300 is rated for 1,000,000 write cycles per cell, but the practical whole-device life is lower. The HMI's internal flash is similar. Writing a tag on every PLC cycle (e.g. 100 ms) will exceed the budget in days.

Engineering rules to extend retention media life:

• Use the PLC mirror pattern. The PLC's RAM retention is battery-backed, not flash-backed; it has effectively unlimited write cycles.
• Persist only on value change (write-on-change), not on cycle.
• Aggregate operator setpoints into recipes rather than persisting individual tags.
• For the HMI mirror case where the HMI must write back to the PLC on next power-up, batch the writes — collect operator changes over a 1-5 second window and write a single block transfer.

See the SIMATIC S7-300 CPU 31x Technical Data for the MMC endurance specification and the panel-specific Operating Instructions for the HMI flash endurance.

11. Practical Implementation: Retaining PID and Process Values

Putting all the rules together, the recommended structure for a S7-300 process cell with a PID loop and operator-entered setpoints is:

Program-side, the PID loop is started in OB35 with a 100 ms cycle. On STARTUP (OB100), initialize the PV and the manipulated variable only if the retentive area is empty; the standard pattern is to use a sentinel value (e.g. 1E+30) to detect a cold start with empty retention.

Example startup logic in OB100 (ST):

// OB100: Startup - decide between cold start and warm restart
IF "DB_Init_Once".ColdStartDone = FALSE THEN
    // First-ever power-up: initialize defaults
    "PID_DB".GAIN := 1.0;
    "PID_DB".TI   := T#20s;
    "PID_DB".TD   := T#0s;
    "PID_DB".SP_INT := 50.0;
    "DB_Init_Once".ColdStartDone := TRUE;
ELSE
    // Warm restart: keep retentive actual values
    // (PID_Compact or CONT_C resumes from previous state)
END_IF;

The sentinel ColdStartDone itself must be in a retentive DB so that the warm-start branch is taken on subsequent restarts. If the backup battery dies, the sentinel is lost and the cold-start branch runs again — which is the desired safe behavior.

12. Verification Procedure After Configuration

To prove retention works before handing the system over to operations:

1. From the HMI, enter a non-default setpoint (e.g. 73.5 °C). Verify the PLC tag reflects it via Monitor/Modify.
2. From the mode selector, switch to STOP. Cycle power on the CPU only — leave the HMI powered. After power-up, verify the PLC tag still reads 73.5 °C.
3. Switch to RUN. Verify the HMI re-reads 73.5 °C without operator action.
4. Cycle power on the HMI only. Verify the HMI re-displays 73.5 °C after the PLC connection re-establishes.
5. Cycle power on both. Verify the cycle above (PLC then HMI) still produces 73.5 °C.
6. Perform a block-level download of an unrelated OB (e.g. OB1). Verify the PID tag is unchanged.
7. Perform a full station download with Consistent download. Verify the PID tag is reset to its initial value. This is expected and must be documented in the operator's manual.
8. Remove the backup battery with the CPU powered; cycle power; verify retentive DB actual values are lost (the test confirms the dependency on the battery).

Document the result of step 7 and 8 in the project's Functional Safety / Retention matrix; this is the evidence that the retention requirement is met.

13. Troubleshooting Matrix

14. Field-Proven Caveats and Edge Cases

• Firmware ≥ V3.x on the CPU is required for some TIA Portal features. A CPU 314 with firmware V2.x will accept a TIA project but certain retentive attributes are silently ignored. Check the module data reference for the firmware-specific behavior.
• String tags in DBs (e.g. operator name) are retained as a whole, but the string length field is reset to 0 if the DB is Non-Retain; this presents as an empty string rather than the default content. The diagnostic symptom is "all operator names disappear on every restart".
• ARRAY and STRUCT tags are retained at the parent level; partial re-initialization is not possible at the array-element level for S7-300 (this is an S7-1500 capability).
• TIA Portal with a re-imported STEP 7 V5.x project can flip the Non-Retain attribute during migration. Always verify retention attributes after every project migration.
• OB100 startup time is limited; deep initialization of large retentive arrays in OB100 can exceed the startup time budget and the CPU will go to STOP with a startup-time error. Initialize only sentinel flags in OB100 and let the cyclic OB do the heavy lifting.

15. Recommended Engineering Practice Summary

1. Treat PLC RAM retention as the primary mechanism. The CPU battery is the single point of truth; monitor it.
2. Use a single dedicated DB (e.g. DB 99) for retention-aware flags and cold-start sentinels. Mark it explicitly as retentive in the project documentation.
3. Keep all PID tuning, setpoints, totalizers, and mode flags in retentive DBs with Non-Retain off.
4. Avoid persisting to HMI flash at high frequency; mirror from PLC instead.
5. Document the full-station download as a destructive operation; the operator manual must call it out and require a deliberate "save setpoints" procedure beforehand.
6. Schedule battery replacement on a fixed interval (e.g. every 2 years) regardless of the BATTF LED state.
7. Perform the verification procedure in Section 12 on every new project and after every firmware update.

FAQ