Case Study:
Multi-Motor Control
Using FB Instance Architecture

From Flat Ladder Logic to Modular FB Libraries

This project extends the foundational start/stop motor control work into a fully modular, reusable architecture using Siemens Function Blocks (FBs) and Instance Data Blocks (DBs) — the standard structural pattern for scalable industrial automation programs on the S7 platform. The central design objective was not simply to control a motor, but to build a control library: a reusable software component that can be instantiated multiple times across a line, a plant area, or an entire facility, without duplicating logic.

Two Function Blocks form the core of the system. FB_Motor [FB1] encapsulates all logic and state for a single motor axis — start/stop latching, fault detection, run-time feedback monitoring, and a watchdog timer that flags a failure if the motor does not confirm running within a defined window. FB_LineControl [FB2] acts as the supervisory coordinator, instantiating two FB_Motor instances as multi-instance static variables, routing line-level signals to each motor, and managing a shared reset condition. The result is a two-motor production line managed by a single block call from OB1.

Block Hierarchy & Data Flow

The Siemens S7 execution model enforces a strict separation between logic (Program Blocks) and state (Data Blocks). Unlike CODESYS-based platforms where a function block's static data can be declared inline within the same compilation unit, TIA Portal allocates a dedicated Instance DB for every FB call — either as a standalone DB or as a nested static variable within a parent FB's own DB.

The critical architectural decision here is using multi-instance design rather than creating separate DBs for each motor. When Motor1 and Motor2 are declared as static variables of type "FB_Motor" inside FB_LineControl, their instance data is embedded directly within DB1. This eliminates DB proliferation as motor count grows and keeps the entire line's state visible within a single data structure — which is advantageous for diagnostics, SCADA integration, and HMI variable mapping.

Motor Control Function Block — Interface & Logic

FB_Motor is the atomic control unit — the reusable component that models a single motor axis with all associated control logic. Its interface was designed to be fully generic: it accepts hardware signals as Bool inputs and drives outputs independently, making it suitable for any actuator type that fits the start/stop/feedback paradigm (motors, pumps, fans, conveyors).

Block Interface

Structured Text Logic (SCL)

The block is implemented in SCL (Structured Control Language), Siemens' IEC 61131-3 compliant structured text dialect. SCL is selected over Ladder here because the conditional logic — prioritised fault evaluation, timer management, and output assignment — is more legible and less error-prone in a textual language. The logic evaluates in strict priority order per scan:

(* Priority 1: Fault Reset clears the latched fault state *)
IF #FaultReset THEN
    #Faulted := FALSE;
END_IF;

(* Priority 2: External fault input or run-confirmation timeout latches fault *)
IF #FaultInput THEN
    #Faulted    := TRUE;
    #LatchedRun := FALSE;  (* Immediate de-energise on fault *)
END_IF;

(* Priority 3: Start/Stop latching logic — fault state blocks start *)
IF #Faulted THEN
    #LatchedRun := FALSE;
ELSIF #Start THEN
    #LatchedRun := TRUE;
ELSIF #Stop THEN
    #LatchedRun := FALSE;
END_IF;

(* Run-confirmation watchdog: timer starts with LatchedRun; fault if no feedback *)
#StartTimer(IN := #LatchedRun, PT := T#3s);
IF #StartTimer.Q AND NOT #RunFeedback THEN
    #Faulted    := TRUE;
    #LatchedRun := FALSE;
END_IF;

(* Output assignment *)
#MotorRunning := #LatchedRun;
#Faulted      := #Faulted;

Why SCL Over Ladder for This Block

• Priority-ordered IF-ELSIF chains express fault hierarchy more clearly than parallel ladder rungs — the scan order dependency is explicit in the text
• TON timer calls with named parameters are less ambiguous in SCL than the equivalent coil/contact representation in LAD
• SCL enables compact conditional assignment that would require multiple rungs and intermediate coils in Ladder, increasing the risk of logic errors
• The block is documentation-friendly: self-commenting variable names and structured text read more like engineering specifications than rungs do

Line Supervisor — Multi-Instance Coordinator

FB_LineControl is the supervisory layer responsible for managing two independent motor instances as a coordinated production line. Its role is signal routing: it receives line-level inputs (Start1/Stop1, Start2/Stop2, feedback and fault signals for each axis, and a shared ResetAll) and maps them to the corresponding FB_Motor inputs at each scan. It does not implement its own latching or fault logic — all such behaviour is encapsulated within the FB_Motor instances it contains.

Interface Design

Multi-Instance Static Variable Declaration

The key implementation detail visible in Screenshot 4 is the Static variable section of FB_LineControl: Motor1 and Motor2 are declared with data type "FB_Motor". This instructs TIA Portal to allocate the full FB_Motor interface — including all its static variables — as a nested structure within FB_LineControl's own DB. No separate DBs for Motor1 or Motor2 are created.

(* FB_LineControl SCL body — motor instance calls *)

#Motor1(
    Start       := #Start1,
    Stop        := #Stop1,
    FaultReset  := #ResetAll,
    RunFeedback := #RunFb1,
    FaultInput  := #Fault1
);

#Motor2(
    Start       := #Start2,
    Stop        := #Stop2,
    FaultReset  := #ResetAll,
    RunFeedback := #RunFb2,
    FaultInput  := #Fault2
);

Main Program Block — FB Call & DB Assignment

Organisation Block 1 (OB1) is the cyclic execution entry point for the S7-1200. In this project, OB1 contains a single ladder rung that calls FB_LineControl [FB2] with its assigned instance DB (FB_LineControl_DB [DB1]). All inputs are connected to their corresponding absolute or symbolic addresses — in the simulation environment, test values are wired directly as static literals (e.g., true, false) to validate the calling interface before hardware I/O is mapped.

The rung visible in Screenshot 7 shows the standard Siemens FB call block representation in Ladder: the function block name and its instance DB are shown above the block boundary, input parameters are listed on the left with their connected signal sources, and EN/ENO flow controls execution. The FB runs on every OB1 scan as long as the enable rung is satisfied.

Implementation Evidence

Fig. 01 FB_Motor [FB1] — Full Interface with Static Variables Expanded

Fig. 02 FB_Motor [FB1] — SCL Body: Start/Stop Priority Logic

Fig. 03 FB_Motor [FB1] — First Compile: Warning on Uninitialized Parameter

Fig. 04 FB_LineControl [FB2] — Interface with Multi-Instance Static Variables

Fig. 05 FB_LineControl [FB2] — SCL Body: Motor Instance Calls

Fig. 06 FB_LineControl [FB2] — Clean Compile: 0 Errors, 0 Warnings

Fig. 07 OB1 — FB_LineControl Call Block in Ladder with Instance DB Assignment

Problems Encountered & Resolved

1. Compiler Warning — Uninitialized Static Variable

The initial FB_Motor compilation produced a static analysis warning: "The parameter '#Faulted' might not be initialized." This surfaced because TIA Portal's SCL compiler performs conservative flow analysis — it traces all code paths and flags any variable that could be read before a guaranteed write. In the fault evaluation block, #Faulted is read in the condition of the outer IF statement before it is written in the FaultInput branch. Although the DB initial value of FALSE ensures correct runtime behaviour, the compiler correctly identified that this is not provable from the code structure alone. Resolution: explicit default value assignment in the interface table, ensuring the variable is always initialised at DB creation time. This also improves maintainability — future developers can see the intended initial state without tracing the code logic.

2. Navigating the FB/DB Coupling Model

Understanding that TIA Portal requires the DB to be re-generated and re-downloaded whenever the FB interface changes was a key operational learning. Adding or removing a parameter from an FB's interface renders the associated DB stale — the portal marks it with a warning indicator, and the program will not download cleanly until the DB is re-compiled. This is a tighter coupling than CODESYS, where interface changes are handled more transparently. Managing this sequence — change FB interface → compile FB → compile DB → download — is an essential operational habit in Siemens projects.

3. Cloud Simulation Constraints

PLCSIM Advanced, available in the local TIA Portal installation, provides full I/O simulation including force tables and watch tables for live variable monitoring. The TIA Portal cloud environment used here does not support PLCSIM, which meant the simulation phase — where inputs would be forced and output states observed in real time — could not be executed. This required a shift in validation strategy: logic correctness was verified through structured code review, compilation output analysis, and conceptual walkthrough of each code path rather than live forcing. This approach — design-by-review rather than design-by-debugging — is actually representative of how safety-critical code is validated in regulated environments where live simulation may not be available.

4. Multi-Instance Type Resolution

Declaring a Static variable as type "FB_Motor" inside FB_LineControl requires that FB_Motor is already compiled and its interface is consistent. During development, an out-of-order compile sequence caused TIA Portal to report an unresolved type reference on the Static variable declaration. The resolution was straightforward — compile FB_Motor first, then FB_LineControl — but this dependency order is worth documenting: in larger projects with deeper FB nesting, a dependency graph of block compilation order is a useful project management artefact.

Skills Demonstrated

Tools & Technologies