Siemens S7 Data Blocks: DB vs M Memory and Retentivity Guide

Siemens S7 Data Blocks: DB vs M Memory, Retentivity, and HMI Integration

Data blocks (DBs) are the principal named memory containers in the Siemens S7-300, S7-400, S7-1200, and S7-1500 families. They coexist with the simpler M (flag) memory area, but they differ structurally, semantically, and in their behavior across power cycles. This reference explains what a data block is, how it differs from M memory, when to use each, and how the retentive and initial-value mechanisms apply during loading, restart, and warm restart of the CPU.

1. What Is a Data Block?

A Data Block (DB) is a logically grouped area of the CPU's work memory that holds user data structured by a declaration. Each element inside the block has a defined type (BOOL, INT, REAL, ARRAY, STRUCT, etc.) and an address that the program accesses symbolically or absolutely. In the IEC 61131-3 model used by Siemens, a DB is the equivalent of a tag table or global variable list that has been compiled into the user program.

Formally, a data block is a block of bits whose length equals the size of the declared data structure - in the cryptographic sense the term comes from operating-system and storage theory where a block is "a sequence of bytes or bits, usually containing some whole number of records, having a fixed length" (Block (data storage) - Wikipedia). The NIST Computer Security Resource Center defines a data block in the same terms: "a sequence of bits whose length is the block size" (Data Block - CSRC Glossary). In Siemens PLCs the same word is reused for an IEC 61131-3 user data structure.

Three fundamental block types exist in the S7 system:

• Organization Blocks (OB) - the CPU's program entry points (OB1 for the main cyclic scan, OB100 for warm restart, OB101 for hot restart, OB102 for cold restart, OB82/OB86/OB122 for error handling).
• Function Blocks (FB) and Functions (FC) - the executable code units.
• Data Blocks (DB) - the data containers associated with the program.

DBs come in two principal variants:

• Global DB (also called "DB" in STEP 7 V5.x or "Global data block" in TIA Portal) - declared once, accessible from any code block in the program.
• Instance DB - automatically generated when an FB is called with a background DB; the instance DB stores the static data of that specific FB call.

Reference: Siemens Industry Online Support - entry ID 109751433, "Programming and operating manual STEP 7 Basic/Professional".

2. DB Memory Layout and Address Syntax

Inside a DB every byte has an absolute address and a symbolic tag. The access syntax depends on the CPU family.

Symbolic access is preferred on S7-1200/1500 because TIA Portal enforces it in many programming languages (SCL, GRAPH). On S7-300/400, absolute access is the historical default and remains available for compatibility with installed code.

3. DB vs M Memory: When to Use Each

The M area (also called flag memory or merker memory) is a flat byte-addressed range located in the CPU's work memory. The default size is 256 bytes on a CPU 315-2 PN/DP and 8192 bytes on an S7-1516, with part of the range declared as retentive. The M area is intended for short-lived, low-level scratch flags that exchange signals between code blocks. It has no declaration, no initial value, and no structure.

The DB is the equivalent of a typed structure: a recipe table, a set of machine parameters, the working storage of an FB. The DB can be referenced symbolically, exported as a UDT, downloaded separately from the program, monitored, and force-modified without recompilation.

Rule of thumb used by senior STEP 7/TIA Portal engineers:

Use M memory only for single-bit handshakes, edge flags, and intermediate Boolean results. Use a DB for everything that has meaning, value, or a name an operator will see on the HMI.

3.1 Concrete Example: db1.dbb1 vs mb1

Both DB1.DBB1 and MB1 resolve to byte 1 in their respective memory areas. The differences are:

• Location - DB1.DBB1 is byte 1 inside the work memory of data block 1; MB1 is byte 1 of the flag area.
• Initial value - DB1.DBB1 is initialized to whatever value the declaration view specifies; MB1 starts at 16#00 (or the retentive last value).
• Symbolic name - DB1.DBB1 can be tied to a symbol such as Recipe.Slot[0].Temperature; MB1 typically carries a one-word symbol such as Edge_Memory.
• HMI connection - TIA Portal and WinCC automatically pick up the structured DB tag; M flags must be added manually to the HMI tag table.

4. Initial Value vs Actual Value

Every tag inside a global DB has two values associated with it in STEP 7 / TIA Portal:

• Initial value (Startwert / Initial value) - the value defined in the declaration view and stored in load memory. This is the value the CPU writes into work memory at the end of the start-up OB (OB100/101/102).
• Actual value (Istwert / Actual value) - the value currently held in work memory after the program has executed. It is the runtime value.

Behavior across CPU operating states:

To monitor both values in TIA Portal, open the Watch table with the DB in question, right-click the tag, and switch the display between "Initial value" and "Actual value". In STEP 7 V5.x this is done via Monitor/Modify > Data block with the Initial values toggle.

5. Retentivity of Data Blocks

Retentivity defines which tags keep their value across a power cycle or STOP->RUN transition. On S7-300/400 the retentive area is configured under CPU Properties > Retentive Memory as a range of bytes (e.g. MB0..MB15, DB1.DBW0..DB1.DBW200). On S7-1200/1500 the retentive area is set per tag inside the DB: open the DB, switch to the Retain column, and tick the box for each tag that must survive a power cycle.

The retentive memory is implemented in a battery-backed or non-volatile section of the CPU (NVRAM on S7-1500, MMC-backed on S7-1200 from firmware V4.4). Maximum retentive sizes are documented in the CPU datasheet; for example, the S7-1516-3 PN/DP allows up to 472 KB of retentive DB data.

5.1 How to Verify That a DB Is Retentive

1. Open the DB in TIA Portal.
2. Right-click the column header and select Show/Hide > Retain.
3. For each tag set the Retain checkbox (Set in IDB) for tags that should keep their value.
4. For S7-300/400: open CPU Properties > Retentive Memory and confirm the DB byte range is included in the retentive area.

5.2 Alternatives to Retentive DBs

When a DB cannot be made retentive (e.g. on a CPU whose NVRAM is full), the following options exist:

• Store on MMC / SIMATIC Memory Card - use RecipeSave from the Recipe library or write the data to a file on the SD card via FileHandleC (S7-1500).
• Use the system DB for data logging - DataLogWrite (S7-1500, firmware V1.8+) writes to CSV files on the SD card.
• Remanent M area - declare a number of MB flags as retentive on the CPU and copy the OP panel data into MB at the end of OB100.
• Non-volatile PLC tags (S7-1500) - the entire PLC tag table supports a Retain attribute, which is functionally equivalent to a global DB with retentive tags.

Reference: Programming and Operating Manual - SIMATIC S7-1500 with TIA Portal (Siemens).

6. Using DBs with HMI Panels (OP/TP/WinCC)

Reading from and writing to a data block is the standard way to expose process data to an operator panel such as an OP17, TP177, KTP1200, Comfort Panel, or WinCC Runtime Advanced. The connection is direct because the HMI tag table accepts the absolute DB address or, in TIA Portal, the symbolic tag name.

6.1 STEP 7 V5.x and ProTool/OP17

1. In STEP 7, create a DB (for example, DB100) and declare the tags that the operator will read or write.
2. In ProTool/Pro, open the tag editor and add a tag pointing to DB100.DBW0 as an input/output field, or DB100.DBX0.0 as a button.
3. Wire the tag to a screen object; the value entered on the OP is written into the DB and is immediately available to the PLC program.

6.2 TIA Portal and Comfort Panel

1. Create a global DB (for example, "Recipe_DB") with the data structure.
2. In the HMI tag table, click Add new tag > PLC tag; the editor shows the symbolic structure of the DB.
3. Drag the tag onto an I/O field; the panel reads and writes the tag without any address arithmetic.

This is the recommended pattern. M flags are not preferred because every additional HMI tag adds to the configuration effort and offers no symbolic documentation.

7. DB Use Cases in Real Programs

7.1 Recipe Storage

The classic application. A recipe is a setpoint package (temperature, time, speed) loaded by the operator. Store the recipe in a DB declared as an ARRAY of STRUCT. The array index is the recipe number; the elements are the parameters. The DB can be made retentive so the operator's edits survive a power cycle.

// TIA Portal SCL example
DATA_BLOCK "Recipes"
{ S7_Optimized_Access := 'TRUE' }
AUTHOR : 'Eng'
VERSION : 0.1
NON_RETAIN
VAR
  Slot : ARRAY[1..50] OF STRUCT
    Temperature : REAL := 80.0;
    Duration_s  : INT  := 120;
    Speed_pct   : INT  := 50;
  END_STRUCT;
END_VAR
END_DATA_BLOCK

7.2 Indirect Addressing with Arrays

DBs are the natural home for arrays because the access DB[index].Element is symbolically clean. The IEC check on the index prevents out-of-bounds reads on optimized DBs (S7-1500), making it safer than bit-twiddling M flags.

7.3 Instance DBs for FBs

When an FB is created with a multi-instance capable declaration (static VAR section), the FB's internal state lives in an instance DB. The instance DB is created automatically at the first call or by clicking Generate instance DB. On S7-1500 the multi-instance model means a single DB holds the data of all FB instances of the same parent FB.

7.4 Hand-Over Areas Between PLC and SCADA

A common pattern is to expose a DB with a fixed layout as the SCADA hand-shake area. The SCADA writes commands into one half, the PLC writes status into the other half, and a handshake word toggles to acknowledge the new data. This avoids the proliferation of M flags and gives the SCADA library a single source of truth.

8. Optimized vs Standard Access (S7-1200/1500)

On S7-1200 and S7-1500 each DB can be set to Optimized block access (default since TIA Portal V13) or Standard access (compatible with S7-300/400). The differences matter for any code that uses absolute addressing.

For new projects, keep optimized access. For migration projects with many absolute addresses, switch to standard access or rewrite the address logic symbolically.

9. Diagnostics and Common Errors

10. Best Practices

1. Use symbolic access on S7-1200/1500 projects. Avoid absolute addresses inside optimized DBs because the compiler may reorder memory.
2. Set retentivity per tag on optimized DBs. Reserve retentive memory for data that must survive a power cycle, not for convenience.
3. Prefer a global DB over scattered M flags for any value that has operator or maintenance meaning.
4. Use a UDT (User-Defined Type) for repeated structures. Declare a UDT once, instantiate it inside a DB as an ARRAY, and the HMI picks it up symbolically.
5. Document the DB layout in the DB header comment and in the watch table. A new commissioning engineer should be able to understand the data flow from the DB comment alone.
6. Verify retentivity on first commissioning. Power-cycle the CPU with the plant in a known state and confirm that the operator's recipe values return intact.
7. When migrating from STEP 7 V5.x to TIA Portal, convert each DB to a UDT where possible; this makes the structure reusable across multiple instances.
8. Keep the number of M flags small. Reserve MB0..MB15 for handshake bits and use the DB for everything else. This rule is taught in Siemens ST-7PRO1 and ST-7PRO2 training and is the de facto standard on S7-300/400 installations.

11. Procedure: Creating a Global Data Block in TIA Portal

11.1 Prerequisites

• TIA Portal V16 or later installed.
• S7-1200 or S7-1500 CPU added to the project (S7-1500 recommended for the full retentivity model).
• Program blocks folder with at least one code block such as OB1 "Main".

11.2 Step-by-Step

1. In the project tree, expand PLC_x > Program blocks.
2. Double-click Add new block > Data block (DB).
3. Choose Global DB (not Instance DB) and click OK.
4. In the new DB editor, declare the variables. For each row, set name, data type, and default value.
5. To enable per-tag retentivity, right-click a column header, choose Show/Hide > Retain, and tick the box for the tags that must survive a power cycle.
6. Save and compile (Ctrl+B).
7. Download to the CPU. The prompt "Do you want to initialize retentive data?" - select No if the current values must be kept.
8. Open a watch table, add the DB tags, and click Monitor all to confirm the actual values match the expected values.

11.3 Verification

• Confirm that the declared tags appear in the PLC tag table and can be browsed from the HMI configuration.
• Power-cycle the CPU and confirm that retentive tags keep their values and non-retentive tags return to the initial value.
• Use Online > Diagnostics > Memory to check the usage of the retentive memory area against the CPU's maximum.

12. Reference: Memory Areas in the S7 CPU

For context, the full set of S7 memory areas is:

• I / Q (Process Image) - inputs and outputs, refreshed at the start and end of OB1.
• M (Flags / Merker) - flat working memory, part retentive.
• DB (Data Blocks) - structured, typed, symbolic data, partially retentive.
• L (Local / Temp) - per-block scratch memory, not retentive, lost when the block exits.
• PI / PQ (Peripheral I/O) - direct I/O access bypassing the process image.
• T / C / Z (Timers, Counters, IEC counters) - system function memory.

Local data is the only area that resets on every block call. Retentive DB tags are the only user data that survives a power cycle. M flags are the only flat, byte-addressable, fast area for handshakes.

Reference documentation: Siemens Industry Online Support, search IDs 109751433 (S7-1500), 91696622 (S7-1200), 18652696 (STEP 7 V5.5 system manual). See also the IEEE / IEC 61131-3 standard for the formal definition of the data block concept in PLC programming.

Frequently Asked Questions