Difference between global data blocks and instance data blocks
In the case of a global DB all the blocks (FBs, FCs and OBs) can read and write the data contained in the data block. The instance DB is assigned to a specific function block and contains local data for that assigned FB.
|Global data blocks
||Instance data blocks|
|All blocks (FBs, FCs and OBs) can access the global DB in the program.
||The instance DB is assigned to an FB.|
|You can create a global DB independently of other blocks in the program.
||The instance DB can only be created when the associated FB is available in the program.|
|You cannot declare static local.
||Static local data can be declared in the FB.|
The stored static local data is not lost when the block has finished and is retained over several cycles until it it is written again.
|Adding, deleting and changing of variables is done in the data block.
||Adding, deleting and changing of variables is done in the associated function block.|
|Initial and current values can be changed in the global DB.
||Initial and current values cannot be changed in the instance DB.|
|The structure in the global DB itself can be specified.
||The structure in the instance DB is predefined by the variable declaration in the associated FB.|
The STEP 7 program has equal read and write access to the global and instance DBs in the CPU.
The data for different FBs can also be stored in one single instance DB (multi-instance). Fig. 02 shows an example of how the two function blocks FB5 and FB6 are called as multi-instances in FB1. The two FBs called deposit their data in the instance data block DB1 of the calling block FB1. In the declaration of FB1, the multi-instance block calls are stored as static variables.
More information is available in the STEP 7 Online Help under
- "Instance Data Blocks"
- "Creating Data Blocks (DB)"
- "Structure of a Data Block (DB)"
- "Using Multi-instances"
Note on upgrading from STEP 7 V4.02 to V5.x
When you upgrade from STEP 7 V4.02 to V5.x, it might happen that some CALL calls are displayed in red in the LAD/STL/FBD editor. The reason for this behavior is that an instance DB used in the block call has been declared as a global DB in the symbol table. This is not allowed by the STEP 7 programming rules and is no longer accepted by STEP 7 versions V5.x.
We recommend the following remedy to properly create wrongly declared data blocks:
- Delete the lines in the symbol table in which the rejected DBs are declared.
- Then delete the wrongly declared data blocks.
- Open the calling block and recreate the instance DBs with the CALL calls.
How a CALL call influences the DB register
When the block is called in in STEP 5 and in STEP 7, the original content of the DB1 and DB2 registers is restored. An open data block remains "valid" until another data block is opened. The DB register contents reflect the currently opened data blocks(DB / DI).
However, you must make sure that not every change in the DB register is made obvious to the user by the S7 editor/compiler. For example, if you use a CALL call to call a function to which you have assigned a fully qualified DB parameter, the compiler opens the data block specified. When the function is completed, this DB number is once again in the DB1 register. Changes within the function do not affect the content of the DB registers after function call.
|L DBB 0
|L DBB 0
If you call a function block with the associated instance data block, the instance DB is in the DB1 register after the CALL call. Transfer of fully qualified DB accesses to the FB as well as changes to the DB register within the FB do not influence this.
|L DBB 0
|CALL FB1, DB10
|L DBB 0
After calling a system function block (SFB), the associated instance data block number is also in the DB1 register. However, the content of the data registers is always retained after a change of block via a UC or CC command, because no parameters or instance data blocks are specified with these calls.
In order to avoid area length errors and access errors when handling data blocks during STEP 7 programming, you should only work with fully qualified DB accesses (DBx.DBBy or symbolic "DBName".Variable_name, for example).