meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
automation:db [2026/01/06 15:01] – created - external edit 127.0.0.1automation:db [2026/01/06 23:18] (current) – vamsan
Line 1: Line 1:
 ==== Data block (DB) ==== ==== Data block (DB) ====
 {{anchor:db}} {{anchor:db}}
-“DB” is an abbreviation for DATA_BLOCK or the German "Datenbaustein" and is used to denote a data area. A DB can contain any set of data types allowed and defined on the given PLC. A DB can have a maximum size of 64 kByte. The size of the PLC data area limits the total space occupied by all DBs. It is important to note that the PLC is not optimized for storing large amounts of data; therefore, we do not store images, music, files, or even large text files in a DB. The TIA-Portal uses the small blue barrel symbol ({{:automation:db_0.png|DB symbol}}) to denote DBs.+“DB” stands for DATA_BLOCK or the German term "Datenbaustein', indicating a data area. It can contain various data types permitted and defined by the specific PLC. The total size of all DBs is limited by the PLC's data capacity. Since the PLC isn't optimized for storing large data, we do not save images, music, files, or extensive text files within a DB. In the TIA-Portal, DBs are marked with a small blue barrel icon ({{:automation:db_0.png|DB symbol}}).
 The image below shows the contents of a DB, along with some settings: The image below shows the contents of a DB, along with some settings:
  
Line 19: Line 19:
 |**Setpoint**|This allows you to initialize values ​​in a data block (DB) online while the CPU is in RUN mode.| |**Setpoint**|This allows you to initialize values ​​in a data block (DB) online while the CPU is in RUN mode.|
 |**Comment**|Description of the function of the field.| |**Comment**|Description of the function of the field.|
 +
 +=== DB Limits ===
 +
 +  * You can define up to 252 structures within a single data block for S7-1200/S7-1500, regardless of the data types used in the structures.
 +  * Maximum DB Number: The total number of data blocks is generally capped at 65,535, due to the common use of a 16-bit address range. 
 +  * Maximum DB Size (Standard - not optimized - Access): For older PLC models like S7-300/400 and for standard access DBs in newer models, each DB's size typically does not exceed 64 KB (65,534 bytes). 
 +  * Maximum DB Size (Optimized Access): In contrast, S7-1200/S7-1500 CPUs that utilize optimized access have a much larger size limit, which varies based on the CPU's total working memory and can reach from 1 MB up to 10 MB or more per DB.
 +
 +=== Instant vs global DB ===
 +
 +A **global DB** is a data block that programmers can freely create and populate with variables. These variables may include default Simatic types (INT, REAL, etc.), structures, arrays, or UDTs.
 +
 +**Instant DB**s are implicitly created when FBs are called for the first time. This call is primarily through the instant DB. When an FB is deleted, the TIA Portal also issues a separate warning about removing the instant DB. The contents of the instant DB automatically update with changes to the FB's variable list. It can include default Simatic variables like INT, REAL, structures, arrays, and UDTs. If the FB calls other embedded FBs (e.g., TON, TOF), their instant DBs are also stored here, resulting in a **multi-instant DB**. 
 +
  
 === DB Properties === === DB Properties ===
Line 28: Line 42:
 ^Name the attribut^Description| ^Name the attribut^Description|
 |**Only store in load memory**|This attribute is stored on the PLC's Micro Memory Card (MMC) or similar non-volatile storage, not in the CPU's working RAM, making it ideal for large, infrequently used data such as recipes or logs. \\ It's accessed using special instructions like READ_DBL or WRIT_DBL to transfer data to/from working memory. This preserves precious working memory, but requires explicit programming to move data for active processing. The data survives power cycles but can be lost with a factory reset.|  |**Only store in load memory**|This attribute is stored on the PLC's Micro Memory Card (MMC) or similar non-volatile storage, not in the CPU's working RAM, making it ideal for large, infrequently used data such as recipes or logs. \\ It's accessed using special instructions like READ_DBL or WRIT_DBL to transfer data to/from working memory. This preserves precious working memory, but requires explicit programming to move data for active processing. The data survives power cycles but can be lost with a factory reset.| 
-|Data block write-protected in the device|Make the entire data block read-only.| +|**Data block write-protected in the device**|Make the entire data block read-only.| 
-|Optimized block access|Optimized variable order within the DB. See below: [[#optimized_db|Optimized DB]].| +|**Optimized block access**|Optimized variable order within the DB. See below: [[#optimized_db|Optimized DB]].| 
-|Data block accessible from OPC UA|The data block can be accessed and published by OPC UA. See: [[#opc_ua|OPC UA]].|+|**Data block accessible from OPC UA**|The data block can be accessed and published by OPC UA. See: [[#opc_ua|OPC UA]].|
  
-== Optimized DB ==+=== Optimized DB ===
 {{anchor:optimized_db}} {{anchor:optimized_db}}
 Simatic groups variables in the optimized DB so they occupy as little storage space as possible. This means that it is "not visible from the outside" where a given data item is located within the storage space, i.e., in this case, the offset is not displayed in the editor window: Simatic groups variables in the optimized DB so they occupy as little storage space as possible. This means that it is "not visible from the outside" where a given data item is located within the storage space, i.e., in this case, the offset is not displayed in the editor window:
Line 39: Line 53:
  
 On the one hand, this helps better utilize the PLC's storage space. Still, on the other hand, it makes operations that require direct addressing (communication modules - Modbus, direct addressing, etc.) impossible. In such cases, this option must be disabled in the settings (//right-click on the DB -> Properties.. -> Attributes -> Optimized block access -> OFF//) On the one hand, this helps better utilize the PLC's storage space. Still, on the other hand, it makes operations that require direct addressing (communication modules - Modbus, direct addressing, etc.) impossible. In such cases, this option must be disabled in the settings (//right-click on the DB -> Properties.. -> Attributes -> Optimized block access -> OFF//)
 +
 +=== Tags vs DB data ===
 +
 +There are two basic methods for storing data in PLCs (in a simplified view). One involves placing variables in a global memory table alongside input and output variables, while the other uses data blocks (DBs). From my experience, storing data in DBs tends to be simpler and more straightforward for several reasons.
 +
 +  * Function-specific data can be stored in DBs. For example, the “motor1” DB contains only data for the 1st motor, but all of them (speed, load, temperature, on-off, errors, ...)
 +  * If someone wants to define a “motor2” as well, identical to “motor1” in terms of its parameters, they just need to copy the previous DB
 +  * Cross-reference management of data immediately points to the given DB, from which we can immediately deduce their function
 +  * If the data is already in the instant DBs assigned to the FBs, it is easy to embed them in a calling FB to use them as multi-instants.
 +
 +Typically, I don't bother defining variables within the Tags; creating them directly in the databases suffices—though this is just my personal preference.
 +
 +=== Storing DB records in the load memory ===
 +In PLCs, working memory is PLC-dependent and often very limited. We may have a lot of information that does not need to be read and written cyclically. Examples include recipe data (a list of technological components), parameter data, or database assignments that are needed only occasionally. 
 +
 +In these cases, one option is to store the data not in working memory but on the SD card and in load memory, and to transfer them only when needed using the "WRIT_DBL" and "READ_DBL" operations.
 +
 +{{:automation:db_5.png |Storing DB records in the load memory}}
  
 <WRAP center round info 80%> <WRAP center round info 80%>