Simatic TIA Portal know-how

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.

Add new FC

Add new FC

  • double click to „Add new block”
  • chose „Function”
  • type a new name

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 );

Add new FB

Add new FB

  • double click to „Add new block”
  • chose „Function block”
  • type a new name

When we open the newly created Fc or FB (FB in the example) we will see the following image:

FC / FB variable types

Field reports:

NameFC / FBdescription
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:

  1. the part of the program (FC, FB or OB) from which the FC is to be called must be opened.
  2. drag-and-drop the FC from the „instructions” window, or simply plug it in. For example, after indentation, „LN” FC looks like this: LN (_real_in_)
  3. you need to know, for example from here that the „LN” FC is calling floating-point numbers, ie REAL or LREAL.
  4. the return value must also be given, eg: out:= LN(in); where in and out are REAL.

When calling FBs, we have two options:

  1. each invited sub_FB receives its own IDB
  2. sub_FBs are treated as an embedded function and their data area will be „taped” to the IDB of the calling FB.

Call FB 2 methods

Let's see this through examples, let's take one of the most commonly used methods, TON:

First method, call with separate IDBs:

Using two TON FBs, both calling their own IDBs
Content of one of the IDBs

Second method, call embedded FBs:

In the case of embedding, the functions must be called from the „static” block of the calling FB (just type „TON” for the „data type”. FBs must be called in the program in much the same way, of course the DB call must be omitted.
The image shows the data of the embedded FBs in the IDB of the calling FB. The great advantage of this method is that the program is easy to import / export / copy, as you only need one FB definition.

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 "optimization" attribute of DBs

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
Import source code to the TIA portal
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!
Import source code to the TIA portal

Post views: 641


2022/04/21 15:01
  • de/s7/tia_knowhow.txt
  • Utolsó módosítás: 2022/04/21 15:01
  • (külső szerkesztés)