Beckhoff TwinCAT 3 Tutorial: Build Your First PLC Project

Q: Can I learn TwinCAT 3 without Beckhoff hardware?

Yes. Beckhoff documents selecting ` ` as the target for its first-project tutorial. Treat that as a learning and logic-test environment, not a validated production controller.

TwinCAT 3 turns a compatible PC-based target into a real-time controller and uses TwinCAT Engineering (XAE) to build the project. For a first program, create a standard PLC project, write and build Structured Text, select the local target, activate the configuration, log in and start the PLC. Keep simulated I/O separate from hardware mapping so the same logic can be tested safely.

This tutorial follows Beckhoff’s documented workflow and adds a small, testable machine-state example. It does not assume that a development laptop is suitable as a production controller.

Current-version note (reviewed July 25, 2026): Beckhoff’s current installation manual covers TwinCAT 3.1 Build 4026. Existing projects may use 4024 or earlier builds. Record the exact XAE build, compiler and library versions; do not upgrade a production project merely because a newer build exists.

TwinCAT 3 components in plain language

Component	Role	Licensing summary
TwinCAT 3 Engineering (XAE)	Create, compile, configure and diagnose projects	Beckhoff states that the PLC-programming core is free of license cost
TwinCAT 3 Runtime (XAR)	Execute real-time control on the target	Permanent runtime functions are licensed
TwinCAT PLC project	IEC 61131-3 POUs, data types, libraries and task references	Built inside the TwinCAT solution
TwinCAT system configuration	Tasks, I/O devices, mappings and target configuration	Activated on the selected target
TwinCAT functions	Motion, HMI, OPC UA and other optional capabilities	License depends on the selected function

Beckhoff’s licensing manual says XAE and runtime components can be downloaded, the PLC-programming core of Engineering is free, and many runtime functions can use a renewable seven-day trial license. A trial is for evaluation and lab work—not unattended production.

What you need

a supported 64-bit Windows engineering computer;
TwinCAT 3.1 XAE installed from Beckhoff;
local administrator access for installation and real-time components;
a clean project folder under version control;
a written I/O contract, even when the first inputs are simulated; and
a known target: <Local> for this learning exercise or an approved remote Beckhoff target.

Office PCs are only conditionally suitable for hard real-time control. Beckhoff explicitly warns about jitter and platform suitability in its licensing documentation. Use qualified hardware, the relevant Beckhoff compatibility guidance and an application-specific timing test for production.

Step 1: Create a standard PLC project

Beckhoff’s official first TwinCAT 3 PLC project uses this sequence:

Open TwinCAT XAE and create a new TwinCAT project.
Select the PLC node and choose Add New Item.
Select Standard PLC Project.
Name the PLC project and add it.
Open MAIN (PRG) under POUs.

The template creates a MAIN program and a referenced PLC task. Structured Text is a practical language for the state-machine example below, but TwinCAT supports the IEC programming editors provided by the installed toolchain.

Editorial Structured Text learning bench with an engineering workstation, simulated start and stop inputs, controller state values and a written test matrix. — This editorial lab scene is not a TwinCAT screenshot. The exact XAE commands are listed in the crawlable steps above.

Step 2: Create a small, testable state machine

Add a DUT named E_MachineState:

TYPE E_MachineState :
(
    Stopped,
    Starting,
    Running,
    Faulted
);
END_TYPE

Replace the declarations in MAIN with:

PROGRAM MAIN
VAR
    // Simulated input contract
    xStartPB       : BOOL;
    xStopPB        : BOOL;
    xGuardClosed   : BOOL := TRUE;
    xDriveReady    : BOOL := TRUE;
    xDriveFault    : BOOL;
    xResetPB       : BOOL;

    // Command and diagnostic outputs
    xRunRequest    : BOOL;
    xReady         : BOOL;
    eState         : E_MachineState := E_MachineState.Stopped;
    tonStartProof  : TON;
END_VAR

Then add the implementation:

xReady := xGuardClosed AND xDriveReady AND NOT xDriveFault;

// Start proof is intentionally visible and testable.
tonStartProof(
    IN := eState = E_MachineState.Starting AND xReady,
    PT := T#500MS
);

// Stop and fault are dominant over a start request.
IF xStopPB OR NOT xGuardClosed OR xDriveFault THEN
    xRunRequest := FALSE;

    IF xDriveFault THEN
        eState := E_MachineState.Faulted;
    ELSE
        eState := E_MachineState.Stopped;
    END_IF
ELSE
    CASE eState OF
        E_MachineState.Stopped:
            xRunRequest := FALSE;
            IF xStartPB AND xReady THEN
                eState := E_MachineState.Starting;
            END_IF

        E_MachineState.Starting:
            xRunRequest := TRUE;
            IF tonStartProof.Q THEN
                eState := E_MachineState.Running;
            END_IF

        E_MachineState.Running:
            xRunRequest := TRUE;

        E_MachineState.Faulted:
            xRunRequest := FALSE;
            IF xResetPB AND NOT xDriveFault THEN
                eState := E_MachineState.Stopped;
            END_IF
    END_CASE
END_IF

This code produces a run request, not a safety-rated motor output. A real machine needs a risk assessment, approved safety design, feedback proof, drive interface and application-specific fault handling.

Structured Text state-machine diagram showing stopped, starting, running and faulted states with stop-dominant and reset transitions. — Explicit states make online diagnosis and boundary testing clearer than a collection of loosely coupled bits.

Step 3: Build and check the project

TwinCAT provides more than one useful check:

Build/Rebuild compiles the objects used by the project.
Check all objects checks all function blocks under the PLC node, including objects not currently called.
The Error List links diagnostics back to the affected object.

For a controlled release, capture:

XAE build;
selected compiler version;
library names and versions;
target platform;
build output;
boot-project status; and
source-control revision.

Do not ignore warnings until they have been classified. A warning caused by an intentionally unused simulation variable is different from a conversion or library warning that changes runtime behavior.

Step 4: Select the local target and run

For this hardware-free exercise:

Select <Local> in Choose Target System.
Activate the configuration.
Allow TwinCAT to restart in Run mode if prompted.
Select Login from the PLC menu.
Create and load the application when prompted.
Select Start to run the PLC.
Watch eState, xReady, xRunRequest and the timer online.

The local runtime may prompt for a trial license. Follow Beckhoff’s TwinCAT 3 licensing instructions and do not treat a renewable trial as a production entitlement.

Step 5: Run the boundary tests

Test	Input sequence	Expected result
Normal start	Pulse `xStartPB` while ready	`Stopped → Starting → Running` after 500 ms
Stop dominance	Set `xStopPB` during Starting	Immediate `Stopped`; `xRunRequest = FALSE`
Guard loss	Set `xGuardClosed = FALSE` while Running	Immediate `Stopped`; restart blocked
Drive fault	Set `xDriveFault = TRUE`	`Faulted`; request off
Invalid reset	Pulse reset while fault remains	State remains `Faulted`
Valid reset	Clear fault, then pulse reset	`Faulted → Stopped`; no automatic restart
Readiness loss before start	Set `xDriveReady = FALSE`, pulse start	State remains `Stopped`
Power/restart review	Restart local runtime	State and outputs follow the documented initialization policy

Also measure task execution and jitter on the intended target. A simulation that passes functional states does not prove the production cycle time.

Step 6: Separate PLC logic from EtherCAT mapping

Keep logical variables such as xGuardClosed and xDriveReady independent of terminal addresses. In the system configuration, link them to the appropriate EtherCAT process data only after:

the physical I/O list is approved;
terminal identity and revision are recorded;
signal type, range and safe state are defined;
wiring and channel diagnostics are verified; and
the safety architecture is handled separately where required.

This separation lets you execute the same test cases with simulated variables before commissioning hardware.

Editorial EtherCAT frame path passing through a chain of I/O devices while each device reads output data and inserts input data. — EtherCAT process data and PLC variables meet at the mapping boundary; keep application meaning independent of terminal position.

Scan or configure manually?

Scanning can accelerate a lab setup, but it should not be the sole source of truth for a production machine. Compare the discovered topology with the approved bill of material and save evidence for:

device order and identity;
terminal type and revision;
expected working-counter behavior;
distributed-clock configuration;
process-data mapping; and
behavior when a device is removed or replaced.

EtherCAT timing and distributed clocks

Do not claim a cycle time simply because EtherCAT can support fast communication. The achievable application cycle depends on:

target CPU and real-time configuration;
PLC and motion task execution;
EtherCAT topology and process-data size;
terminal and drive capabilities;
distributed-clock configuration;
Windows/target workload; and
acceptable jitter and overrun margin.

Select the slowest cycle that meets the validated process requirement. Measure it under representative load and retain the trace with the acceptance evidence.

EtherCAT distributed-clock illustration aligning controller, remote I/O and servo-device time bases before synchronized sampling and actuation. — Distributed clocks improve synchronization only when the complete task, bus and device configuration is engineered and measured.

Industrial network timing evidence view comparing configured cycle, measured execution, bus latency, jitter and remaining deadline margin. — Publish measured timing with the target, build, load and topology; a protocol headline is not an application benchmark.

Commission an EtherCAT segment systematically

Confirm the approved topology and power groups.
Inspect shield, grounding and connector installation.
Verify device identities and expected process data.
Link one signal group at a time.
Check input and output direction before forcing anything.
Compare working counters and device states in normal operation.
Remove one non-safety device under controlled conditions and verify diagnosis.
Restore it and verify recovery without an unintended start.
Measure cycle time and jitter under representative application load.
Archive configuration, scan evidence and test results.

EtherCAT commissioning bench with controller, terminal chain, servo drive, diagnostic laptop and a topology verification checklist. — The commissioning sequence proves identity, mapping, diagnosis and recovery before optimizing speed.

Device proof record matching EtherCAT terminal identity, revision, process-data layout, mapped PLC variables and observed diagnostic states. — A saved scan is useful; a reconciled device-proof record is stronger evidence.

Project structure that scales

For a larger machine, separate responsibilities:

PLC
├── DUTs
│   ├── E_MachineState
│   └── ST_MachineStatus
├── GVLs
│   ├── GVL_Inputs
│   └── GVL_Outputs
├── POUs
│   ├── FB_Machine
│   ├── FB_Drive
│   ├── FB_Alarm
│   └── MAIN
└── Tests
    └── FB_MachineTests

Keep hardware mapping at the boundary, application behavior in function blocks and tests close to the behavior they prove. Pin library versions and review every library update as a source-code change.

Common TwinCAT problems

Cannot activate the local runtime

Check installation of the real-time components, Windows virtualization/security configuration, administrator rights and Beckhoff’s current installation guidance. Do not weaken endpoint security on a production machine without an approved OT security decision.

Project builds but will not run

Verify the selected target, runtime state, required licenses, active configuration, PLC login and boot-project state. Read the first causal diagnostic rather than clearing the whole message list.

EtherCAT devices remain in an unexpected state

Compare physical order, power, identity, process data and cabling with the configured topology. Use working-counter and device diagnostics to isolate the segment.

Online values do not match field signals

Prove the chain in this order: field state → terminal channel → EtherCAT process data → mapped PLC variable → application state. Do not start by changing the program.

Cycle-time overruns

Capture task execution, jitter, CPU allocation and load. Move non-deterministic work out of the fast task, reduce unnecessary polling and select a realistic task interval.

Practice before moving to TwinCAT hardware

PLC Simulation Software can be used to practice the state transitions and test matrix in this article. Disclosure: PLCProgramming.io and PLC Simulation Software have common ownership. The product is an independent training simulator; it is not TwinCAT, does not import TwinCAT projects, emulate EtherCAT or validate Beckhoff runtime timing. Recreate the logic in TwinCAT and rerun every test on the selected target.

Continue with:

Safety and production limitations

The example output is a software request, not a safety-rated actuator command.
Do not implement an emergency stop, guard function or safe motion function in standard tutorial logic.
A local engineering PC and trial runtime are not evidence of production suitability.
EtherCAT functional tests do not validate a TwinSAFE application.
Production release requires the applicable machinery risk assessment, electrical design, software lifecycle, validation and qualified approval.

Frequently asked questions

Is TwinCAT 3 free?

Beckhoff states that the core TwinCAT 3 Engineering PLC-programming environment is free of license cost. Runtime and optional functions are licensed, although many can use renewable seven-day trial licenses for evaluation.

Can I learn TwinCAT 3 without Beckhoff hardware?

Yes. Beckhoff documents selecting <Local> as the target for its first-project tutorial. Treat that as a learning and logic-test environment, not a validated production controller.

Which TwinCAT build should I install?

Use the build approved for the project and target. Beckhoff’s current installation documentation covers Build 4026, while many installed systems use earlier builds. Check compatibility before changing.

Should I scan EtherCAT devices automatically?

Scanning is useful during setup, but reconcile the discovered chain with the approved topology, identities and mappings. Preserve the evidence and test failure recovery.

What task cycle should I use?

There is no universal best value. Select it from the process requirement, then prove execution time, bus timing, jitter and margin on the intended target under representative load.