Siemens S7 Data Block Initial vs Actual Value Download Behavior

Overview

When a SIMATIC S7 PLC downloads a Data Block (DB), engineers frequently observe that runtime "actual" values get replaced by the "initial" values declared offline. The behavior is intentional and is governed by the load memory, work memory, and retentive memory model that the S7-300, S7-400, S7-1200, and S7-1500 families all share. This reference documents the exact memory model, distinguishes the three different "initial" value locations, walks through the four common download scenarios, and provides field-proven procedures to preserve operator-entered setpoints across re-downloads, online edits, cold/warm restarts, and MRES. The same procedures apply to STEP 7 V5.x and to TIA Portal, with menu and dialog differences called out explicitly.

Two symptoms drive most service tickets:

1. An operator enters a setpoint from an HMI, the engineer re-downloads the DB to the CPU, and the setpoint reverts to 0 (or to the declared start value).
2. The engineer uploads the project to recover the lost setpoint and accidentally promotes a runtime value to a permanent engineering default, which then locks into every subsequent download.

Both symptoms are correct CPU behavior, but they are almost always undesirable. The fix is to combine the right memory model configuration with the right engineering tool workflow.

S7 Memory Model and Where DBs Live

Every S7 CPU implements a tripartite memory layout that directly controls what happens to a DB on download. Understanding the three layers is the foundation of the rest of this document. Reference the S7-1200 and S7-1500 system manuals on the Siemens Industry Online Support portal for the byte-exact memory map of your specific CPU.

• Load memory (Flash / MMC / SIMATIC Memory Card): Non-volatile. Holds the project as compiled by the engineering software, including the start values declared in the offline DB. Survives power loss, CPU STOP-RUN transitions, and MRES (when not formatted).
• Work memory (RAM): Volatile. Holds the live "actual" values the user program reads and writes. Cleared on cold restart and on MRES.
• Retentive memory (subset of work memory): Non-volatile across a warm restart and a power cycle. Configured per tag or per memory area (M, T, C, DB).

When a DB is downloaded, the engineering tool writes the block to load memory only. The values in work memory are overwritten depending on which download option is selected. This distinction is the root cause of every setpoint loss reported in field service.

Three "Initial" Value Definitions You Must Distinguish

Siemens documentation uses the term "initial value" in three different places. Conflating them is the source of the bulk of confusion in field tickets. The semantics differ between STEP 7 V5.x and TIA Portal but the underlying storage model is identical.

1. Start value / Initial value (declaration view): The value you type in the "Start value" column of the DB declaration in TIA Portal, or the "Initial Value" column in STEP 7 V5.x. This is the developer's intent. It is stored in the offline project and is written to load memory at the time of download.
2. Initial value (load memory): The byte-for-byte image of the DB that the CPU keeps in its flash or MMC. This is what replaces actual values when the CPU does a cold restart or when the DB is re-downloaded with the "initial values only" option.
3. Actual value (work memory): The live, current value the user program reads. It can be modified by the program, by HMI, by online test, or by an online download of a single value. It is cleared on cold restart unless the tag is retentive.

The relationship is most clearly seen in the online view of a DB. In TIA Portal the right pane shows three columns: "Name", "Data type", "Start value". When the CPU is online the lower pane shows "Monitor value" or "Actual value" - the runtime value currently in work memory. In STEP 7 V5.x the declaration view shows "Initial Value"; the data view shows "Actual Value".

Download Behavior — Four Real-World Scenarios

The following four scenarios map to the exact observations reported in the field. They are reproduced here as a reference matrix so the engineer can locate the right symptom without reading the full procedure.

Scenario A — First download of a new offline project

The offline project has start value = 0 (the TIA default for INT and REAL). The DB is downloaded to the CPU. Both load memory and work memory receive 0. The CPU starts with actual values of 0. This is the expected behavior and is the correct baseline for a freshly commissioned machine.

Scenario B — HMI writes a setpoint, then the engineer re-downloads the DB

Operator enters setpoint = 75.0 from the HMI. The value lives only in work memory. The engineer right-clicks the DB and selects "Download to device" without enabling the "initial values only" option. STEP 7 or TIA Portal overwrites the actual values in work memory with the values from load memory, which are still the start values. The setpoint reverts to 0 (or to whatever the declaration view said). The HMI display flickers and the operator calls support.

Scenario C — Upload from device after the HMI setpoint change

With actual value = 75.0 in work memory, the engineer uses "Upload from device" (TIA Portal) or "PLC - Upload Station to PG" (STEP 7 V5). The offline PG image now reflects the actual value: the start value field in the declaration shows 75.0, and the offline/online comparator reports "identical" for the DB. The PG image has been permanently altered.

Scenario D — Download the uploaded project back to the CPU

The offline DB now has start value 75.0. On download, load memory is overwritten with 75.0 and work memory is initialized from load memory, so the actual value remains 75.0. No setpoint loss is visible - but the engineer has unintentionally promoted a runtime value to a project start value. Subsequent code changes that download the DB will lock in 75.0 as the new default, even if the operator changes it to 80.0 next shift.

Capturing and Preserving Runtime Setpoints

The engineering tool exposes explicit menu functions to control value transfer between the offline image, load memory, and work memory. The exact menu path differs between STEP 7 V5.x and TIA Portal but the underlying operation is the same: read actual values from work memory, write them into the declaration's start value column, save the project, and download.

STEP 7 V5.x (S7-300 / S7-400) — capture and persist

1. Open the DB in the editor and go online ("Online - Monitor").
2. Switch to the data view. The right-hand column now shows actual values in the CPU.
3. Select all rows (Ctrl+A), then use menu Edit - Initialize actual values. This overwrites the work-memory image in the editor with the values from the "Initial Value" column. It does not yet persist them.
4. To promote actual values to start values, use Edit - Set as initial value (some versions label this "Actual value - Set as initial value"). The start values in the declaration view are overwritten with the runtime values.
5. Save the project (Ctrl+S) and then use PLC - Download to push the new start values to load memory.
6. Optionally use PLC - Copy RAM to ROM to ensure the changes are written to the MMC in addition to work memory.

TIA Portal (S7-1200 / S7-1500) — snapshot procedure

1. Open the DB in the project tree. Confirm the CPU is online (status bar at the bottom right).
2. Right-click the block in the project tree or inside the open editor and choose Snapshot of actual values. The runtime values currently in work memory are written into the start value column of the offline DB.
3. Save the project (Ctrl+S). The offline PG image now reflects the live setpoint.
4. Use Online - Download to device with the option "Download to device" (not "Initial values only") to push the snapshot into load memory.

Download options that affect actual values

Retentivity — The Real Persistent Store

Retentive tags are the only values that survive a power cycle without depending on the upload/download sequence. Use them for setpoints you never want to lose, even if the engineering PC corrupts the offline project. Retentivity is configured in two places: the CPU's hardware configuration (for memory areas) and the DB tag properties (for individual tags).

S7-300 / S7-400 retentive configuration

• Open the CPU in HW Config and select Properties - Retentive Memory. The dialog accepts a starting address and length for M (merker), T (timers), C (counters), and DB areas.
• For DBs, the entire DB can be declared retentive by adding it to the "Retentive" check box list in the same dialog, or individual tags can be marked retentive using the "Retain" column in the DB declaration (available from STEP 7 V5.4 SP5 onward via NCM / NetPro patches).
• The retentive area is preserved across a warm restart and a power cycle. It is cleared by MRES and by a cold restart configured in the CPU properties.

S7-1200 / S7-1500 retentive configuration

Open the DB, select a tag (or Ctrl+A for all), and set the "Retain" column to "Set" in the properties pane. The compiler reserves the tag in the retentive area of work memory. Power cycle, STOP-RUN, and MRES do not clear it (with the exception of the explicit "Reset to factory settings" command on S7-1500 V16+).

Instance DBs, Global DBs, and Their Value Behavior

The same start-value-vs-actual-value model applies to instance DBs (DBs created automatically for a Function Block call) and to global DBs (the ones engineers create with "Add new DB"). Two differences are worth knowing:

• Instance DB: Stores the static variables of a single FB instance. The start values in the FB source are inherited when the instance DB is created. Subsequent changes to the FB start values are propagated to existing instance DBs only via a recompile + reload. Online edits to the FB do not touch existing instance DBs.
• Global DB: Stores tags declared directly in the DB. Changes to the start values propagate to the offline DB on the next compile, but do not propagate to the running instance until the DB is downloaded.
• Multi-instance DB: A single DB holds static data for multiple FB instances. Same value model as instance DB; useful for keeping all function-block state in one retentive block.

For setpoints, prefer a global DB. For runtime state of an FB (counters, latches, edge bits), prefer an instance DB. The retention column in the DB tag list applies identically to both.

HMI Recipe and External Storage Strategies

For machine constants that change between product variants, the recommended pattern is to keep the engineering DB neutral and store the variable setpoints on the HMI or in an external recipe file. The PLC reads them on startup via a download command from the HMI. The DB itself never carries a "live" value - it is initialized to a known engineering default and overwritten at runtime.

Pattern 1 — HMI recipe on a Comfort Panel / WinCC

1. Configure the recipe on the panel with the same tag layout as the DB. Use the symbolic PLC tag name as the recipe element name to keep mapping trivial.
2. On power-up, the panel sends the recipe data to the DB tags using a tag trigger or a job interface (area pointers 67-69 on S7-300/400, the equivalent job interface on S7-1500 panels).
3. Operator edits are saved to the panel's internal flash (or an SD card) and never touch the engineering project.

Pattern 2 — Recipe on the operator PC (WinCC Professional / TIA)

Use the WinCC recipe view with a connection to the PLC. Setpoints are stored as CSV or XML on the PC and pushed to the DB tags on demand. Survives CPU MRES, CPU replacement, and corrupted offline projects. The recipe file itself is part of the engineering backup and is under version control.

Pattern 3 — File on a shared network drive

For legacy systems without a capable HMI, store the setpoint DB as a CSV file on the engineering server. A startup OB (OB100 for warm restart, OB102 for cold restart) reads the CSV via a custom function block and writes the values to the engineering DB. The DB itself keeps default values; the CSV is the source of truth. This pattern is fragile against file-server outages and should be reserved for brownfield sites.

SCL example: CRC-16 over the setpoint area

Add a WORD at the end of the setpoint DB and compute a CRC over the setpoint area in OB1. A non-matching CRC triggers an HMI warning that prompts the operator to re-enter the recipe. This is the cheapest way to detect silent corruption of the setpoint area.

// SCL: CRC-16 over the setpoint DB area, called from OB1
// Assumes a DB "DB_Setpoints" with a "CRC_Offset" INT and a "CRC_Value" WORD
#iMaxByte := DB_Setpoints.CRC_Offset;
#wCRC := WORD#16#FFFF;

FOR #iByte := 0 TO #iMaxByte - 1 DO
    #bTemp := DB_Setpoints.[%DBB#iByte];
    FOR #iBit := 0 TO 7 DO
        IF ((#wCRC XOR #bTemp) AND WORD#16#0001) <> WORD#16#0000 THEN
            #wCRC := SHR(IN := #wCRC, N := 1) XOR WORD#16#A001;
        ELSE
            #wCRC := SHR(IN := #wCRC, N := 1);
        END_IF;
        #bTemp := SHR(IN := #bTemp, N := 1);
    END_FOR;
END_FOR;

IF #wCRC <> DB_Setpoints.CRC_Value THEN
    "HMI_AlarmSetpointCorrupt" := TRUE;   // trigger operator warning
END_IF;

The CRC is written into the DB at the end of the recipe download job. The OB1 CRC check runs every cycle, so any single-bit corruption (EMC, RAM failure, MMC aging) is detected within a few milliseconds and the HMI can prompt the operator to re-send the recipe before the next production cycle.

Online Editing Caveats — Monitor/Modify and Force

Two online functions are routinely misused and lead to setpoint loss incidents.

Monitor / Modify (V5) and Monitor & Force (TIA)

These dialogs write to the work memory only. They do not write to load memory, do not mark the value as retentive, and do not propagate to the offline project. A power cycle, a cold restart, or a DB download wipes the modified value. Use Monitor/Modify for commissioning checks only; never as a "set the setpoint" tool in production.

Force tables

Forcing a tag overrides the user program but does not persist. A STOP-RUN transition clears the force. On S7-1500, force values can be retentive if the tag is configured with the "Set in IDB" option, but this is the exception, not the rule. The presence of force entries is shown in the diagnostics buffer and is a common reason for "setpoint works only when the engineer is connected" reports.

Watch tables

Watch tables are read-only by default. They cannot modify values. The "Modify" column in a watch table writes to work memory, with the same caveat as Monitor/Modify.

Verification Procedure

1. Place the CPU in STOP via the programming software (or via the mode switch on the CPU).
2. Open the DB in online view and confirm the displayed values match the operator's last entry. If they do, the values are in work memory but not yet in load memory.
3. Use Snapshot of actual values (TIA Portal) or Edit - Set as initial value (STEP 7 V5) to promote them to start values.
4. Save the project to the engineering server.
5. Perform a "Download to device" of the entire station. Place the CPU in RUN. Verify the values are still present.
6. Power-cycle the cabinet (turn off the main breaker for 30 seconds). Restore power. Verify the setpoints are intact.
7. Trigger an MRES via the mode switch. Restore the recipe from the HMI. Verify the setpoints are restored to the operator's last values, not to the engineering defaults.

If the setpoints disappear at step 5, the DB tags are not retentive and the load-memory download is overwriting them. If they disappear at step 6, the retentive configuration is missing. If they disappear at step 7, the HMI recipe path is broken and the engineering project is the only source of truth - which is the failure mode the recipe pattern was designed to avoid.

Troubleshooting Matrix

Best Practices and Field Rules

• One DB per concern: Keep setpoints, machine constants, and runtime counters in separate DBs. Apply retentivity only where needed. A single 4 KB DB with 80 retentive tags and 200 non-retentive tags is a debugging hazard; three 1 KB DBs with clear boundaries are not.
• Upload before every download: "Upload from device" is the cheapest insurance against a wiped setpoint. Make it a rule: no download without a prior upload to a timestamped project folder.
• Always snapshot before a code deployment: Use "Snapshot of actual values" (TIA Portal) or "Edit - Set as initial value" (STEP 7 V5) right before a planned shutdown. The snapshot becomes the engineering baseline for the next shift.
• Use a checksum tag: Add a WORD or INT at the end of the setpoint DB and compute a CRC over the setpoint area in OB1. A non-matching CRC triggers an HMI warning that prompts the operator to re-enter setpoints. The SCL example in this article implements the canonical CRC-16/Modbus polynomial.
• Document the source of truth: Label each tag with comments indicating whether it is "engineering default" or "operator setpoint". Review this list in code reviews. A tag without a documented source of truth is a tag that will be misdiagnosed in the next incident.
• Test the MRES path at commissioning: On a non-production CPU, perform a memory reset and verify that the documented recovery path (HMI recipe, CSV file, engineering upload) actually restores setpoints. Document the test in the SAT (Site Acceptance Test) report.
• Do not rely on online value modification alone: Monitor/Modify writes to work memory only. A restart wipes it unless the tag is retentive. If you find yourself doing Monitor/Modify at every shift change, the system needs a proper recipe mechanism.
• Lock the engineering project: Use TIA Portal's "Project protection" or STEP 7 V5's "Know-how protection" on the FB that handles setpoint storage. This prevents operators with a programming cable from accidentally re-typing start values that propagate to the offline project.
• Retentive tag count is limited: Each CPU has a maximum number of retentive tags. S7-1214C, for example, supports up to 10 KB of retentive data. S7-1516 supports up to 768 KB. Check the CPU's technical data sheet for the exact number; exceeding the limit causes a compile error or a runtime load failure.
• Keep the engineering DB read-only from the HMI: HMI writes should target a separate "operator setpoint" DB. The engineering DB is only modified from the programming software. This separation prevents Scenario D from ever occurring.

Frequently Asked Questions