Description

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
  • Variables can be added and the initial and current values changed.
  • Adding, deleting and changing of variables is done in the data block.
• Instance data block
  • Variables cannot be added or deleted and the initial and current values cannot be changed.
  • Adding, deleting and changing of variables is done in the associated function block.

Fig. 01

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

Fig. 02

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.

Remedy
We recommend the following remedy to properly create wrongly declared data blocks:

1. Delete the lines in the symbol table in which the rejected DBs are declared.
2. Then delete the wrongly declared data blocks.
3. 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.
 

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.
 

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.

Note
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 (e.g. DBx.DBBy or symbolic "DBName".Variable_name).