StateTick
Run the machine before the machine exists.
TwinTick Studio is StateTick’s own digital twin application — a real 3D physics environment, built in and shipped as part of the StateTick ecosystem, not a bridge out to someone else’s visualisation tool.
It exists to answer one question early: does the control logic actually run this machine? A digital twin here is not a visualisation exercise — it is a test rig your real controller drives.
Four steps to a twin, and one tick to put your real controller behind it.
Start with the CAD you already have
The mechanical model exists long before the machine does — and it already contains everything the product will touch.
Drop an FBX or a glTF/GLB into TwinTick Studio and it becomes a scene you can orbit. The parts arrive as they were modelled, so you are not rebuilding the machine — you are marking up the one mechanical already drew.
Working part by part, you say which pieces move and which are structure. The ones that matter are the ones the product meets — the conveyor it rides, the gate that stops it, the jaws that hold it, the tool that works on it. Everything else is scenery, and leaving it as scenery is what keeps the twin fast.
That focus is the whole design. What this twin models is product moving through the machine: where a part is, what it touches, what stops it, what lets it through. It is the flow of the line and the mechanical parts that act on it — which is exactly the layer the control logic lives in, and exactly where sequence errors show up.
Give the parts behaviour, not code
A motion is a type you pick and configure, not a script you write.
Each moving part gets a motion from a library covering the things machines actually do — and the library keeps growing. That is the step people expect to be hard, and it is a dropdown and a few fields.
And sensors, so the machine can see
A twin that only moves is a cartoon. Presence and distance sensors are placed the same way as motions, and they publish real readings from the physics scene — so the controller waiting for a part to arrive is waiting on a part that actually arrived.
Underneath it is a real physics engine, not an animation timeline. A part that is late is late because something blocked it, which is exactly the class of problem you want the twin to find.
Assemble the line and let product run through it
One saved model is a station. A factory is several of them plus something to process.
Each finished twin saves as its own model. In Factory Builder you place those models into a line — infeed, station, station, reject — the same way you would lay out the real cell.
Then you add spawners, which are the product. A spawner drops parts at a period you set, and from that moment the line behaves like a line: parts ride the conveyor, arrive at the station, block a sensor, get worked on, and move on. Nobody scripts that interaction — it falls out of the physics, which is the point. Product flow is what you are actually validating.
The interesting failures are never in one station. They are in the handover — two parts arriving at once, a gate closing on a part that was still moving, an interlock that only trips when the line is full. A twin with real product in it produces those on its own.
Now put the real controller behind it
The step that makes it validation rather than animation.
Everything so far is a mechanical model that moves. What turns it into a test rig is that the twin is just another bus.
In StateTick's Bus Manager, beside EtherCAT and Modbus and OPC UA, there is a column for the twin. Tick the variables the twin needs, set the direction, deploy. On the TwinTick side each motion input and each sensor output is either a local constant or bound to a StateTick path — you pick which from a list of the live variables.
That is the whole integration. The FSM you are going to ship, unmodified, is now driving a 3D machine: its outputs move the parts, and the sensors in the scene feed its conditions.
What you find, and when
The commercial case, plainly.
Sequence errors are cheap in a twin and expensive on a machine. The gate that closes early, the station that starts before the part is settled, the recovery path nobody tried — those cost minutes to find against a 3D model and cost a shift to find on site, with a customer watching.
The order of work changes too. Normally control software waits for the machine, so all the debugging lands in the last week of the build, on site, under pressure. With a twin, the sequence is already proven when the hardware arrives — commissioning becomes checking the wiring rather than discovering the logic.
And because the twin is a transport rather than a mode, you can point the plan back at hardware and forward at the twin as often as you like. A fault reported from the field can be reproduced against the model rather than against production.
TwinTick is not a standalone simulator. It is part of the StateTick ecosystem, and the thing it connects to is a StateTick controller — not a PLC, not a fieldbus, not a SCADA system. It has no drivers and no tag database of its own.
That is the design. StateTick is what binds to the outside world, and the twin is one more destination on the far side of it — which is exactly why swapping the twin for the plant is a change of routing rather than a change of machine. Touch Studio sits in the same relationship.
The controller you validate is the controller you ship.
That is the part that makes this worth doing. There is no model of the logic, no simplified simulation of the sequence, no second controller written for the test bench that then has to be kept in step with the real one.
The same machine, the same conditions, the same timers — running against a 3D line instead of a physical one, because the mapping table says so.
What is StateTick — how the four parts fit together.
The Test Manager — automated tests that can assert against the twin as well as the machine.