Function Block Invocation and Subroutine Encapsulation Methods for S7-1200 PLC

Invoking function blocks is akin to setting a one-button operation mode for various small appliances in a kitchen; just press a button, and it will automatically complete a series of actions. In the S7-1200, function blocks serve as “containers” for packaging reusable code, encapsulating commonly used control logic that can be called upon as needed, significantly enhancing programming efficiency and program readability.

Basic Concept of Function Blocks

The program organization units (POUs) of the S7-1200 PLC are mainly divided into three categories: OB (Organization Block), FB (Function Block), and FC (Function). They are like different departments in a company: OB is the general manager, responsible for global scheduling; FB is the department with “memory,” capable of remembering the last working state; FC is like a temporary worker without state, who “forgets” everything after completing a task.

The key feature of a function block (FB) is that it has static variables, which retain their values even after the function block has finished executing, allowing them to be reused in the next call. This feature is implemented through **instance data blocks (DB)**, where the system automatically generates a corresponding instance DB each time an FB instance is created.

Creating and Invoking Function Blocks

Creating an FB in TIA Portal:

Project Tree → Right-click "Program Blocks" → Add New Block → Function Block (FB) → Enter Name → Select Language

Example of Interface Definition:

FUNCTION_BLOCK "FB_Motor"
VAR_INPUT
    Start : Bool;    // Start command
    Speed : Real;    // Speed setpoint
END_VAR
VAR_OUTPUT
    Running : Bool;  // Running status
END_VAR
VAR  // Static variables (memory retention)
    RunTime : Time;  // Runtime counter
END_VAR

Invoking a Function Block:

// Create instance
"MotorDB_1"(
    Start := I0.0,
    Speed := "GlobalDB".SpeedValue,
    Running => Q0.0
);

Parameter Passing Methods

1. Value Passing: Simple data types are passed by value
2. Reference Passing: Modify the original variable through IN_OUT parameters
3. Structure Passing: Pass related parameters as a UDT

// Structure example
TYPE "UDT_MotorParam"
    STRUCT
        Speed : Real;
        AccelTime : Time;
    END_STRUCT;
END_TYPE

Practical Application Tips

Multi-instance Application: The same FB can create multiple instances to control different devices, such as:

"MotorDB_Conveyor"();  // Conveyor
"MotorDB_Mixer"();     // Mixer

Calling Hierarchy: It is recommended not to exceed 4 levels of nesting, modularizing by function:

Main(OB1) → FB_System → FB_Process → FB_Device

Common Problem Solutions

1. Data Loss: Ensure to use static variables to store data that needs to be remembered
2. Instance Confusion: Each instance must have a unique name, and the correct instance should be specified when accessed
3. Increased Scan Cycle: Excessive nested calls will extend the scan cycle; optimization is necessary

Notes: Temporary variables (VAR_TEMP) are cleared after each call; static variables (VAR) retain their values until the next call.

Practical Recommendations

Create a modular temperature control system that encapsulates PID algorithms, sensor acquisition, output control, and other functions using function blocks. Create multiple instances of the same temperature control FB to control different temperature zones. Try adjusting the FB’s interface parameters to experience the advantage of adding new functionalities without affecting existing calling code. Analyze the memory usage of instance DBs and consider how to optimize the use of static variables. Use UDTs to organize related parameters, improving code readability and maintainability.