S7-300 TIA Portal DB Reinitialization: Preserve Values on Add

Problem Overview

When an engineer adds a new tag (variable) to a Data Block (DB) in the Siemens TIA Portal for an S7-300 station (for example, CPU 313C, 6ES7 313-5BF03-0AB0 or any 31x/31xC variant) and performs a download, all existing variable values in that DB are reset to their declared default values. Counters, setpoints, state flags, recipes, and tuning constants accumulated during commissioning or production are lost.

This behavior is different from many other controller families (Allen-Bradley Logix Designer, Beckhoff TwinCAT, Codesys-based PLCs) where adding members to a structure preserves the live values of unchanged members. The Siemens S7-300 firmware implements a strict "DB restart" semantic on download of an instance or global DB whose declaration has been altered: the entire block is re-initialized in work memory.

Symptoms include:

• Counter values (e.g. produced part counts) return to 0 after a download.
• Recipe setpoints revert to the defaults declared in the DB editor.
• HMI trend curves that read directly from the DB display flatlines or zero values.
• State machine position variables return to their initial state, potentially causing a safety-relevant restart of the process.
• PID controller integrator (I-portion) values are wiped, causing the loop to bump.

On a process that cannot be stopped (continuous web, glass furnace, kiln, chemical reactor), this re-initialization is a direct production risk.

Root Cause: Why the S7-300 Reinitializes the DB

The S7-300 CPU manages two distinct memory areas for a Data Block:

1. Load memory (typically the MMC for S7-300 CPUs). Holds the compiled DB including its initial values (the "default values" column in the DB editor).
2. Work memory (RAM). Holds the running instance of the DB with the current values modified by the user program and by HMI.

When TIA Portal detects that the interface signature of a DB has changed — for example, a new tag is appended, a tag is renamed, or the data type is changed — it must regenerate the entire block object. The download sequence is:

1. TIA Portal deletes the existing block in the CPU.
2. The new block image is written to load memory.
3. On the next STOP→RUN transition (or implicit restart caused by the deletion), the CPU copies the initial values from load memory into work memory, overwriting the live values.

This is documented in the S7-300 Automation System Manual under the section "Behavior of Data Blocks after Reload" and in the S7-300 CPU 31xC Technological Functions manual for the 31xC variants. The initial-value column of the DB editor corresponds exactly to what is loaded into work memory at block restart.

CPU 313C Memory Layout and Retentivity Boundaries

The 313C has 64 KB of work memory, 128 KB of load memory, and supports a maximum of 1024 DBs (DB 0 is reserved). Relevant constraints that interact with this issue:

A DB can be marked non-retentive (the default — values are lost on power fail / restart) or retentive (values survive STOP→RUN and even power fail, limited by the CPU's retentivity ranges). Retentivity only protects against power off and STOP→RUN transitions caused by mode change — it does not protect against a download that deletes and re-creates the block. Once the block is re-created by the download, the initial values are loaded and the previous contents in work memory are gone, regardless of the retentive flag.

Diagnostic: Confirming the Re-Initialization

Before applying a workaround, verify that the symptom is in fact DB re-initialization and not, for example, an OB100 startup that explicitly clears the DB.

1. Online → Go online with the CPU.
2. Right-click the affected DB → Monitor/Modify. Note a value, for example a counter at 1234.
3. Trigger the download of the modified DB.
4. Re-open Monitor/Modify. If the value is 0 (or whatever initial value was declared), the DB was re-initialized by the download.
5. Cross-check by looking at the diagnostic buffer: Online → Accessible Devices → CPU → Diagnostic Buffer. Look for entries "Download of block DB<n>" followed by "Restart (cold/warm)" or "Stop caused by download of modified block".

If the value is preserved, the issue is something else (OB100 clearing memory, an HMI write to the wrong area, an unconnected safety program running an initial block, etc.).

Workaround 1 — Buffer DB (Save-As) Pattern

The most reliable workflow during commissioning and on a running process is to maintain a buffer copy of the DB containing the live values before every download that adds tags.

1. Before downloading the modified DB, go online and read the current values. Online → Upload Station to PG only for the affected DB, or use "Snapshot" in the project tree.
2. Right-click the DB in the project tree → Save As → name it e.g. DB_LiveBackup or DB_RuntimeValues. Save it as a separate global DB so its declaration is locked.
3. Now add your new variables to the working DB and download.
4. After the download, the new DB has the new tags but the values are at the initial state. Open both DBs side-by-side, copy the current values from DB_LiveBackup into the new DB (Monitor/Modify online write) for every tag whose name still matches.
5. Once stable, delete DB_LiveBackup.

Workaround 2 — Pre-Allocation of Dummy Tags

Avoid the issue altogether by reserving free slots in the DB at design time. A common pattern is to pre-allocate, for example, 50 INTs, 50 BOOLs, 50 REALs, and 50 TIMERs as dummy variables.

DATA_BLOCK "DB_ProcessData"
{ S7_Optimized_Access := 'FALSE' }
  STRUCT
    // Active tags
    i_ActualCount : INT := 0;
    r_Setpoint    : REAL := 50.0;
    b_RunEnable   : BOOL := FALSE;
    t_HeatOn      : TIMER;
    // --- Reserve 50 INTs, 50 BOOLs, 50 REALs, 50 TIMERs ---
    i_Reserve : ARRAY[1..50] OF INT;  // all := 0
    b_Reserve : ARRAY[1..50] OF BOOL; // all := FALSE
    r_Reserve : ARRAY[1..50] OF REAL; // all := 0.0
    t_Reserve : ARRAY[1..50] OF TIMER;
  END_STRUCT;
END_DATA_BLOCK

When a new variable is required, the engineer renames (and retypes) one of the reserve elements. As long as the offset and length of the modified reserve element do not change relative to neighbors, the rest of the DB is preserved by the CPU.

Workaround 3 — Separate "Static" and "Live" DBs

Decouple the data that legitimately needs to change (recipe data, learned PID gains, current counts) from the data that is genuinely configuration. Live values that must survive a download should live in their own DB that is not modified when the project changes.

1. Move the runtime values into a dedicated DB, e.g. DB_Runtime, declared once and never edited after commissioning.
2. Place new development tags in a separate DB_Development or in the instance DBs of new FBs.
3. Use the program to copy values between DB_Development (volatile, regenerated) and DB_Runtime (stable).

This is the same architectural pattern that high-availability S7-300 applications (redundant H systems) use to insulate live data from project changes.

Workaround 4 — Recipe / Data Record on MMC

For setpoints that need to survive both STOP→RUN transitions and downloads, persist them to MMC using SFC58 / SFC59 (write/read record) on a data record in the user-defined area, or use the SFC82 / SFC84 functions on a passive S7 connection. The download can wipe the work-memory DB but the values are recoverable from the MMC and the OB100 (startup) reloads them.

// OB100 - Startup
// Reload saved recipe from MMC into DB_Recipe
CALL  "SFB 52" / "RDREC"
      REQ    := TRUE
      IOID    := B#16#54
      LADDR   := W#16#0     // MMC pseudo slot
      RECNUM  := 1
      RET_VAL := MW 100
      BUSY    := M101.0
      RECORD  := P#DB101.DBX0.0 BYTE 200;

This pattern is widely used in S7-300 boiler, kiln, and weigh-feeder applications where recipes must survive a controller swap.

Workaround 5 — Symbolic Tag Rename Only (TIA Portal V13+)

Starting with TIA Portal V13, certain S7-300 firmware versions (CPU 31xC with firmware V3.3 and CPU 31x with firmware V3.3 or later) support a "Software-Update during operation" mode in the CPU properties under Protection & Security → Software Update. When this option is enabled, a download that only changes tag names (not offsets or data types) is treated as a non-initializing update. This is documented in the Siemens KB article 109751498 ("S7-300/S7-400 software update during RUN"). It is, however, limited in scope and does not help when a brand-new tag is being added that shifts offsets.

STEP 7 V5.x vs TIA Portal Behavior

Engineers migrating from SIMATIC Manager (STEP 7 V5.5 / V5.6) sometimes report that the issue "did not exist" there. In practice the underlying firmware behavior is the same — a DB whose interface changes is re-initialized in work memory. The difference is workflow:

• STEP 7 V5.x had a more explicit "Download block" step that the engineer performed one block at a time. The buffer-DB workaround was easier to follow because block-level operations were first-class.
• TIA Portal batches the download of the program, all system data, and all changed blocks in a single transaction, and triggers an implicit CPU restart. The user is less aware that a STOP→RUN is happening.
• TIA Portal's "Download to target device" with the option "Consistent download of all blocks" makes the implicit restart unavoidable for any modified DB.

The root firmware behavior is identical; only the visibility of the workaround has changed. The Siemens KB 18652631 entry "What happens to the values of data blocks after a download?" explicitly documents this design.

DB Design Best Practices for Live Processes

Programmatic Recovery: OB100 Reload

If a download has already happened and process values have been lost, the values can be reconstructed in OB100 (startup OB) from an external source. The OB100 runs on every STOP→RUN transition, including the one caused by the download.

// OB100 - Complete Restart
// Restore last known recipe from a passive backup DB kept on MMC
// 1. Read record from MMC
// 2. Write to DB_Recipe
// 3. Set initial done flag
      CALL  "RDREC"
            REQ    := TRUE
            LADDR  := 0
            RECNUM := 1
            RET_VAL:= MW200
            BUSY   := M201.0
            RECORD := P#DB_Recipe.DBX0.0 BYTE 400;

This pattern is mandatory for any S7-300 process that cannot tolerate a download-induced reset, and it is the cleanest separation between the development DB and the runtime DB.

Verification Steps

1. Select the modified DB in the project tree.
2. Compile → Software (rebuild all). There must be no errors.
3. Online → Download to device → Software (all).
4. Open the diagnostic buffer; confirm the entry "Download of block DB<n> completed" and note the time delta to the next entry.
5. Open Monitor/Modify on the DB and check the previous live value (a counter, a setpoint, a state byte). If the value persists, the workaround is working. If it has reset, inspect OB100, OB101, and the project tree for a hidden copy of the DB being re-initialized.
6. Trigger a HMI read of one of the preserved tags and confirm the HMI shows the expected live value.

Troubleshooting Matrix

FAQ