TwinCAT 3 Structured Text Software Architecture: From Machine States to Reusable Function Blocks

Start with behaviour, not with I/O

Define operating modes, machine states, permitted transitions, process sequences and fault responses before declaring hundreds of field variables. A useful software design description identifies the commands a module accepts, the states it reports, the interlocks it obeys and the evidence required to declare an operation complete.

Physical I/O should enter the application through typed structures or device adapters. The machine logic then works with names such as ClampClosed, AxisReady and PressureValid rather than terminal addresses. This reduces coupling to a particular I/O layout and makes simulation practical.

Layer the PLC application

1. Hardware and fieldbus layer: maps EtherCAT PDOs, drive status and instrumentation into validated device structures.
2. Device layer: owns one actuator, instrument, axis or intelligent device and exposes commands, state and diagnostic information.
3. Module layer: coordinates related devices into a station or process function.
4. Machine layer: applies modes, production sequences, interlocks and recovery policy across modules.
5. Interface layer: provides deliberate HMI, ADS, OPC UA, recipe and production-data contracts.

A layer may depend on the contract beneath it, but it should not reach through several layers to manipulate an unrelated output. That rule prevents hidden behaviour and makes offline tests far easier to construct.

Use function blocks as owned components

A reusable function block should own its internal state and timing, accept a small command structure, and return a status structure with state, readiness, activity, completion and fault information. Edge handling, timeouts and command acknowledgement belong inside the block that owns the behaviour.

Avoid a single global namespace containing every command and status flag. Prefer DUTs, enumerations and clear input/output structures. Use methods and properties where they make ownership clearer, while keeping the online view understandable for commissioning engineers.

Make state and recovery explicit

Represent modes and states with enumerations rather than loosely related Boolean flags. Each transition should state its guard conditions, actions, completion condition, timeout and response to a stop or fault. A reset must not simply clear an alarm bit: it should prove that the unsafe or invalid condition has disappeared and return the module to a defined recovery state.

Separate normal stopping, controlled abort, emergency or safety response, and restart. Safety functions remain in their validated safety system; standard PLC code may consume safety status but must not obscure the safety design boundary.

Definition of done

• Source, library versions, target versions and build method are controlled.
• I/O and external interfaces are documented and traceable.
• All automatic transitions have an observable reason, timeout and fault response.
• Simulation or test doubles can exercise critical modules without production hardware.
• Alarm text identifies the affected object, condition and useful operator action.
• Online change policy, download procedure and recovery package are agreed before handover.