Description STEP 7 V5.x and STEP 7 (TIA Portal) provide various block protection facilities to protect the know-how of your programs in the blocks against unauthorized persons. You can also encrypt programs created in S7-SCL, S7-GRAPH and CFC and protect the block code against unauthorized access. The program code, the temporary/static variables and the network comments are then not displayed. It is not possible to change the protected block. The following table gives you an overview of the know-how protection facilities.
SIMATIC STEP 7
Setting up block protection
STEP 7 V5.x
LAD / FBD / STL
Input: "KNOW_HOW_PROTECT" in the STL source
Additional information is available in Entry ID: 10025431
Input: "KNOW_HOW_PROTECT" in the S7-SCL source
Additional information is available in Entry ID: 14761527
Input: "KNOW_HOW_PROTECT" in the S7-GRAPH source
Additional information is available in Entry ID: 10024793
Enable the "KNOW_HOW_PROTECT" function
in the CFC chart and SCL source
Additional information is available in Entry ID: 14761890
STEP 7 V5.5
LAD / FBD / STL / SCL
Using the function: S7-Block Privacy
Additional information is also available in Entry ID 45632073
STEP 7 (TIA Portal)
LAD / FBD / STL / SCL / GRAPH
Enable the block protection with the "Edit > Know-How Protection" function
Additional information is available in the STEP 7 (TIA Portal) Online Help under:
Setting up know-how protection
Opening know-how protected blocks
Removing know-how protection
LAD / FBD / SCL
LAD / FBD / STL / SCL
What is the maximum number of parameters that can be assigned to an FC and FB in the S7-300 CPU?
Description The maximum number of parameters for a function (FC) in an S7-300 CPU is limited to 127. These can be IN, OUT or IN_OUT parameters. On the other hand, the number of parameters for a function block (FB) in an S7-300 CPU is not limited to a specific number, but is restricted by the maximum size of the instance data block.
How can you install block protection for self-created blocks?
Instructions: STEP 7 provides the KNOW_HOW_PROTECT function for protecting the programs. If you open a block protected by this function, then you can only view the block interface (IN, OUT and IN/OUT parameters) and the block comment. The program code, the temporary/static variables and the network comments are not displayed. It is not possible to change the protected block.
The table below describes the procedure for installing the KNOW_HOW_PROTECT function for your program blocks (FBs, FCs and DBs).
Open the function block to be edited and in the LAD/STL/FBD editor you generate a source via "File > Generate source...".
In the dialog that opens you enter an object name, e.g. "Protect_FB".
The "Generate source <Name>" dialog opens. Here you mark the block for which the STL source is to be generated and use the arrow key to move this block into the "Blocks Selected" window on the right. Confirm with OK and the STL source is generated. Close the LAD/STL/FBD editor again.
Open the newly created source in the "Sources" folder of your S7 program.
Insert a line with the "KNOW_HOW_PROTECT" command in the declaration section of the source block under "TITLE".
Save and compile the STL source via "File > Save" and "File > Compile". The block is now protected.
The block protection can only be removed again via the STL source. If the STL sources are no longer available to the program or project via the "KNOW_HOW_PROTECT" command, you can no longer remove the protection for the blocks.
The table below describes the procedure for deactivating the KNOW_HOW_PROTECT function for your program blocks (FBs, FCs and DBs).
Open your source.
Remove the "KNOW_HOW_PROTECT" entry or comment it out with two slashes.
Save and compile the STL source via "File > Save" and "File > Compile".
The block protection is now deactivated.
Tips and tricks for calling and parameterizing SFBs, SFCs and IEC standard functions
The table below provides information and remedies for the above.
Tips and tricks for calling and parameterizing SFBs, SFCs and IEC standard functions
General - where can you obtain information on the SFBs, SFCs and the IEC functions?
Information on the SFBs, SFCs and the IEC functions for configuring and parameterizing are available
In the Online Help by marking the block and pressing the F1 key
In the "System software for S7-300/400 system and standard functions" manual, Entry ID: 1214574.
How do you parameterize the inputs "IN1" and "IN2" of the IEC standard function FC11 (FIND)?
The character string "IN2" to be found must not be the same size as the character string "IN1". If the two character strings are identical, block FC11 (FIND) also reports zero. For queries about being equal use FC10 (EQ_STRNG) or combine both blocks.
What do you have to watch out for when configuring the ANY pointer of the ARRAY or STRUCT type at the "RECORD" output of SFC14/15?
STEP 7 always stores ARRAYs and STRUCTs in word boundaries in the memory. An odd byte number (e.g. ARRAY <1..5>) is filled with 1 byte, so that an incorrect length is transferred via the ANY pointer. This leads to the following error message:
80B1: "The length of the specified target area is not equal to the length of the user data configured with STEP 7"
The length of the ANY pointer must always be specified precisely in bytes, e.g. with the syntax: "P#M280.0 BYTE 5". We recommend parameterizing the ANY variable of SFC14 /15 via the absolute programming.
How can you transfer data areas of the "STRING" type with SFC20?
Using the system function SFC20 (BLKMOV) you can transfer data areas from a data block DB1 to a data block DB2, for example. When writing a local variable of the STRING type in a data block, you must preset that variable beforehand. You must then program that variable symbolically (not absolutely) for transfer to SFC20. Fig. 01 shows how the SFC20 can be programmed with a STRING variable.
Why is the return value RET_VAL of SFC20 different depending on the CPU used?
When assigning an inadmissible ANY pointer with the length "0", there is a difference between the return values of an S7-300 and an S7-400 CPU. There are different return values of SFC20 due to the different ways the CPUs handle errors.
Why does the function IEC FC 38 return the value "0" although the string variable is in the permissible range?
If the IEC function FC 38 is parameterized via a STRING variable that is defined in a DB without an initial value, then a "0" is given in the byte for the actual length. The variable has not been initialized in the DB. This means that the variable is installed with the information "defined length", but without any information about the actual length. Now, if a character string is entered via the variable table, without adapting the byte for the actual length, the character string is not recognized by the CPU. The character string is only recognized by the CPU once the byte for the actual length has been adapted.
Please also refer to the information in the Online Help of STEP 7, under "Format of the Data Type STRING".
In which OBs are the SFBs for the communication jobs called up? All SFBs that you require for data exchange or for program management (setting AS to STOP or to RUN) via the configured connections must be called in the startup OBs (OB100 in the S7-300, OB100 and OB101 in the S7-400) and in cyclic operation (OB1).
The OB100 is a startup OB and is run when the CPU is restarted (warm start). In this OB, the first communication trigger is enabled with markers M1.0 and M0.1, for example. A sample program, as well as further information about programming and parameterizing the SFB14 / SFB15 can be found in Entry ID: 1819293.
You must interconnect the parameters "REQ", "ID" and "PI_NAME" of the SFBs as follows in the startup OBs:
"REQ": Enables data exchange if certain conditions are met. Connect the "REQ" parameter to a boolean actual parameter with the status "0".
"ID": Reference to the local connection description which is allocated during the configuration of the connection. Connect the "ID" parameter in the format W#16#X where X is the "ID number" of the connection.
"PI_NAME": Indicates the memory area in which the name of the program which is being started (ASCII code) is saved. The parameter "PI_NAME" (SFB19 "START", SFB20 "STOP" or SFB21 "RESUME") must be connected to a string beginning "P_PROGRAM".
There is more information about the assignment of parameters to the SFBs available in the STEP 7 Online Help.
How do you transfer string variables from a data block to a function blocks, for example?
For this application case you program symbolically or symbolically access the names of the variables in the data block. The following example shows data block DB5 with the two variables "String_1" and "String_2".
The symbolic name of DB5 is "Baustein" (= block). The two string variables should be linked with a function block FB1. Fig. 01 shows the declaration of both string variables and the assignment of the symbolic name "Baustein" in the DB's Properties.
The IEC standard function FC10 EQ_STRNG (equal comparison of two variables in the STRING format) is called in FB1. The two parameters S1 and S2 of FC10 are parameterized with the input variables "InputSTR1" and "InputSTR2". Fig. 02 shows the call and parameters of the standard FC10 (EQ_STRNG) in FB1.
FB2 calls FB1 with its instance data block DB1 and the two input parameters "InputSTR1" and "InputSTR2" are parameterized with the two string variables of DB5 ("Baustein".String_1 and "Baustein".String_2).
04: "Basics of Designing a Program Structure"
09: "Creating Blocks and Libraries"
10: "Creating Logic Blocks"
13: "Creating STL Source Files"
15: "Checking Block Consistency and Time Stamps as a Block Property"
Variables with structured data types are saved with transit parameters (IN_OUT) of the FB as reference with a 6-byte POINTER (48 bits) in the instance DB. This means that there is not a value, but a six-byte POINTER in the instance DB. This POINTER indicates the actual parameter; therefore, it is imperative that it is parameterized. STEP 7 identifies the following structured data types: "Date_and_Time", "String, Array", "Struct" and "UDT".
Fig. 01 contains an example of how to program indirect access to the first byte of this data type. This procedure from the example is for data backup.
The 6-byte POINTER is loaded via the IN_OUT variable "Symbol_of_InOut". The number of the data block is then transferred from the 6-byte POINTER into a temporary variable "DB_Num". The DB is opened with this saved DB number via the statement "AUF DB[#DB_Num]" and then the address is loaded into address register 1.
The "+AR1" instruction interprets the value in ACCU1 as a number in the INT format, extends it with the correct +/- sign to 24 bits and adds it to the content of the address register. If the maximum range of the byte address is overshot or undershot (0 ... 65535), this has no effect, because the upper bits are truncated.
The statement "L B[AR1,P#0.0]" provides you with the saved data and correct address. If you were to use the statement "L Symbol_des_InOut" instead of this example, then you would not load the saved data from the address register, but the data directly from the IN_OUT parameter. However, these values might have changed. Please also refer here to the relevant information in the STEP 7 Online Help under
"Avoiding errors when calling blocks".
The example described is valid only for DB areas, because otherwise the CPU goes into "STOP". Numbering with 0 (DB0) is not permitted.
The "InOutvar.zip" file includes a STEP 7 project with two S7 stations for the sample program described above:
Station: "Beispiel in deutsch" mit den deutschen Kommentaren
Station: "Example in English" with English comments
Assign parameters to a function call with structured data types The parameters of a structured data type (ARRAY and STRUCT) offer an efficient way of transferring larger, inter-related volumes of data between the calling block and the block being called. A field or a structure can be transmitted as a complete variable to a called function.
The variables of structured data types can only be saved in a data block or in the local data stack. Consequently, the actual parameter must be declared either in a data block (global or instance DB) or in the local data stack for the called block.
For the purposes of the transfer, a parameter of the same data type as the actual parameter being transferred must be declared in the called function. The supply of these parameters (data type: ARRAY, STRUCT, DATE_AND_TIME and STRING) must take place symbolically.
The LAD/STL/FBD editor checks the compatibility of the data types of the actual parameter and block parameter during transfer of parameters to a function. The actual parameter transfer to the called function is performed by a pointer with a DB number and area-crossing pointer. This pointer is created in the L-stack of the calling block by the CALL macro.
The variables of a structured data type may only be saved in the local data stack (TEMP variable in the FC12) or in a data block (DB5).
The pictures and downloads in this FAQ were created with STEP 7 version V5.4.
If you regularly use function blocks during your structured programming, you will require a separate instance data block for each FB call. In the case of very small FBs, the instance DBs also often comprise no more than a few words. By making frequent calls to these small FBs, and given the instance data blocks generated in the process, your program may, on occasions, become very unclear, or you may reach the maximum number of DBs supported by your CPU.
Since an instance DB may be much longer than is actually required for an FB, several instance DBs can be combined in one multiple instance. However, one condition is that all the combined calls must be programmed in one FB. Furthermore, the FB which you are using must possess multiple instance capability. This entry contains the following two sets of instructions:
Table 1: Programming multiple instances and updating calls for changed instances
Table 2: Subsequent declaration of whether or not existing FBs possess multiple instance capability.
Table 1 describes the procedure for programming a multiple instance and for updating calls for changed instances:
In the SIMATIC Manager, create the FB in which you wish to create your multiple instance and open it. In the static area of the interface, enter the name which you wish to use to call the instance in the program later on. Enter the FB or the SFB, which you wish to call, as the data type.
Fig. 01 shows an example of how to declare the instance in the FB interface.
Call the instance in your program. You can either select the instance from the catalog under "Multiple instances" and drag & drop it into your network or call the instance using the CALL instruction.
Note on STEP 7 V5.4 SP2:
If the multi-instances are not listed in the Catalog View in the LAD/FBD editor, we recommend inserting a function block (as dummy) by the static variables in the declaration and then deleting it again. The multi-instances are then available again for selection.
Now assign parameters to the block inputs and outputs and save the FB. You can now call the FB using your multiple instance in the program (e.g. OB1). An instance data block is created for you to monitor.
When you create multiple instances, please bear in mind that the FB, which is called as a multiple instance, is always created first and then assigned a multiple instance call. If you do not follow this procedure, there might be inconsistencies in the program. These inconsistencies also occur if you make changes to a multiple instance.
Once you have made changes to an instance, open the block from which the call is to be made. While the calling block is being opened, messages will appear indicating that changes have been made to the interface for a UDT or for a local tag for declared FBs, and that a time stamp conflict has occurred in at least one block call. Acknowledge these messages with OK. The call instance which has been changed is highlighted in red in the LAD/STL/FBD editor.
In order to update the block call, right-click the block and then select "Update Block Call..." in the pop-up menu that opens.
In the subsequent dialog box, click OK to perform the interface update.
Note on STEP 7 V5.3:
When you attempt to update the block call using the function "File > Check and Update Accesses", the STEP 7 V5.3 is unable to find any unique assignment between the variables, and the call remains red. Nor is it possible to make a correction by updating the call via "Edit > Call > Update". The only possible way of updating the call is to delete the call, update the interface in the declaration and then call the block again as a multiple instance. If you have deleted variables in the interface of an FB, you should correct all the multiple instance calls via the function "Edit > Call > Update" without using the "Check and Update Accesses" function beforehand. Once you have updated these multiple instance calls, you can then use the "Check and Update Accesses" function again as normal.
We recommend running a block consistency check after updating the block call. In the SIMATIC Manager, mark the block folder in the S7 program, right-click and select the "Check block consistency..." function. The structure of your S7 program then appears.
Compile the program via the "Program > Compile All" function or via the second button on the toolbar. After compilation, your STEP 7 program will be consistent.
Whenever you create a new function block, multiple instance capability is set as the default (Fig. 06) in the block properties. You can also change this.
Once you have created the block, multiple instance capability can only be changed afterwards via a lengthy routine because the block cannot be reset in the object properties. It only shows you whether or not your block possesses multiple instance capability.
Table 2 describes the procedure to show how to declare existing FBs as possessing, or no longer possessing, multiple instance capability afterwards:
In order to make a subsequent declaration that a function block possesses, or no longer possesses, multiple instance capability, open the LAD/STD/FBD editor for the block in question and generate a source for the FB via the function "File > Generate source...".
Select your project from the following dialog box and save the source in your source folder, which is located in the S7 program.
In the "Generate source <name_block>" dialog box (Fig. 07), go to the list on the left and select the block in which you wish multiple instance capability to be enabled or disabled and click the arrow button to add it to the list on the right. Click "OK" to close the dialog window.
Close the LAD/FBD/STL editor and open the source which you have created in the source folder in the SIMATIC Manager. Multiple instance capability depends upon an attribute being entered under code line "Version : 0.1".
If you wish to declare that your FB possesses multiple instance capability, delete the "CODE_VERSION1" attribute.
If you wish to declare that your FB no longer possesses multiple instance capability, enter the "CODE_VERSION1" attribute in Fig. 08.
Save and compile the source. Your block is now subsequently declared to possess, or no longer possess, multiple instance capability.
You now have to re-compile all the blocks which you call in the block which you have just declared to possess, or no longer possess, multiple instance capability. In order to do this, we recommend that you perform a block-consistency check (described in Table 1, No. 6).
The download contains the three system function blocks SFB3 "TP" which are called as multi-instances in FB1. FB1 and its instance DB are called in OB1. Copy the "Multiins.exe" file into a separate folder on your hard disk and then run the file with a double-click. The project is unpacked automatically. You can then edit the program with STEP 7.
Runnability and test environment:
The example can be used on all the CPU types of SIMATIC S7-300, S7-400, C7 and WinAC. The following table lists the components that have been used to create this entry and verify the functions described.
Intel(R) Pentium(R) M processor 1.73GHz
PC operating system
How do you update invalid block calls (time stamp conflicts) in calling blocks?
Instructions: If you make changes to a block which is called in another block, or if you change a UDT definition which is used in a DB, FC, FB or in another UDT, this gives rise to a time stamp conflict. The time stamps (code and interface time stamp of the blocks) are used to monitor consistency in the STEP 7 program. There is more information available about the time stamps in the Online Help in STEP 7 under
Time Stamps as a Block Property and Time Stamp Conflicts
Time Stamps in Instance Data Blocks
Time Stamps in UDTs and Data Blocks Derived from UDTs
Time Stamps in Logic Blocks
Updating Block Calls or UDT Applications
If you have made changes to a block (FB, FC, DB) in the interfaces, the following error message appears when the calling block is opened:
"There is a time stamp conflict with at least one block call.".
After clicking OK to acknowledge, the called block which has been changed appears in red in the LAD/STL/FBD editor. The table below describes a series of possibilities or remedies for remedying time stamp conflicts in blocks:
Menu command: "Check and Update Accesses"
This instruction is used to check all operands for type compatibility; if any errors are discovered, they are highlighted in red. Furthermore, the data blocks are updated or restructured, and the call interfaces are updated insofar as possible.
Open the LAD/STL/FBD editor for the calling block and update the block call via "File > Check and Update Accesses".
If, for example, you have removed variables from the interface for the called block, then STEP 7 cannot find a unique assignment between the variables, and the call remains red. In this case, proceed to No. 2 or perform the "Updating Block Calls" function.
Menu command: "Edit > Go To > Next Error"
After opening the LAD/STL/FBD editor, click "Edit > Go To > Next Error" to automatically jump to the block call which is highlighted in red.
Updating Block Calls
Click the block highlighted in red in the LAD/STL/FBD editor or apply the function described in No. 2. The "Edit > Call > Update" menu command can be used to update any block which has become invalid. The following interface changes in the called block are then automatically updated:
Inserting and deleting parameters.
Changing parameter names and types.
Changing the order (recopying) of parameters.
If you click the "Update..." button, this will take you to the "Interface Update" dialog box. In this dialog box, the left pane shows the block prior to the interface change, and the right pane shows the block as it currently is. You can now update the existing parameters in the old box. This involves selecting a parameter from the old block and copying or moving it to the new block.
Once you have performed an interface update and clicked "OK" to exit the dialog, the invalid block is replaced by the updated block.
Deletion and new entry of the block call
The block call can also be updated by deleting the block call and re-entering it.
If you click the FB in FBD view to highlight it and delete the block via "Edit > Delete", the instance DB is also automatically deleted.
The entire line (e.g. CALL FB1,DB1) has to be deleted in STL view.
Then call the block, including the instance DB, again and confirm the subsequent message with "Yes".
The instance DB or block call are now updated and can be saved in the LAD/STL/FBD editor.
Further processing of a DB if the UDT used in the block has been changed If, for example, you have created a UDT (used-defined data type) variable, the data block has to be updated every time the UDT is changed. As soon as you open the data block, the error message shown in Fig. 07 appears:
The message also indicates that the UDT's time stamp is more recent than the data block's. When you acknowledge the message described above, the variables of the UDT are marked in red. In addition you see the structure of each UDT before the UDT was changed. Update the block call with the menu command "File > Check and Update Accesses".
Perform the block-consistency check and compile the entire STEP 7 program in the block-consistency check via the function "Program > Compile all". The block consistency check function automatically clears the majority of all time stamp conflicts and block inconsistencies. You can also find more information is our entry entitled
"How do you perform a block-consistency check following changes in the STEP 7 program?"
Entry ID 5416540
Keywords: User-defined data type
How do you perform a block-consistency check following changes in the STEP 7 program?
Instructions: The block-consistency check is used to scan for inconsistencies caused by changes to interfaces and to rectify them. The table below describes the procedure for checking consistency within the entire block folder or within the entire program in an S7 station.
In the SIMATIC Manager, mark the block folder within an S7 program and open the "Check block consistency" dialog box;
either via the menu command "Edit > Check block consistency ..." or
right-click and then select the "Check block consistency ..." function in the pop-up menu that opens.
The structure of your S7 program then appears.
You can check the blocks' consistency in this display. If a block is marked with a red cross (in this example, OB1 and FB1 in Fig. 01), this indicates that there is an interface conflict in that block. The block responsible is marked with a yellow exclamation mark ( FC1, in this case).
In order to determine the precise cause of the interface conflict, compile the entire program either with the menu command "Program > Compile all" or by clicking the "Compile all" button (Fig. 02).
All the blocks are now compiled one after another. If an error occurs during compilation, the cause is flagged up in the output window by a red circle.
The individual blocks are opened by double-clicking the corresponding error messages. The invalid block call is highlighted in red. Update the block call. You can find further information on how to update block calls in our entry entitled
"How do you update invalid block calls (time stamp conflicts) in calling blocks?"
Entry ID: 12216780.
After the time stamp conflict has been rectified and the block has been saved, the error-related symbol disappears from the reference tree. The program is now consistent.
Note: The block consistency check is currently supported by the following SIMATIC software products:
STEP 7 from V5.1 onwards
S7-GRAPH from V5.2 onwards
S7-HiGraph from V5.2 onwards
S7-SCL from V5.3 SP1 onwards
All other programming languages support the consistency check and cannot be compiled with the "Compile all" function.
If the consistency check reveals time-stamp conflicts or interface changes, take the following steps:
Double-click the block in question in the SIMATIC Manager to open it and re-compile it with the appropriate compiler.
Perform this in consecutive order for all the blocks with time-stamp conflicts and changed interfaces.
The block-consistency check is then called again.
How do you determine the block number of the "Data Types for Parameters" in the program and how can you pass this parameter on to an FC?
Using the following program codes, you can determine the number of the "Data Types for Parameters" (BLOCK_FC, BLOCK_FB, TIMER or COUNTER).
Example 1 for function blocks
In FB1, the "Time_1" variable of the "Timer" type is declared in the variable declaration and when FB1 is called in FB2, the "Time_1" variable is parameterized with the "T5" timer. The number 5 is determined for "T5" in the program code shown in Fig. 01.
Example 2 for functions
In FC1, the "Time_1" variable of the "Timer" type is declared in the variable declaration and when FC1 is called in FC2, the "Time_1" variable is parameterized with the "T8" timer. The number 8 is determined for "T8" in the program code shown in Fig. 02.
In the case of function blocks with multi-instances, you have to make an addition to the program in Fig. 01:
TAR2 //Address offset of the multi-instance
+AR1 //Add address offset of the multi-instance to the current address
When a function (FC) is called, it is not permissible to transfer directly a parameter of the "BLOCK_DB" type, for example. If you attempt to use a parameter type as current parameter when a function is called, you get the following error message:
"Illegal parameter assignment for <parameter name>"
It permissible to pass on a BLOCK_DB parameter type only when an FB is called (from an FB or an FC).
Direct passing on of parameter types is not permissible when a function is called (from an FB or an FC). More detailed information on this is available in the Online Help of STEP 7 under the topic of "Legal data types in the transfer of parameters".
However, if you still wish to pass on information from the BLOCK_DB parameter to an FC, the DB number can be determined and be transferred in an FC call by means of an elementary data type (e.g. WORD).
In the following example, the FB100 function block has an IN parameter of the "BLOCK_DB" (InData) type. In order to pass on this parameter during an FC101 call, the number of the data block transmitted with "BLOCK_DB" is determined and is saved in a temporary WORD variable (DB_No.). When the function is called, the data block number is transmitted as a WORD parameter instead of the BLOCK_DB parameter.
If the interface of the caller FB can be made with a WORD parameter for transferring the DB number, this parameter can be passed on directly to the FC that is being called.
What is the difference between the CALL statement and the UC or CC call statement?
The CALL statement is always used to call FBs, FCs, SFBs and SFCs absolutely, i.e. the specified block is always called and processed independent of the condition. The CALL operation is followed by the list of block parameters (IN, OUT and INOUT parameters).
Function blocks and functions can also be called with the RLO (result of logic operation)-independent UC call statement and with the RLO-dependent CC call statement. The UC call statement is an absolute instruction and calls the block independent of the RLO. In the case of the conditional CC call statement, the block is only called if the RLO is "1". Unlike the CALL call statement you must observe the following conditions for the UC and CC call statements:
that the called functions do not have any block parameters,
that the called function blocks do not have any instance data blocks and, thus, no block parameters or static local data either.
Fig. 1: UC and CC call statements in the LAD/STL/FBD editor.
The UC call statement calls the FB2 block independent of the result of the logic operation. The FB3 block is only called by the CC call statement if input E200.0 equals "1".
The UC and CC call operations make no distinction between functions and function blocks during their execution. Both types of blocks are treated equally.
Call function block
with a block parameter
with an instance data block
(including static local data)
without a block parameter
without a block parameter
without an instance data block
(no static local data)
without a block parameter
without a block parameter
without an instance data block
(no static local data)
Table 1: Differences between the CALL statements and the UC or CC call statements
UC (Unconditional Call), CC (Conditional Call).
What is the difference between an instance data block and a global data block and how does a CALL call influence the DB register?
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)"
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).