Siemens S7 Data Blocks: Architecture and Programming Reference

Data Blocks (DBs) are the backbone of user data organization in SIMATIC S7-300, S7-400, S7-1200, and S7-1500 controllers. Unlike controllers that expose a flat tag database to the application (Allen-Bradley ControlLogix/CompactLogix, Schneider Modicon M340/M580), S7 separates program blocks (OBs, FBs, FCs) from data blocks that contain the variable storage the program reads and writes. Understanding how DBs are loaded, addressed, sized, and bounded by firmware limits is essential before designing any non-trivial S7 application.

This reference consolidates the architectural reasoning behind DBs, the practical limits enforced by STEP 7 / TIA Portal, the difference between shared DBs and instance DBs, and the field-proven techniques for indirect addressing, multi-instance reuse, and H-system (fault-tolerant) deployment.

1. S7 Memory Architecture Overview

Every S7 CPU implements three distinct memory areas:

The defining constraint is work memory. A representative S7-300 CPU 315-2DP exposes only 128 kB of work memory, while an S7-400 CPU 417-4H provides 32 MB and a CompactLogix L63 provides 4 MB of user-tag memory. The DB mechanism is Siemens' solution for fitting large structured data into a small RAM footprint: only the DB that the program is currently calling occupies work memory; the remainder stays compressed on the load memory medium.

2. Data Block Types

STEP 7 and TIA Portal distinguish four categories of DB. Selecting the correct type is the first design decision when structuring a project.

2.1 Shared (Global) Data Blocks

A shared DB is a user-defined STRUCT that any FB, FC, or OB can read and write via symbolic or absolute addresses. Shared DBs are typically numbered 1 through 60,999 (the exact range depends on firmware). Use shared DBs for:

• Process images that survive across OB1 cycles (recipe data, setpoints, mode flags)
• Communication buffers shared between cyclic and interrupt OBs
• HMI-mapped tag containers that the panel polls via PUT/GET or S7 communication

Declaration example in TIA Portal (data view):

DATA_BLOCK "DB_Process"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
  STRUCT
    iSetpointRPM   : INT  := 1500;   // motor setpoint
    rActualFlow    : REAL := 0.0;    // measured flow L/min
    bValveOpen     : BOOL := FALSE;
    sRecipeName    : STRING[32];
    aAlarmFlags    : ARRAY[1..32] OF BOOL;
  END_STRUCT;
END_DATA_BLOCK

2.2 Instance Data Blocks

An instance DB holds the static and temporary variables of one specific call of an FB. Every time an FB is called, the runtime assigns a unique instance DB (or, for multi-instance FBs, a slot within a parent instance DB). The FB code references variables symbolically; the instance DB owns the actual bytes.

Numbering convention: instance DBs are typically assigned in the range reserved by the CPU firmware, often starting at 1 and overlapping with shared DBs in TIA Portal but stored in separate firmware-managed tables internally. Multi-instance FBs share one parent DB.

2.3 System Data Blocks (SDB)

System data blocks are written by STEP 7 / TIA Portal and contain CPU configuration: hardware parameters, communication connections, OB priorities, and diagnostic settings. Engineers rarely edit SDBs directly; the engineering tool regenerates them on every download. Loading an SDB triggers a CPU restart in most cases.

2.4 Type CPU-DB (H-System Configuration)

On S7-400 fault-tolerant CPUs (S7-417-4H), the H-system uses a special Type CPU-DB to synchronize redundant partners. This DB stores the link-up parameters, redundant I/O configuration, and runtime synchronization metadata. Mismatches between the H-master's project and the standby CPU's project manifest as a Type CPU-DB consistency error and break H-link on startup. Always download both H CPUs together and confirm the project comparison report before any online operation.

3. Load Memory vs. Work Memory: Why DBs Exist

The DB model directly maps to dynamic memory allocation in C/C++. The CPU treats each DB as a struct that:

1. Is compressed on the MMC/SIMATIC Memory Card (load memory).
2. Is expanded into RAM (work memory) only when an OB/FB/FC calls it or when an absolute address is touched.
3. Is freed back to the work-memory pool when the call returns and no active job references it.

This lazy allocation is what permits an S7-315-2DP (128 kB work memory) to host projects whose total DB payload exceeds that figure, provided peak usage fits. The same memory model is what allows an S7-1500 CPU 1515-2 PN (500 kB work memory for code, 3 MB for data) to handle tens of thousands of tags without exhausting RAM.

Consequence for the programmer: if you keep a pointer to a DB's contents in a static variable, the runtime cannot unload the DB. Holding a "global handle" to a DB defeats the paging model. Prefer symbolic, scoped access through FBs.

4. Comparing S7 DBs with Other PLC Tag Models

The Logix architecture avoids the DB concept entirely because Logix CPUs treat the entire tag database as one flat, scope-controlled object. The trade-off is that every tag consumes work memory permanently. S7's design preserves work memory at the cost of explicit block management.

5. Configuring DBs in STEP 7 (Classic) and TIA Portal

5.1 Classic STEP 7 V5.x

1. Open the S7 project in SIMATIC Manager.
2. Insert > S7 Block > Data Block.
3. Assign a number (DB 1 to DB 60,999 for shared DBs) and a symbolic name.
4. Choose Shared DB or Instance DB. For instance DBs, the FB must already exist.
5. Declare variables in the data view; assign initial values for load memory.
6. Save, compile, and download. The runtime loads the DB on first call.

5.2 TIA Portal V16-V18

1. Project tree > PLC_1 > Program blocks > Add new block > Data block.
2. Select "Global DB" or "Instance DB" and assign a name. For optimized access, leave "Optimized block access" enabled (default on S7-1200/1500). Disable only when interfacing to legacy S7-300/400 blocks that use absolute addressing.
3. Declare structure members with IEC types. Mark retentive tags with the "Retain" column flag for S7-1200/1500 or set the Retentivity attribute for S7-300/400.
4. Compile and download; the runtime builds the DB header and slot table.

6. Accessing DB Data

6.1 Symbolic vs. Absolute

6.2 Opening a DB for Indirect Addressing (STL)

Indirect access requires STL or SCL because LAD/FBD cannot express variable offsets.

// Iterate through a 32-element BOOL array in DB "DB_AlarmFlags"
OPN   DB ["DB_AlarmFlags"]           // open DB by symbolic name (TIA)
L     0
T     #iLoopIdx                      // loop counter, INT
NEXT: L     #iLoopIdx
      JL    END_LOOP                  // conditional jump if counter valid
      L     DIX [#iLoopIdx]           // read DBX 0.0 + iLoopIdx bit
      S     #bAnyAlarm
      L     #iLoopIdx
      +     1
      T     #iLoopIdx
      L     32
      <I                            // counter < 32 ?
      JC    NEXT
END_LOOP: NOP 0

The OPN instruction binds DB register 1 (or 2 for DI) to the opened block; all subsequent DIX/DID/DBB/DBW/DBD instructions operate within it. Failure to OPN before indirect access raises OB121 (programming error) and the CPU goes STOP if no error OB is configured.

7. Multi-Instance FBs and Reuse

When an FB calls other FBs as local instances, the called FBs do not consume additional instance DBs. Instead, their data is allocated inside the parent's instance DB. Multi-instance FBs are the recommended pattern for modular machine code because they:

• Eliminate DB numbering conflicts.
• Allow parameter passing by reference without copying large structs.
• Enable library versioning with type compatibility in TIA Portal.

Implementation in TIA Portal: in the FB's static section, declare variables of the called FB type. The compiler nests the data layout automatically. In classic STEP 7, enable the "Multiple instance capability" attribute on the called FB.

8. Firmware Limits and the 1200-Instance DB Boundary

S7-300 and S7-400 CPUs enforce a hard maximum on the number of instance DBs allocated at runtime. On most S7-300 CPUs, the maximum is 1024 instance DBs, while S7-400 CPUs allow up to 4096. TIA Portal's S7-1500 CPUs scale higher but enforce analogous limits per firmware version.

When the runtime exceeds the permitted count, the CPU writes diagnostic buffer entries of the form:

The Siemens SiePortal case where the number of instance DBs intended for S7 communication (1425) was greater than the maximum permitted (1200) is a textbook symptom. The fix is structural: replace per-instance copies of the communication FB with one multi-instance container, or split the project across multiple CPUs.

9. Type CPU-DB on S7-400H Systems

S7-417-4H redundant CPUs maintain a Type CPU-DB that holds the link-up, synchronization, and partner IP information. If the standby CPU has a project whose Type CPU-DB does not match the master byte-for-byte, link-up fails with diagnostic buffer entries pointing to the inconsistent DB number. Typical field conditions that cause this:

• Project downloaded to only one of the two H-CPUs.
• Different firmware versions between rack 0 and rack 1.
• Edited H-parameters stored on one CPU's MMC but not the other.
• Mismatched interface assignments in NetPro after a network change.

Recovery procedure: bring the standby CPU to RUN with the master still in RUN, compare the projects via STEP 7 "Compare blocks", re-download the standby, then cycle the H-link. Always keep the H-CPU pair on identical firmware; Siemens documents version matrices in the S7-400H system manual.

10. STL, LAD, and FDB: When the DB Model Matters Most

Most application code is written in LAD or FBD and never touches absolute addressing. The DB model stays invisible. The moment you need:

• Loops over array elements,
• Variant record dispatch,
• Pointer-based string handling,
• Indirect DB-to-DB copy,

you will switch to STL or SCL. STL is the lowest-level representation; LAD/FBD are graphical translations of STL. Examining the STL view of a small LAD network reveals the DB registers (AR1, AR2, DBW, DIX) the translator inserts. Practice by writing a network in LAD, switching the editor to STL, and inspecting the result. Adding branches, contacts, timers, and comparators exposes exactly when the translator emits OPN DB or sets the address register.

For complex data manipulation, SCL (Structured Control Language, Pascal-derived) is the higher-level alternative. SCL compiles to STL but provides WHILE/FOR/CASE syntax, typed pointers, and direct slice access on optimized DBs.

11. Best Practices for DB Design

1. Name by function, number for compatibility. Symbolic names survive renumbering; absolute numbers do not.
2. Disable optimized access only when required. Optimization enables symbolic download, better diagnostics, and S7-1500 features such as GRAPH sequencer binding.
3. Group retentive tags. Place them in a dedicated retentive area at the end of the DB so they survive power-off without fragmenting the layout.
4. Prefer multi-instance FBs. Multi-instance is the only reliable path past the instance-DB count ceiling.
5. Reserve a small unoptimized DB for HMI or third-party drivers that demand fixed offsets. Do not mix absolute and symbolic access in the same DB.
6. Document DB numbering ranges in the project header. Shared DB 1-1000, instance 1001-2000, communication 2001-4096, for example. STEP 7 does not enforce uniqueness, only the runtime does.
7. Validate peak work memory before commissioning. STEP 7's "Block consistency check" and TIA's "Resource allocation" reports tabulate the worst-case DB load.

12. Verification Checklist After Download

1. Confirm the DB exists online via "Monitor/Modify" and inspect a few tags.
2. Read the diagnostic buffer for OB121 (programming) or OB122 (I/O access) errors.
3. If the CPU went STOP after download, check the SF LED plus the last entry before STOP. DB syntax errors surface as compilation events in STEP 7's "Compile and check block consistency" step.
4. Compare online/offline block footprints to confirm the MMC contains the DB revision you expected.
5. For H-systems, verify both racks report the same DB checksum and the same link-up state.

13. Troubleshooting Matrix

14. Field-Commissioning Notes

• Always verify the load memory (MMC) free space before adding a large DB. S7-300 MMC sizes range from 64 kB to 8 MB; S7-1500 SIMATIC Memory Cards from 4 MB to 32 GB.
• Battery-backed S7-400 CPUs require the battery to retain NVRAM; an exhausted battery plus retentive DBs causes an immediate retentive data loss on the next power cycle.
• S7-1500 firmware versions prior to V2.0 enforce tighter instance-DB limits; consult the function manual "S7-1500 CPU" for the per-firmware table.
• When migrating a STEP 7 V5.x project to TIA Portal, run the migration tool first. It reports DB number conflicts that would otherwise surface as runtime errors after download.