PLC Function Blocks and FBD: Instances, Examples and Testing

Direct answer: what a PLC function block is

A PLC function block is a reusable program unit with a defined interface and, unlike a pure function, the ability to preserve instance-specific internal state between calls. The block is the type or behavior definition. An instance is the allocated memory and runtime identity used when that definition is called. Two motors can use the same motor function-block type while retaining different commands, timers, alarms and operating state.

Function Block Diagram (FBD) is a graphical programming language in which functions, function blocks and other elements are connected to show data or signal flow. A function block and FBD are therefore related but not interchangeable terms: a function block can be called from Structured Text or another supported context, and an FBD routine can contain functions as well as stateful blocks.

IEC 61131-3:2025 Edition 4 describes the current suite as Structured Text, Ladder Diagram and Function Block Diagram, with additional structuring elements for Sequential Function Chart. It does not make every vendor instruction, status member, evaluation rule or data type portable. Treat the standard as a common model and the exact product documentation as the executable contract.

The fastest way to understand a block is to ask four questions: what inputs form its command contract; what outputs expose its result and diagnostic state; what state persists from the previous scan; and what must happen when the call is disabled, interrupted or reset. A diagram that looks intuitive can still fail if any of those answers are implicit.

Function, function block, instance and FBD are different surfaces

A function should behave like a calculation

A function is a strong fit when the result should be determined by the current inputs and no private history is required. A linear scaling calculation, range check or unit conversion is easier to reason about when repeated calls with the same input produce the same output. Vendor implementations may impose their own syntax and supported types, so confirm the platform definition before relying on this as a language-law shortcut.

State can be passed into a calculation explicitly, but doing so does not turn that calculation into a self-contained equipment object. If the caller owns all state, the caller must also preserve it and maintain the sequencing contract.

A function block is a type; an instance holds the history

A timer needs elapsed time and prior enable state. An asynchronous communication block may need a request edge, busy state, timeout, response and error identity across multiple scans. A motor module may remember whether a start request was accepted, which interlock failed first and whether an alarm requires acknowledgment. Those are stateful behaviors.

Create a separate instance for every independently controlled object unless the block documentation explicitly describes another pattern. Reusing one instance for multiple devices in the same scan can mix their histories. That can produce a fault that appears nondeterministic because the last call overwrites state needed by the first.

FBD is the canvas, not the memory model

FBD makes the connected flow visible, but appearance does not prove execution semantics. Blocks can have retained state, enable behavior, asynchronous completion or order dependencies. Feedback paths need deliberate design. Wires show connections; they do not necessarily show the precise order in which every product evaluates elements.

Rockwell's current design considerations recommend FBD for continuous process and drive control, loop control and calculations expressed as circuit flow. That is product guidance, not a universal rule that every control loop belongs in FBD. The maintenance team, safety boundary, testability, version-control workflow and target platform all affect the language decision.

Design a function-block interface as an engineering contract

An interface should let the caller command the behavior, observe its result and diagnose why the requested result was not achieved. Avoid exposing private implementation details merely because the programming environment makes them easy to browse.

Use inputs for requests, not hidden global commands

Hidden global tags make a block hard to reuse and test. Pass required commands and conditions through the declared interface, or inject a clearly typed structure when the platform's library pattern supports it. Global emergency or mode data may be unavoidable in a legacy project, but the dependency should be documented and covered by tests.

Make units and validity explicit

SpeedRef : REAL is incomplete if the caller cannot tell whether it means revolutions per minute, percent, hertz or engineering units. Pressure : REAL is incomplete if a disconnected transmitter can be represented as a plausible zero. Include units in the variable name, type, documentation or configuration object, and carry a validity or quality indication when invalid data changes behavior.

Separate command acceptance from physical achievement

A Start request is not proof that a motor is running. The block may accept the request, energize an output and wait for auxiliary or speed feedback. Expose states such as StartAccepted, Starting, Running, AtSpeed and FailedToStart only when they have distinct operational meaning. Do not combine them into one ambiguous On bit.

Structured Text function-block example

The following vendor-neutral teaching example shows the shape of a stateful motor block. It is not safety logic, and exact declarations, enumerations, timers and instance calls must be adapted to the target platform.

FUNCTION_BLOCK FB_Motor
VAR_INPUT
    Enable       : BOOL;
    Start        : BOOL;
    Stop         : BOOL;
    Reset        : BOOL;
    Permit       : BOOL;
    RunFeedback  : BOOL;
    StartTimeout : TIME := T#5s;
END_VAR
VAR_OUTPUT
    RunCommand   : BOOL;
    Ready        : BOOL;
    Running      : BOOL;
    Faulted      : BOOL;
    ErrorId      : UINT;
END_VAR
VAR
    startEdge    : R_TRIG;
    startTimer   : TON;
    requested    : BOOL;
END_VAR

startEdge(CLK := Start);

IF Reset AND NOT Enable THEN
    Faulted := FALSE;
    ErrorId := 0;
END_IF;

IF Stop OR NOT Enable OR NOT Permit OR Faulted THEN
    requested := FALSE;
ELSIF startEdge.Q THEN
    requested := TRUE;
END_IF;

RunCommand := requested AND Permit AND Enable AND NOT Faulted;
startTimer(IN := RunCommand AND NOT RunFeedback, PT := StartTimeout);

IF startTimer.Q THEN
    Faulted := TRUE;
    ErrorId := 101;
    requested := FALSE;
END_IF;

Running := RunCommand AND RunFeedback;
Ready := Enable AND Permit AND NOT Faulted AND NOT Running;
END_FUNCTION_BLOCK

The example deliberately makes several policies visible. Stop and lost permission remove the request. Reset is accepted only while disabled. A start timeout latches a diagnostic and drops the request. Running requires both command and feedback. A real equipment module may need local/remote arbitration, restart policy, feedback-drop detection, first-out interlocks, alarm acknowledgment and separate unavailable versus faulted states.

Declare and call separate instances:

VAR
    Motor_1 : FB_Motor;
    Motor_2 : FB_Motor;
END_VAR

Motor_1(
    Enable := AutoMode,
    Start := CmdStart1,
    Stop := CmdStop1,
    Reset := CmdReset1,
    Permit := GuardedPermit1,
    RunFeedback := Aux1,
    StartTimeout := T#4s
);

Motor_2(
    Enable := AutoMode,
    Start := CmdStart2,
    Stop := CmdStop2,
    Reset := CmdReset2,
    Permit := GuardedPermit2,
    RunFeedback := Aux2,
    StartTimeout := T#6s
);

Do not copy this example into a production controller without a design review. GuardedPermit is only a name here; a standard PLC Boolean and normal function block do not become a certified safety function because they refer to a guard. Risk reduction must use the required architecture, components, validated safety application and site process.

Trace function-block behavior scan by scan

Most PLC logic executes repeatedly. A stateful block reads current inputs, uses retained values from prior calls, updates its internal state and produces outputs. The exact input-image and output-update model varies, but scan-level reasoning remains essential.

Consider a rising-edge detector called every scan:

If the block is conditionally skipped on Scan 4, its private previous state may remain 1; the next Start=1 call may then produce no edge. Some vendor blocks define enable semantics that differ from this simplified model. Test the exact pattern rather than assuming that “not called” means “reset.”

Decide what happens when a call is skipped

Conditional execution can freeze timers, retain outputs, drop completion pulses or violate the required call-every-scan contract of an asynchronous block. Prefer a continuous call with an explicit Enable or command input when the library documentation expects cyclic service. If the call must be skipped, specify the retained-output and restart behavior.

Do not issue a second asynchronous request while busy

Communication, motion and device-management blocks often span cycles. A common contract uses Execute, Busy, Done, Error and ErrorId. The caller presents a clean request edge, waits while busy, consumes the result and then returns the command to its required reset state. CODESYS library guidance distinguishes edge-triggered xExecute behavior from level-controlled xEnable behavior; those patterns should not be mixed casually.

Understand FBD signal flow and execution order

FBD is effective when the diagram tells a process story: measurement becomes engineering units, validity and permissives qualify it, control calculates a command, and output handling drives the actuator. Keep the normal signal direction consistent, name intermediate values and avoid long wires that cross unrelated control paths.

Do not infer all execution order from left-to-right placement. Rockwell Logix Designer, CODESYS, Siemens and other environments expose different rules and controls. Some derive order from data dependencies, some provide execution-order markers, and some require special handling for feedback loops. Copying an FBD between software versions can also change availability or interpretation of elements; Rockwell's FBD manual specifically documents version and element considerations.

Use an execution-order review when:

• one output feeds a block earlier in the visual flow;
• several blocks write or mutate shared data;
• a limiter, selector or manual override must run before a controller;
• an asynchronous block's status controls a second request;
• online edits or copied routines may alter the generated order;
• the design depends on a one-scan delay.

Create test probes at boundaries and record expected scan values. If a loop depends on a prior-cycle value, name that memory explicitly instead of relying on a visually circular wire to explain it.

Build reusable equipment modules without building a black box

A reusable block should reduce duplication while increasing evidence. It should not hide every condition inside a monolith that maintenance cannot diagnose. Keep one coherent responsibility, define its state machine, expose meaningful first-out information and provide a compact operator-facing status model.

Prefer composition over one universal block

A motor equipment module can compose command arbitration, permissive evaluation, feedback monitoring and alarm handling. A conveyor module can then use one or more motor modules plus product sensing and sequence behavior. A line module can coordinate conveyors. This hierarchy is easier to test than a single block with hundreds of loosely related parameters.

Version the public interface deliberately

Changing internal implementation without changing behavior may be a patch. Adding an optional diagnostic output may be backward-compatible on one platform and disruptive on another. Renaming a member, changing a type or reversing a default can break many instances. Record library version, change reason, migration action and regression evidence.

Test a PLC function block as a deterministic component

Testing begins with a behavioral contract, not an online animation. List the input sequence, expected output at each scan, retained state, timeout, error identity and reset condition. Include normal, boundary, interruption and recovery paths.

Minimum motor-block test matrix

Run tests in a simulator, test framework or isolated controller appropriate to the platform. Do not force outputs on installed machinery merely to satisfy a software test. Integrated tests must include the electrical device, feedback, communications, HMI, alarms, sequence and safe-state behavior under an authorized plan.

Make failures explain themselves

When a test fails, preserve the input timeline, block version, instance values, scan or task context and first diverging output. A screenshot of the final state is often insufficient. Exported traces or a structured scan table make timing regressions reviewable.

Translate vendor terminology without claiming equivalence

The concepts overlap across ecosystems, but names do not map one-to-one.

Siemens multi-instances can place the instance data of called FBs within a higher-level FB's instance data, reducing separate instance DBs while preserving separate sub-instance state. CODESYS declares a function-block instance as a variable and calls it with arguments. Rockwell AOIs provide reusable instruction definitions but have their own parameters, local tags, prescan behavior, signatures and version workflow. None of these should be translated mechanically without a platform-specific design review.

Debug function blocks and FBD systematically

Start at the public contract. Confirm the instance being observed, command edge, enable state, permissives, process-data validity, task execution and whether the block is actually called. Then inspect internal state only far enough to explain the first unexpected public output.

Avoid changing several internals at once. Reproduce the smallest failing timeline, identify the first divergence from the contract, correct one cause and rerun the complete regression set. If the block controls hazardous motion or a critical process, use the site's approved change, test and return-to-service process.

Choose function blocks, FBD, Structured Text or ladder deliberately

Use function blocks when a reusable stateful contract clarifies the system. Use FBD when connected signal or control flow is the clearest representation and the target's execution semantics are understood. Use Structured Text when algorithms, data structures, loops or text-based review dominate. Use ladder when maintenance-visible Boolean conditions, interlocks and discrete control are best expressed as rungs.

The languages can cooperate. An SFC can coordinate phases, each phase can call a reusable equipment function block, a control-loop routine can use FBD, and a calculation can use Structured Text. The architecture should give each behavior one clear owner and avoid writing the same output from several language surfaces.

Frequently asked questions

What is a function block in PLC programming?

A function block is a reusable program-unit type with a declared interface and instance-specific memory. Each instance can preserve internal values between calls, which supports timers, communication transactions, equipment modules and other stateful behavior. Verify the exact call, initialization and retention rules in the target platform.

What is the difference between a function and a function block?

A function is normally used for a calculation without private instance history, while a function block can retain state in each instance. Vendor rules and supported types differ, so use the product manual for the executable details rather than treating the distinction as a portability guarantee.

Is Function Block Diagram the same as a function block?

No. Function Block Diagram is a graphical programming language. A function block is a reusable, potentially stateful program unit that can appear in FBD or be called from another supported language. An FBD routine can also contain stateless functions and vendor instructions.

Does every function-block instance need separate memory?

Yes, independently controlled objects need independent runtime state. Some platforms allocate that state in separate instance objects while others support multi-instance or nested storage. The physical storage layout differs, but each logical instance must not unintentionally share private history.

Can I call the same function-block instance twice in one scan?

Some environments allow it syntactically, but the second call operates on state changed by the first and can make behavior difficult to reason about. Use distinct instances for independent objects, and call one instance more than once only when its documented contract and tests deliberately support that pattern.

What happens if a function block is not called for one scan?

It depends on the implementation. Private state and outputs may remain unchanged, timers may stop being serviced, and completion pulses may be missed. Many asynchronous blocks expect a cyclic call. Test and document the exact target behavior instead of assuming that a skipped call resets the block.

Is FBD executed from left to right?

Do not assume a universal left-to-right rule. Products determine order through data dependencies, configured execution order or other compiler/runtime rules. Feedback paths and shared-data writes need particular care. Confirm the exact controller version and expose the intended order in tests.

How should an asynchronous function block be called?

Follow its documented handshake. A common pattern applies a clean execute edge, keeps the block called while busy, does not change request parameters mid-operation, captures done or error, returns execute to the re-arm state and only then issues the next request.

Are Siemens FBs, CODESYS function blocks and Rockwell AOIs equivalent?

They share reuse and encapsulation goals, but they are not interchangeable. Instance storage, parameters, lifecycle, prescan, signatures, online changes and execution behavior differ. Translate the design intent and tests, then implement it using the target platform's documented construct.

Can a normal function block implement a safety function?

A standard function block in a normal PLC is not made safety-rated by its name or Boolean inputs. Required risk reduction must use the specified safety architecture, certified or otherwise suitable components, approved safety programming environment, validation and applicable machine-safety process.

Primary sources and further verification

This page owns the function-block and FBD concept, design and test intent. Use the function-block reference library below for individual timers, counters, triggers, math and control elements. Use the separate Sequential Function Chart guide when the primary problem is phase or sequence coordination, and the IEC 61131-3 standards pillar for the broader language model.