I predict that in the chapter, I will write the descriptions in my own words, as if I were trying to explain things to a friend. The description may not be professional this way, but my goal is for anyone who reads to understand what is described.
FCs are programming blocks that do not require static variables, that is, they do not need internal information that would be stored from one cycle to another. It is therefore not necessary to assign data blocks, i.e. DBs, to FCs.
In the references, I denote FCs as follows: _FC_
for example: _FC_ Result := ABS (Value);
I repeat because it is important: The internal variables of the FC are valid only within one cycle, they lose their values for the next cycle. If you need to store information, use the FB or call DB, merkel.
FBs are a bit more complex modules than FCs. FBs are able to define cyclical variables, these are static variables. These are not actually stored in the FB, but will be assigned a datablock (DB) to each FB and it will store these variables. These DBs should be called IDBs (instant datablocks) because, unlike global DBs, they are assigned to a specific FB. In addition to storing variables, IDBs are also suitable for storing embedded FBs, this will be discussed later. The IDB will be assigned to a given SC during the first call.
In the references, I denote FBs as follows: _FB_
for example: _FB_ RetVal (INT):= BLKMOV (SRCBLK := source block (VARIANT); DSTBLK ⇒ destination block (VARIANT); ENO ⇒ operation enable );
When we open the newly created Fc or FB (FB in the example) we will see the following image:
Field reports:
Name | FC / FB | description |
---|---|---|
Input | FC and FB | Variables read by modules. |
Output | FC and FB | Variables write by modules. |
InOut | FC and FB | Variables read and then written back by modules. Changes made to the module are reflected in the outputs. |
Static | FB only | static variables: their value is retained because they are stored in the IDB assigned to the FB. If you open the IDB, you can follow the change in the value of the variables there. |
Temp | FC and FB | Temporary variables: they can only be used within the given cycle, they will lose their value at the time of another call. |
Constant | FC and FB | Constant values: their value must not change. |
Return | FC only | the return value of the function, which is the name of the function. In the case of an external call: retval: = Function_name (); |
Calling FCs is easier:
When calling FBs, we have two options:
Let's see this through examples, let's take one of the most commonly used methods, TON:
First method, call with separate IDBs:
Second method, call embedded FBs:
By default, the TIA portal turns on the optimization attribute of DBs, which means that the order of variables in DBs is automatically optimized.
In many cases, this causes serious problems when the given variables have to remain in predefined positions, such as OPC, or typically any similar communication (Modbus, PN, ..) DB. For example, the BLKMOV command does not work with optimized DBs either.
To deactivate, right-click on the DB and select Properties… and then Attributes:
The optimized block access attribute in the menu must be turned off.
For generated DBs, the {S7_Optimized_Access: = 'TRUE'} entry should be modified as follows: {S7_Optimized_Access: = 'FALSE'}.
1: Double click to: Add new external file by External source files menu 2: Choose files and open | |
3: right click to the file 4: choose Generate blocks from file 5: IF the message blocks can be overwriten comming: press OK. 6: Enjoy the code! Think about how much energy and money you have saved yourself, throw me some coin for a coffee through Paypal! |
Post views: 727