PLC Programming: Why FB Requires DB While FC Does Not?

In PLC programming, FB (Function Block) and FC (Function) are two commonly used programming elements. Their design purposes and data processing methods differ, which directly leads to FB requiring a DB (Data Block) while FC does not.

Why does FB require DB?

The static variables and input/output parameters of FB need to be persistently stored during each scan cycle of the PLC, and this data cannot be stored in the temporary storage area (L stack) because the data in the temporary storage area is cleared after each call ends. Therefore, FB requires a dedicated DB to store this data.

DB provides independent storage space for each FB call. For example, if an FB is used to control a motor and the PLC program needs to control 10 motors, an independent DB can be allocated for each motor to store their respective operating states, parameters, etc.

With DB, the same FB logic can be reused multiple times without the need to write new code for each call. For instance, an FB can define the control logic for a motor, storing different motors’ operational data (such as speed and status) in different DBs.

Why does FC (Function) not require DB?

FC is a stateless program block, where input and output data are passed through parameters during the call. After FC execution, the internal variable states are not retained for the next call.The temporary variables of FC are stored in the PLC’s local stack (L stack). The L stack is a temporary storage area where data is automatically cleared after the function call ends, thus no additional persistent storage is needed.FC is typically used to perform specific, independent tasks such as mathematical calculations, logical operations, or data format conversions. These tasks do not rely on state retention across cycles.

Comparison of FB and FC

Feature FB (Function Block) FC (Function)
State Retention Stateful, variable states are stored in DB Stateless, data is passed through parameters, not retained after call
Data Storage Requires instance DB to store input, output, static variables Temporary variables stored in L stack, no DB needed
Call Method Instantiated call, DB must be specified Direct call, data passed through parameters
Usage Scenario Complex logic, state tracking, modular programming Simple calculations, logical operations, one-time functions
Multi-instance Support Supported, each instance has an independent DB No multi-instance support (stateless)
Programming Complexity Higher, needs to manage DB and variables Lower, only needs to focus on input/output parameters

Usage Scenarios for FB

Assuming an FB is used to control a conveyor belt, it includes parameters:

Input: Start signal, Stop signal

Output: Running status

Static variables: Running time, Fault count

Each time the FB is called, a DB (e.g., DB10) is specified to store the status of that conveyor belt. If controlling 10 conveyor belts, 10 DBs (e.g., DB10 to DB19) are used, with each DB storing the corresponding conveyor belt’s data.

Usage Scenarios for FC

An FC is used to calculate the average of two input values:

Input: Value1, Value2

Output: Average value

Input values are directly passed during the call, and the FC returns the result through the output parameter without needing to retain intermediate states.

Editor’s Summary:If logic requires state retention across cycles or modular reuse, choose FB+DB; if only performing instantaneous calculations or logic, choose FC.

By appropriately using FB and FC, the structure of Siemens PLC programs can be optimized, improving development efficiency and system reliability.

Leave a Comment