“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 (). The image below shows the contents of a DB, along with some settings:

The columns are as follows:

• 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.

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 DBs 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.

(right-click on the DB → Properties..)

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:

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)

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.

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.