BLOCK_FC Parameter Type in Siemens TIA Portal Technical Reference

Overview

The BLOCK_FC parameter type is a system-defined data type in the Siemens SIMATIC S7-300/400/1200/1500 programming environments (STEP 7 V5.x and the TIA Portal) that stores a 16-bit reference to a Function (FC) block. Unlike INT or WORD, a variable declared as BLOCK_FC can only receive a Function block as its actual value. The compiler and runtime system treat the value not as a generic integer but as a valid FC block number, which makes it useful when the calling code must remain decoupled from the absolute number of the FC being executed.

Within a Function Block (FB), a Function (FC), or a System Function Block (SFB), you can declare an IN, IN_OUT, OUT, STAT, or TEMP parameter as BLOCK_FC. At call time, the calling block provides a specific FC, and the receiving block can use that reference internally, for example to dispatch logic or to wrap the passed FC inside a higher-level algorithm. The most common motivation is library portability: a packaged library FB can accept any concrete FC number, eliminating the need to keep a fixed FC numbering scheme between projects.

BLOCK_FC Data Type Specification

Parameter Types in SIMATIC S7

BLOCK_FC belongs to the family of parameter types in STEP 7 / TIA Portal. Parameter types are 16-bit or larger constructs that point to a runtime object (a block, a timer, a counter) or describe a memory area (POINTER, ANY). The following table lists all parameter types available in S7-300/400/1200/1500 with their widths and purpose.

The complete specification for parameter types and their permissible usage is documented in the STEP 7 programming manuals. See the SIMATIC S7-1200/1500 system manual and the STEP 7 (TIA Portal) programming and operating manual for the latest reference.

Declaration Syntax in TIA Portal

In the block interface of an FB or FC, add a formal parameter and select BLOCK_FC from the data type column. The declaration can be made in either the input, output, in/out, static, or temp sections depending on the desired directionality.

ST (Structured Text) interface excerpt:

FUNCTION_BLOCK FB_Dispatcher
VAR_INPUT
    i_FormatFC : BLOCK_FC;    // Accepts any FC at call time
    i_Enable   : BOOL;
END_VAR
VAR
    s_Buffer   : STRING[80];
END_VAR
BEGIN
    // Body, see implementation example below
END_FUNCTION_BLOCK

LAD/FBD view: In the block interface editor, choose Name = i_FormatFC, Data type = BLOCK_FC, Comment = FC executed by dispatcher. The drop-down will show only the system parameter types alongside the elementary and complex types.

When the block is called from another block, the actual value passed must be a real FC symbol from the project. Numeric literals such as 5 are rejected by the compiler.

// Caller code
FB_Dispatcher_DB(
    i_FormatFC := FC_FormatInt,   // FC symbol from project
    i_Enable   := TRUE
);

Why Use BLOCK_FC: Practical Use Cases

Direct invocation (CALL FC5) is the simplest pattern and is the right choice for the majority of code. BLOCK_FC addresses four situations that direct call cannot handle cleanly.

1. Resolving FC Number Conflicts in Imported Libraries

The standard library in STEP 7 / TIA Portal ships FC2 CONCAT (string concatenation), FC3 INSERT, FC4 DELETE, FC5 MID, and similar IEC functions. If a project already uses those FC numbers for proprietary code, the imported function is renamed to a free number (for example FC17, FC18) to avoid collision. With BLOCK_FC, the call site is a parameter, not a hard-coded CALL, so the renamed function is still consumed correctly. This pattern eliminates the need to track and reconcile block numbers across machines and projects.

2. Building Portable, Reusable Function Libraries

A library FB such as FB_DiagnosticShell can expose an IN of type BLOCK_FC. The user of the library decides which concrete FC (e.g. FC_FormatInteger, FC_FormatFloat, or a custom format routine) is passed in. The library is therefore decoupled from the specific implementation and can be copied into different projects without source changes.

3. Renaming Blocks Without Touching the Consumer

When a function must be renamed (e.g. FC2 CONCAT → FC17 CONCAT_LIB to resolve a collision), every CALL FC2 in the program must be updated. If the call sites use BLOCK_FC, the consumer passes the new symbol and the rest of the program continues to compile and run unchanged.

4. Dispatcher / Strategy Patterns

An FB can host a CASE structure that branches on the numeric value of the BLOCK_FC parameter to select between alternative algorithms, log which function was provided, or feed the block number into system calls that consume a block identifier (for example, SFCs that operate on block attributes).

Direct Call vs. Block Transfer

Use direct CALL FC n when the FC number is part of the program's fixed design. Reserve BLOCK_FC for parameterised, library-style, or rename-resilient code.

Implementation Example: Reusable Library FB

The following ST snippet shows a complete FB_FormatDispatcher that takes a BLOCK_FC, a WORD value, and returns a STRING. Internally the dispatcher simply records which FC was provided and calls it indirectly through a CASE on the block number; this is purely illustrative and demonstrates the parameter passing mechanics, not an indirect call mechanism (STEP 7 / TIA Portal do not support indirect CALL on arbitrary FC numbers, so the dispatcher would in practice invoke the FC through a wrapper or an ANY parameter when runtime flexibility is required).

FUNCTION_BLOCK FB_FormatDispatcher
TITLE  = 'Format dispatcher using BLOCK_FC parameter'
VERSION : '1.0'
VAR_INPUT
    i_FormatFC   : BLOCK_FC;   // FC to be used for formatting
    i_Value      : INT;        // Value to format
    i_Enable     : BOOL;       // Process trigger
END_VAR
VAR_OUTPUT
    o_Result     : STRING[80];
    o_Status     : WORD;        // 16#0000 = OK, 16#8001 = no FC assigned
END_VAR
VAR
    s_Formatted  : STRING[80];
END_VAR
BEGIN
    o_Status := 16#0000;
    o_Result := '';

    IF NOT i_Enable THEN
        RETURN;
    END_IF;

    // Example: write the FC number to the result for diagnostics
    // Real libraries use the FC reference to call a wrapper block.
    // STEP 7 does not allow CALL <variable> for FCs; the
    // dispatcher pattern therefore works on a fixed CASE on
    // the block number, or the consumer performs the call.
    CASE i_Value OF
        0: o_Result := 'Zero';
       10: o_Result := 'Ten';
      100: o_Result := 'Hundred';
    ELSE
        o_Result := 'OutOfRange';
        o_Status := 16#8001;
    END_CASE;

    // Note: i_FormatFC is monitored in the instance DB. The
    // symbol is consumed by callers that need to chain calls.
END_FUNCTION_BLOCK

Caller in OB1:

// OB1 - cyclic main
FB_FormatDispatcher_DB(
    i_FormatFC := FC_FormatInt,   // real FC symbol from project library
    i_Value    := MW10,
    i_Enable   := TRUE,
    o_Result   => DB_Log.Text,
    o_Status   => MW20
);

Alternative: chaining the FC reference. The receiving FB can hand the same BLOCK_FC parameter on to a downstream FB, allowing a multi-stage pipeline without any of the intermediate blocks knowing the absolute FC number.

FUNCTION_BLOCK FB_PipelineStage
VAR_INPUT
    i_FormatFC  : BLOCK_FC;
END_VAR
VAR_OUTPUT
    o_FormatFC  : BLOCK_FC;
END_VAR
BEGIN
    o_FormatFC := i_FormatFC;   // forward the reference
END_FUNCTION_BLOCK

Related Parameter Types

BLOCK_FB

Identical semantics to BLOCK_FC but for Function Blocks. Use it when an FB must accept a callable FB reference; the receiving block typically uses it to CALL FB n, DBx with the same instance data. Block numbers range 0 to 65,535, in practice assigned automatically by TIA Portal.

BLOCK_DB / BLOCK_SDB

Stores a 16-bit reference to a data block (or system data block). Common pattern: an FB accepts a BLOCK_DB input and uses OPN or extended DB syntax to access data inside whatever DB the caller supplies. This is the classic recipe for generic communication, recipe, or HMI data handlers.

BLOCK_SFB / BLOCK_SFC

References to system function (blocks). Their numbering is fixed by the CPU firmware and cannot be reassigned, so the practical value of BLOCK_SFB / BLOCK_SFC is limited. They appear in some legacy libraries.

POINTER and ANY

POINTER (48 bits) and ANY (80 bits) are not block references; they point to data addresses. They are listed here only because the parameter-type concept is the same. ANY is widely used in TIA Portal for variant-like parameters (analogous to Variant in ST) and is documented in the STEP 7 (TIA Portal) manual.

Constraints and Limitations

• Formal parameters only. A BLOCK_FC tag cannot be declared in a global DB, in VAR_GLOBAL, or in I/Q/M areas. The compiler enforces this rule.
• No indirect CALL on the value. The S7-300/400 instruction set and the S7-1200/1500 TIA Portal do not provide an instruction such as CALL [i_FormatFC]. The runtime cannot dynamically load and execute the FC referenced by the BLOCK_FC tag. The reference must be used symbolically at compile time, or consumed by a wrapper.
• No constant literals. You cannot pass 5 as a BLOCK_FC actual. The actual must be a real FC symbol declared in the project or a referenced library.
• Block type check. The compiler rejects attempts to assign an FB or DB to a BLOCK_FC actual. Use the matching parameter type for each block class.
• Cross-project portability. When you copy a library FB into a new project, the receiver must contain a concrete FC with the same interface (matching IN, OUT, IN_OUT, return value) for the consumer code to compile. BLOCK_FC resolves numbering but not interface compatibility.
• Version dependency. Parameter types behave identically across STEP 7 V5.x and TIA Portal V13 onward, but the symbol-handling rules (e.g. re-assignment of block numbers) are managed by the active master data system in TIA Portal. Renaming a block automatically updates all call sites that pass it as a BLOCK_FC actual.

Verification and Diagnostics

1. Online monitor the instance DB. Open the FB instance DB in the TIA Portal "Watch table" or "Monitor/Modify" view. The BLOCK_FC input appears as a 16-bit WORD showing the actual FC number. Example: i_FormatFC = W#16#0005 means FC5 is assigned.
2. Cross-reference (Go to). Right-click the formal parameter in the block interface and choose "Go to > Usage". TIA Portal lists every call site, including those that pass the FC symbol. This confirms that the renaming of an FC has propagated correctly to all BLOCK_FC inputs.
3. Compile consistency check. Trigger a full "Compile (software rebuild)" after any block rename. The build log will list every block whose interface is broken, including unresolved BLOCK_FC actuals.
4. Symbolic vs. absolute view. Switch the instance DB between "Symbolic" and "Absolute" view. The symbolic view displays the FC number; the absolute view shows the raw 16-bit value. A value of 0 means "no FC assigned" and is a common cause of unintended behaviour if the receiving FB assumes a non-zero reference.
5. Library upgrade propagation. In a typed library (master-copy + types), updating a library and propagating the change automatically updates all consumer projects. With BLOCK_FC, the link is symbolic; with direct CALL FC n, the link is numeric and may be missed if the type information is incomplete.

Best Practices

• Document the expected interface in the FB header. Because the BLOCK_FC actual is resolved at compile time, the FB's documentation must state the required FC interface (inputs, outputs, return value). A mismatched interface will compile but cause incorrect behaviour at runtime.
• Validate the assignment in the FB body. Check the input for a non-zero value at the start of the FB and set a status output if the reference is missing. The default value 0 indicates "no FC assigned".
• Prefer symbolic consumption. Always pass the FC by name (FC_FormatInt) and not by a WORD cast. The compiler can then perform the block-type check and refactor safely.
• Use typed libraries. For commercial or multi-machine deployment, wrap the dispatcher FB in a typed Siemens library (master copy + type). The type system guarantees that consumers see the correct interface after library upgrades.
• Combine with BLOCK_DB for data + code. Many reusable algorithms need both a code block (FC) and a working-data block. Pass both as BLOCK_FC and BLOCK_DB to keep the consumer code free of absolute numbers.
• Reserve direct CALL for project-specific code. If the FC is part of the machine's own logic and will not be reused, a direct CALL FC n is shorter, faster to read, and avoids the 2-byte overhead in the instance DB.

Comparison with Conceptually Similar Mechanisms

Other PLC families implement similar but non-identical mechanisms. The differences matter when porting code or training engineers who work across platforms.

The IEC 61131-3 standard defines elementary and derived data types, but parameter types such as BLOCK_FC are vendor extensions. The closest IEC 61131-3 concept is the function block instance declared as a typed variable, which is closer to an AOI instance than to a numeric block reference.

FAQ