Siemens PLC Data Block: Global DB vs Instance DB
Quick answer
A Siemens data block (DB) is a typed memory block. A global DB stores shared project data; an instance DB stores the static state and interface data for a specific function-block instance. It is not executable code.
Key Takeaways
- A Siemens data block (DB) is a typed memory block. A global DB stores shared project data; an instance DB stores the sta...
- Intermediate-level topic in Data Types & Variables
- Commonly used in: Machine configuration and recipe structures, Function-block instance state
- Related to: Structure, Pointer, BOOL
Detailed Definition
A data block is a Siemens STEP 7/TIA Portal program object that stores structured values. A global DB is directly available to the user program and is suitable for data shared across program parts. An instance DB belongs to an FB call and stores that instance’s static variables, parameters and internal state. Multi-instances embed one FB instance inside another instance DB.
Good DB design uses named structures and PLC data types rather than unrelated flat tags. Ownership matters: shared writable data can become difficult to diagnose when many blocks modify it. Retentivity, start values, actual values, optimized access, external HMI access and recipe persistence are independent design decisions that must be documented and tested.
Evidence and scope
The global and instance data-block model was checked against Siemens programming guidance for S7-1200/1500. Optimized access, retain settings, download initialization and online-change behavior depend on CPU generation, TIA Portal version and project configuration.
Technical review:
Critical behavior
- Global DBs are shared data; instance DBs contain the persistent state of one FB instance.
- A DB is not a subroutine and does not execute. Logic in OBs, FBs and FCs reads or writes its data.
- Start values, online actual values and retained values are different concepts during download and restart.
- Optimized block access can change addressing and external-access assumptions; symbolic access is preferred.
- Copying or reinitializing an instance DB can also copy or reset hidden timer, edge and sequence state.
Verification checklist
- 1Classify every DB as global, single-instance or multi-instance.
- 2Assign one owner for each writable shared structure and document external clients.
- 3Test cold restart, warm restart, download and initialization with non-default values.
- 4Verify symbolic HMI/OPC access after compiling optimized blocks.
- 5Archive PLC data types and DB interface versions with the program release.
IEC and vendor terminology
Similar-looking instructions do not always have identical execution, initialization or storage behavior.
| Platform | Common term | What to verify |
|---|---|---|
| Siemens global DB | Global data block | Structured data accessible by multiple program blocks; assign a clear writer/owner for each field. |
| Siemens FB call | Instance DB | Stores parameters, STAT variables and internal state for one FB instance. |
| Siemens FB hierarchy | Multi-instance | Stores child FB instances inside the parent instance DB to reduce separate DB objects. |
| Other IEC platforms | Global variable list / FB instance | Similar data ownership concepts exist, but the Siemens DB object and access settings are platform specific. |
Global and instance DB ownership
OB_Main ──calls──> FB_Pump(P101) ──state──> DB_Pump101
│ │
└──reads────────> DB_MachineConfig <──writes── HMI/service layer
└── typed limits, modes and setpointsWhich Siemens data block should own the value?
Choose ownership before choosing a DB name or address.
| State / phase | Best owner | Typical lifetime | Primary risk |
|---|---|---|---|
| Shared machine setpoint | Typed global DB | Project / retained if justified | Uncontrolled writes from many blocks |
| One pump sequence state | Pump FB instance DB | Across scans; restart per design | State copied or reset unexpectedly |
| Temporary calculation | Block TEMP/local variable | One execution | Mistaken expectation of persistence |
| Child valve instance | Parent FB multi-instance | Parent instance lifetime | Interface hidden by deep nesting |
| HMI exchange structure | Dedicated typed global DB | Defined by interface contract | Optimized/external access mismatch |
Working LD and ST example
Use a typed global configuration with instance-owned state
Keep shared setpoints separate from the state of each reusable equipment module.
Ladder Diagram
|----[ CALL FB_Pump, DB_Pump101 ]--------------------------------|
| Enable := DB_Config.AutoEnable |
| StartLevel := DB_Config.Pump101.StartLevel |
| Level := TankLevel Running => Pump101Running |Structured Text
Pump101(
Enable := DB_Config.AutoEnable,
StartLevel := DB_Config.Pump101.StartLevel,
StopLevel := DB_Config.Pump101.StopLevel,
Level := TankLevel,
Running => Pump101Running,
Faulted => Pump101Faulted
);
// Pump101 state belongs to DB_Pump101.
// Shared, reviewed setpoints belong to DB_Config.Expected result: A second pump can reuse FB_Pump with a separate instance DB while both consume a controlled, typed configuration structure.
Failure modes and diagnostic checks
| Symptom | Likely cause | Check next |
|---|---|---|
| Values revert after download | Start values, actual values and retain settings were misunderstood. | Run a documented download and cold/warm restart matrix with representative values. |
| Timer or edge state behaves unexpectedly | The FB instance DB was recreated, copied or initialized. | Inspect the instance relationship and every initialization path. |
| HMI cannot browse or write a member | External-access or optimized-access settings do not match the communication path. | Test symbolic access using the actual HMI/driver and compiled project. |
| A value changes with no obvious writer | Several blocks, HMI scripts or communications clients write the global field. | Use cross-reference and access protection; assign one owner and request interface. |
Current primary and technical sources
These sources support the behavior summarized on this page. The project's controller, firmware and IDE help remain authoritative for implementation.
- Programming Guideline for S7-1200/1500
Siemens — Global DB, instance DB, symbolic access and structured-program guidance
Continue with the practical guide
Common Questions
What is Data Block?
A Siemens data block (DB) is a typed memory block. A global DB stores shared project data; an instance DB stores the static state and interface data for a specific function-block instance. It is not executable code.
When should I use Data Block?
Data Block is particularly useful in scenarios such as Machine configuration and recipe structures and Function-block instance state. Consider implementing it when you need reliable, efficient solutions for these types of applications.
What should I verify before using Data Block?
Classify every DB as global, single-instance or multi-instance. Assign one owner for each writable shared structure and document external clients. Test cold restart, warm restart, download and initialization with non-default values. Verify symbolic HMI/OPC access after compiling optimized blocks. Archive PLC data types and DB interface versions with the program release.
What are related concepts I should learn?
To fully understand Data Block, you should also familiarize yourself with Structure, Pointer, and BOOL. These concepts work together in industrial automation systems.
Continue Learning
Ready to deepen your understanding of Data Block? Here are some recommended resources:
Was this helpful?
Let us know if this glossary term helped you understand Data Block better.
Your feedback helps us improve our glossary and create better content for the PLC programming community.
Quick Info
- Category
- Data Types & Variables
- Difficulty
- Intermediate
- Tier
- Important
About Data Types & Variables
Data structures, variable types, and memory organization