Siemens S7 Data Blocks: Global vs Instance DB Architecture Reference

This reference consolidates field-proven guidance for designing STEP 7 / TIA Portal user programs around Data Blocks (DB). It addresses the most common question asked by engineers migrating from the Rockwell/Allen-Bradley (A-B) Logix platform: should the application use Global DBs with Functions (FC), or Instance DBs tied to Function Blocks (FB)? The guidance below covers block memory layout, the FC/FB call model, byte-ordering rules, IEC timer/counter selection, Organization Block (OB) usage, User-Defined Types (UDT), and structured design patterns that scale from a single conveyor to multi-section plant code.

1. Data Block Architecture in S7

Data Blocks are the storage containers for variable user data in the S7 user program. Unlike the Process Image (PII/PIQ), Bit Memory (M), or Local / Temp (L) stack, DBs are addressable as named memory regions that survive between scans and can be referenced by every block in the program. Per the official TIA Portal V20 programming reference, "Data blocks thus contain variable data that is used by the user program" and sit alongside OBs, FBs, and FCs as first-class elements of the program.

Two physical flavors of DB exist:

Both DB types are accessed the same way at runtime (DB1.DBX0.0, DB1.DBW2, DB1.DBD4). The difference is semantic: a Global DB is a free-form data structure you author by hand; an Instance DB is automatically generated to match the declaration of its parent FB. Per Siemens documentation, an Instance DB's STRUCT is locked to the FB interface and cannot be edited directly in the DB editor; changes must be made in the FB and recompiled.

2. Global Data Blocks (GDB) — Technical Details

A Global DB is simply a named area of work memory. It has no associated code block; the engineer declares its STRUCT manually. GDBs are ideal for data that does not belong to a single piece of equipment, including:

• Recipes and machine setpoints read by HMI
• Production counters and shift totals
• Cross-equipment interlocks (e.g., Permissive_Common)
• HMI message buffers and alarm history
• Communication buffers for PUT / GET / BSEND / USEND on S7-300/400, or for READ / WRITE on S7-1200/1500

Per the TIA Portal V20 programming basics manual, Global DBs are part of the standard block set and can be created from Program blocks > Add new block > Data block. The resulting block is downloaded to the PLC and can be opened in online watch without restrictions.

Authoring tip: split a GDB into sections by purpose (Settings, Status, Production, Comm) using comment dividers. Avoid using a single monolithic GDB for an entire machine — it becomes unsearchable past a few hundred tags and bloats online diff views.

3. Instance Data Blocks (IDB) — Technical Details

An Instance DB is the runtime memory of a Function Block (FB). When an FB is called with a Call instruction, you either name an existing IDB or let the compiler auto-generate a single-instance or multi-instance IDB. The IDB's STRUCT is rebuilt from the FB declaration every time the FB's interface is recompiled.

Standard FB declaration layout:

FUNCTION_BLOCK FB_Conveyor
VAR_INPUT
    i_Start         : BOOL;     // Start command from HMI or upstream
    i_Stop          : BOOL;     // Stop command (NC contact)
    i_SpeedSetpoint : REAL;     // Hz or %
END_VAR
VAR_OUTPUT
    q_Running       : BOOL;
    q_Fault         : BOOL;
    q_ActualSpeed   : REAL;
END_VAR
VAR_IN_OUT
    io_Motor        : BOOL;     // shared drive enable signal
END_VAR
VAR
    s_TON_Run       : TON;      // IEC on-delay, STATIC retention
    s_LastStart     : BOOL;     // edge-detection bit
    s_RunTimeSec    : DINT;     // accumulated run time
    s_StartPulse    : BOOL;     // one-shot memory
END_VAR
VAR_TEMP
    t_TempDword     : DWORD;    // scratch / intermediate calc only
END_VAR
BEGIN
    // FB body
END_FUNCTION_BLOCK

When FB_Conveyor is called as a single instance, the compiler creates an IDB (e.g., DB_Conveyor_1) containing two substructures: a Input, Output, InOut, and Static view that mirrors the FB declaration. Temp variables are not stored in the IDB; they live on the local stack of the calling OB and must not be used after the FB exits.

Calling the same FB multiple times (e.g., Conveyor_1, Conveyor_2, Conveyor_3) can be done as:

• Single-instance: each call uses its own IDB. Recommended when the equipment instances are independent and the FB may be reused in other projects.
• Multi-instance: each call stores its data inside the IDB of a parent FB. Recommended for tightly-coupled subsystems where the parent is the only caller.

Multi-instance syntax (in a parent FB):

FUNCTION_BLOCK FB_Line
VAR
    Conveyor1 : FB_Conveyor;   // multi-instance, stored in FB_Line's IDB
    Conveyor2 : FB_Conveyor;
    Conveyor3 : FB_Conveyor;
END_VAR

4. Functions (FC) vs. Function Blocks (FB)

The choice between FC and FB is the central design decision in any S7 program. The trade-off is summarized below.

Rule of thumb from the field:

• Use an FC when the routine is purely a calculation or conversion (e.g., scaling a 4–20 mA raw value to engineering units, computing a CRC). It is also the fastest path to a first working program under deadline pressure.
• Use an FB when the routine has state: a motor, a valve, a PID loop, a state machine, anything that needs to remember between scans.

Combining both is the typical pattern: the OB calls FBs (one per device instance), and each FB calls shared FCs (for math, scaling, alarm formatting). The shared, non-volatile settings live in a single Global DB; the per-device state lives in IDBs.

5. M Memory, Bit Memory, and When to Avoid It

Bit Memory (M / MB / MW / MD) is the legacy scratch-pad of S7. It is faster to type than DBx.DBWy, but it has three structural problems that scale poorly:

1. No online structure view. Watching M10.0 in the variable table is fine; watching 300 M bits mixed across a machine is not.
2. Retentivity is per-byte, not per-bit. A BOOL in MB10 inherits the retentive setting of the entire byte.
3. No symbol-only access on S7-1200/1500 optimized blocks. Optimized FBs cannot reference M bits symbolically; everything must go through a DB.

Practical guidance: keep M reserved for low-level handshakes (e.g., FirstScan, AlwaysTrue, Heartbeat_100ms) and put all real program state in DBs. This mirrors A-B practice of using program tags (controller-scoped) instead of legacy global tags in older SLC/PLC-5 conventions.

6. Byte Ordering, Data Types, and the Ladder Pitfall

S7 is a big-endian architecture for declared types but the bit/byte numbering of absolute addresses can mislead engineers coming from PLC-5 or Logix. The rule to memorize:

When you execute a MOVE (ladder) or T (STL) instruction, the CPU stores the value according to the target's declared type. If you turn off "Type check of operands" in the compiler settings to silence mismatched-type warnings, the program may compile but execute with wrong byte order. The correct fix is to align source and destination types (INT to INT, REAL to REAL) and to swap bytes explicitly with TAW / TAD when interfacing with a device that delivers little-endian data (most Modbus RTU slaves, some ASCII scales).

Recommended data types by use case:

7. IEC Timers and Counters — The Right Choice

S7 ships two timer families. S5 timers (SP, SE, SD, SS, SF, SA) are bit-mapped legacy blocks from the S5 era. IEC timers are System Function Blocks found in Libraries > Standard Library > System Function Blocks:

On S7-1200/1500 the IEC blocks are called TON_TIME / TOF_TIME / TP_TIME / CTU / CTD / CTUD in the Instructions > Timer operations and Counter operations task cards. Their semantics match the A-B TON / TOF / CTU / CTD instructions almost exactly, which makes them the preferred choice for migration projects.

Two IEC timer behaviors to remember:

1. Edge-triggered start. A TON/TOF starts on a rising edge of IN. If IN is already TRUE on the first scan, the timer does not start. Initialize the timer input from a conditional that produces a clean edge, or call SFB3/SFB4/SFB5 with IN driven by a one-shot.
2. PT = 0 never passes power. A TON with a preset of T#0ms leaves Q = FALSE forever. S5 timers behaved the opposite way (PT=0 meant "always true"). Always use a positive PT and validate HMI entries for <= 0.

Reading the elapsed time (ET / CV) does not interfere with the running timer. To compute the remaining time, use Remaining := PT - ET in REAL/DINT math. S5 timers require the extra LC (load BCD) and ITD (BCD-to-integer) steps to make the remaining time accessible as a usable number — another reason to standardize on IEC blocks.

8. Organization Blocks (OB) and Startup Behavior

OBs are the entry points the CPU calls; they cannot be called from user code. The most common are:

The startup OBs (100/101/102) execute once when the CPU transitions from STOP to RUN, before OB1 begins cycling. They are the place to:

• Copy default values into the GDB Settings structure
• Initialize edge-detection bits (s_LastStart := FALSE)
• Pre-load recipe parameters from a non-volatile source
• Reset non-retentive counters and production totals

9. User-Defined Types (UDT) for Reusable Structures

A UDT is a user-defined data type, like a struct in C. It can be referenced in the declaration of any DB or FB and it guarantees identical layout across instances. UDTs are the single most effective way to scale a Siemens program from one device to one hundred.

Typical usage — a Motor UDT shared by every motor block:

TYPE UDT_Motor
STRUCT
    StartCmd       : BOOL;
    StopCmd        : BOOL;
    Running        : BOOL;
    Faulted        : BOOL;
    ActualSpeed    : REAL;
    SetpointSpeed  : REAL;
    RunHours       : DINT;
    LastStartTime  : DTL;
END_STRUCT
END_TYPE

Reference in a DB:

DATA_BLOCK DB_Equipment
STRUCT
    Conveyor1 : UDT_Motor;
    Conveyor2 : UDT_Motor;
    Conveyor3 : UDT_Motor;
    Shared    : UDT_CommonSettings;  // second UDT for setpoints
END_STRUCT
END_DATA_BLOCK

Reference in an FB's Static area:

FUNCTION_BLOCK FB_Conveyor
VAR
    s_Motor : UDT_Motor;
END_VAR

Now an HMI tag like DB_Equipment.Conveyor1.Running is identical in shape to DB_Equipment.Conveyor2.Running. WinCC, TIA HMI, and third-party SCADA systems can use a single tag prefix and an index to address all motors.

UDT edit rule: changing a UDT automatically updates every block that uses it. Always recompile the entire program (not just the changed FB) after a UDT change, and verify IDB sizes in the project tree.

10. Addressing Mode: Symbolic vs. Absolute

Two ways to reference a variable exist:

• Absolute — DB1.DBX4.0, MW10, I0.0
• Symbolic — Data_Recipe.SpeedSP, Conveyor1.Running

Best practice for new programs: set the project priority to Symbolic in the block-folder properties. This makes the symbol the default, the absolute the fallback, and the ladder editor stops inserting raw DB1.DBX4.0 tags on first use. On TIA Portal V20, optimized blocks enforce symbolic-only access at compile time, so the choice is effectively made for you.

11. Common Errors and Verification Matrix

12. Migration Checklist: A-B / Logix → S7

For engineers moving from Studio 5000 / RSLogix 5000 to STEP 7 / TIA Portal, the following mapping helps a clean conversion.

13. Field-Proven Project Layout

For a mid-size machine (one PLC, 10–50 devices, one HMI), the following structure scales cleanly:

1. OB1 — calls FB_Line_Control (the master FB) and the standalone FBs for HMI handshake, alarm collection, and recipe handling.
2. OB100 — initializes DB_Settings with default values, clears non-retentive counters.
3. DB_Settings (GDB, non-optimized for HMI) — recipes, setpoints, machine parameters.
4. DB_Production (GDB, retentive) — counters, shift totals, fault history.
5. DB_Comm (GDB, non-optimized) — buffers for PUT/GET to subordinate PLCs or drives.
6. UDT_Motor / UDT_Valve / UDT_PID — reusable structures.
7. FB_Conveyor / FB_Pump / FB_Valve / FB_PID — equipment blocks, each a multi-instance of the master FB_Line_Control or a single-instance with its own IDB.
8. FC_Scale_4_20 / FC_Alarm_Format / FC_Linearize_TC — stateless utility routines.

The same UDT_Motor shows up in DB_Equipment for HMI tag prefixing, in the Static of every motor FB, and (if needed) in a Global DB for a section overview panel. One change to the UDT propagates everywhere.

14. References and Standards

Verify behavior against the following official Siemens manuals and standards when implementing these patterns in a certified project:

• TIA Portal V20 — Global Data Blocks (DB)
• SiePortal — Sharing Data Blocks between several S7-1500
• Software Toolbox — How to access Siemens S7 PLC Function and InstanceDB