A controller does one stubborn thing, forever: read its inputs → solve its task → write its outputs, a thousand times a second. The clever bit about TwinCAT is that this runtime isn't trapped in the steel cabinet — it also lives on your laptop. Activate onto the local target and the very same boot project runs with the EtherCAT bus simulated and nothing physical attached. Below isn't a diagram. It's a real glazing line you can run, wind to 20×, and break on purpose.
Here is the whole point of simulation in one picture. The same running task drives three windows in lockstep: the machine moving, the I/O signals flickering TRUE/FALSE, and the Structured Text deciding what to do next. Hit play and watch a donut roll in, the photo-eye catch it, the nozzle glaze it, and the line index on. Nothing here is wired to anything real — it's the TwinCAT runtime cycling a 1 ms task on your PC.
👀 Watch the link: when bDonutAtStation flips TRUE, line L2 lights, bGlazeValve goes green, and only then does glaze pour. Machine, signals, and Structured Text are never out of step — because they are all the same task. That is what "running in simulation" actually feels like. Hit ⏭ Step to advance one slice at a time, exactly like single-cycle mode in the online view.
This is the TwinCAT-specific magic, and it trips up newcomers from other brands. There is no separate "simulator program." The runtime (XAR) already sits on your engineering PC next to the IDE (XAE). When you press Activate Configuration and the controller drops into Run Mode, you simply chose a target. Point it at the real CX, or point it at 127.0.0.1.1.1 — your own machine. Flip the switch and see what actually changes.
🟩 Run Mode, no hardware. The local runtime executes the real task. EtherCAT is simulated — virtual terminals, virtual bus timing — and inputs come from Free Run (you toggle them) or a machine model (it toggles them for you).
🔌 What never moves. Your code, the task, ADS port 851, the HMI and the Scope all connect to the local runtime exactly as they would to steel — they genuinely cannot tell. That's why a green simulation builds real confidence.
Go back up and hit ⚡ Jam the valve. Watch it: bGlazeComplete goes TRUE, line L3 tries to shut the valve — but it's stuck open. The donut drowns, the glaze counter climbs, the line faults out. Now picture that on the real floor: pink syrup over a machine, a stopped line, a very sticky afternoon and a maintenance callout. Here it is a number you reset with a button.
Engineers don't say "running without hardware" — they say where the real bits sit. It's a ladder called X-in-the-loop: as you climb it, more of the setup becomes real and the test gets more trustworthy. Tap each rung.
The thread through all three: a model of the machine feeding inputs back to the controller automatically. Plain simulation needs you to fake those inputs by hand (Free Run); a twin generates them itself — over ADS or OPC UA, from Simulink or a 3D game-engine model. That feedback loop is the whole difference.
1 · You have no controller on your desk, only the TwinCAT IDE on your laptop. How do you run and test the actual task today?
2 · Your virtual line glazed a donut, the photo-eye tripped on its own, and the valve opened — all with no clicking from you. Which setup were you running?