StateTick
A machine that always works proves nothing.
A twin that runs perfectly every time only ever tests the happy path. The sequence that matters is the one that runs when a gripper drops the part, a belt slips, or an encoder keeps counting after the motor has stopped.
TwinTick can make the machine misbehave on demand — seize, slip, drift, over-travel, or report something other than what is happening. Your controller drives it exactly as before, and you find out whether it notices.
The rule every fault follows
A fault is only worth having if the controller can detect it through the I/O it already reads.
This is the line between a demo and a test rig, and every fault in TwinTick is built to stay on the right side of it.
If the twin raised a flag saying “I am broken”, nothing would have been tested — the logic would just be reading a flag that does not exist on a real machine. So it does not do that. The twin quietly stops turning while the encoder keeps counting, and your sequence has to work that out on its own, from the same signals it will have on site.
Everything below is detected the way a real controller detects it: a position that stops changing, an interlock that never makes, a count that drifts, a discrepancy timer that expires because commanded and actual stopped agreeing.
Nothing announces itself. A faulted part looks exactly like a healthy one in the viewport and on the bus. That is the point — the only thing that can tell you something is wrong is your own logic.
Three classes, and why the middle one matters most
Each fault is classified by what it attacks.
The lying faults are the ones that earn their keep. Every alarm your sequence relies on is telling the truth right up until it is not, and a controller cannot catch that by reading a flag — it has to catch it by cross-checking one signal against another, or against time.
The degraded ones are the most realistic. Belts slip, gearboxes wear, air pressure sags, lenses get dirty. None of it trips anything, and the line just quietly stops making rate.
Rotary motion
Index tables, star wheels, spindles.
| Fault | Class | What the machine does | What the controller sees | Setting |
|---|---|---|---|---|
| Seize | physical | Stops turning while still commanded to run. | Angle frozen, in-position never arrives. A timeout should catch it. | On / off |
| Fails to start | physical | Ignores the first run command; needs re-commanding. A contactor drop-out. | Nothing moves and nothing alarms. Tests whether the sequence checks that it actually started. | On / off |
| Coast after stop | physical | Keeps turning a few degrees after the run command drops. A failed brake. | Overshoots the index station — pockets stop short of the transfer. | Degrees |
| Backlash | degraded | Loses a little motion every time direction reverses. A worn gearbox. | Position error accumulates on any shuttling move, and nothing alarms. | Degrees |
| Speed droop | degraded | Turns at a fraction of commanded speed. | Index takes longer; downstream timing slips out from under the recipe. | Percent of commanded |
| Overshoot and hunt | degraded | Passes the target, then oscillates around it. | The in-position signal chatters. Tests debounce on the interlock. | Degrees |
| Encoder freeze | lying | Keeps turning normally. The published angle stops. | Looks exactly like a stall that is not one. Does the recovery routine make it worse? | On / off |
| Encoder drift | lying | Turns correctly; the reported angle drifts a little every revolution. | Everything reads fine while the pockets progressively miss the transfer. | Degrees per revolution |
| False in-position | lying | Turns normally. In-position asserts before it arrives. | Downstream releases product into a pocket that is not there yet. | On / off |
Linear motion
Sliding lifts, transfers, pushers.
| Fault | Class | What the machine does | What the controller sees | Setting |
|---|---|---|---|---|
| Jam | physical | Stops dead mid-travel and stays there. | Position frozen short of target. The discrepancy timer should trip. | On / off |
| Short stroke | physical | Stops a few millimetres before the commanded end, every time. | In-position never sets, and product is handed off slightly out of place. | Millimetres |
| Stiction | degraded | Sits still for a moment before breaking free and moving. | Late arrival. Attacks anything that assumes motion starts on command. | Milliseconds |
| Gravity creep | degraded | Drifts back toward the low end while idle. A leaking valve on a vertical axis. | Position wanders with no command. Does the hold logic notice? | mm per second |
| Slow travel | degraded | Moves at a fraction of commanded speed. | Cycle time stretches; downstream starves. | Percent of commanded |
| Position offset | lying | Moves correctly; reports a constant offset from where it really is. | Every commanded position lands wrong by the same amount, silently. | Millimetres |
| Alarm suppressed | lying | Travels past a soft limit; the alarm never publishes. | The safety reading the sequence depends on simply is not there. | On / off |
Conveyors and transfers
Belts and driven surfaces.
| Fault | Class | What the machine does | What the controller sees | Setting |
|---|---|---|---|---|
| Belt slip | degraded | Product moves slower than the belt surface. The conveyor failure. | Everything reads healthy. Destroys any logic that infers position from speed × time. | Percent slip |
| Motor stall | physical | Belt stops while commanded to run. | Product stops arriving. Does the downstream sensor time out cleanly? | On / off |
| Runaway | physical | Ignores the stop command and keeps running. | Tests whether the stop path is real or decorative. | On / off |
| Ramp failure | degraded | Accelerates but never reaches commanded speed. | At-speed never sets — or sets wrongly, if paired with the next one. | Percent of commanded |
| False at-speed | lying | Stalled or slipping; reports at-speed anyway. | The interlock that gates product release is lying. | On / off |
Pneumatics
Cylinders, pushers, stops.
| Fault | Class | What the machine does | What the controller sees | Setting |
|---|---|---|---|---|
| Valve stuck | physical | Freezes in place regardless of command. | Neither end switch makes. The discrepancy timer trips. | On / off |
| Low air | degraded | Extends and retracts far more slowly than rated. | Cycle stretches; end switches arrive late. | Percent of commanded |
| Short stroke | physical | Stops before the end of travel. | The end switch never sets, although the rod clearly moved. | Millimetres |
| Seal leak | degraded | Creeps back from the held end while still commanded. | End switch makes, then drops out with no command change. | mm per second |
| Reed switch stuck | lying | Rod moves normally; the end switch is welded on, or dead. | Reports extended with the rod home. Extremely common in the field. | Which end |
Clamps and grippers
The richest of the set — the most signals to lie about.
| Fault | Class | What the machine does | What the controller sees | Setting |
|---|---|---|---|---|
| Obstructed | physical | Stops a few degrees short of closed — something is in the way. | Closed never sets. The honest, easy case. | Degrees |
| Will not open | physical | Stays shut on the open command. | Product never released; the next station starves. | On / off |
| One jaw stuck | physical | Only one jaw moves, so the grip closes off-centre. | Jaws-touching never sets although the clamp reports closed. | Which jaw |
| Slip | degraded | Grips, then loses the product while still commanded shut. | Gripping drops with no command change. Does the transfer notice mid-move? | Milliseconds |
| Slow actuation | degraded | Opens and closes at a fraction of rated speed. | Grip completes after the robot has already started moving. | Percent of commanded |
| Limit switch lies | lying | Jaws open; the closed signal reports true. | The interlock that authorises the move is wrong. Product dropped in transit. | On / off |
| Phantom grip | lying | Holding nothing; gripping and product-present both report true. | The line believes it is carrying a part that fell out three stations ago. | On / off |
Sensors
Presence and distance — a small surface with a high return.
| Fault | Class | What the machine does | What the controller sees | Setting |
|---|---|---|---|---|
| Dead | physical | Never detects anything. | Product passes uncounted. A starvation timeout is the only defence. | On / off |
| Stuck on | lying | Reports permanent detection with nothing in the beam. | Blocked-lane logic fires forever, or the line refuses to index. | On / off |
| Dropout | degraded | Randomly misses a fraction of detections. A dirty lens. | Counts drift low over a shift. Only statistics reveal it. | Percent missed |
| Ghost trigger | lying | Fires occasionally with nothing present. | Counts drift high. Tests any logic that trusts a single edge. | Events per minute |
| Reading offset | lying | Distance is consistently wrong by a fixed amount. | Measurement-based decisions are all wrong, confidently. | Millimetres |
| Noise | degraded | Distance jitters around the true value. | Threshold comparisons chatter. Tests filtering. | ± millimetres |
Process equipment
Vessels and cutting tools — where being wrong gets expensive.
Tanks and vessels
| Fault | Class | What the machine does | What the controller sees | Setting |
|---|---|---|---|---|
| Valve stuck | physical | Inlet or outlet valve ignores the command. | Neither end position makes; the discrepancy timer trips. | On / off |
| Leak | degraded | Level falls with both valves shut. | Mass balance stops adding up. Tests any inventory logic. | Units per second |
| Blocked outlet | physical | Outlet valve opens; nothing drains. | Valve says open, level says full. Two honest signals, one bad conclusion. | On / off |
| Level sensor stuck | lying | Vessel fills and empties; the reading holds. | Overfills past high-high with no alarm, because the alarm reads the same sensor. | On / off |
| Level drift | lying | Reading slowly diverges from the true level. | Set points quietly move. The classic slow-poison instrument fault. | Units per minute |
Saws and cutting tools
| Fault | Class | What the machine does | What the controller sees | Setting |
|---|---|---|---|---|
| Will not spin | physical | Run commanded, blade static, nothing cuts. | Cut count stops advancing while product keeps feeding. | On / off |
| Slew jam | physical | A blade will not move to its commanded gap. | Blade position parks short. Every subsequent cut is the wrong width. | Which blade |
| Blade break | physical | One blade stops cutting mid-run; the rest continue. | Piece count drops by one. Does the recipe check what it got back? | Which blade |
| Position lies | lying | Blade sits at a different gap than reported; published dimensions still claim nominal. | Nothing at all. Every piece is out of spec and the data says it is fine. | Millimetres |
That last one is the whole argument. No alarm, no timeout, no operator notices — and every part made that shift is scrap. It is the kind of failure a twin can hand you on a Tuesday afternoon instead of a customer handing it to you a month after handover.
How faults are set up
Opt-in, per instance, and repeatable.
Off unless you ask
- Faults are a section you enable, not a mode you enter
- A model with no faults configured behaves exactly as it did before
- Nothing is baked in — a clean model ships clean
Per placement, not per model
- The same machine placed twice can have one healthy and one faulty
- Faults belong to the instance in the line, alongside its other overrides
- Useful for “lane 2 is the bad one” scenarios
Driven from your logic, or by hand
- Each fault is a bindable input — a toggle, a percentage, or a magnitude in the device's own unit
- Trigger it from a panel, from a test case, or from the sequence itself
- A fault state is published, so a test can assert on it
Repeatable when it needs to be
- Random faults — dropout, ghost triggers, slip — take a seed per motion
- A run that failed can be replayed exactly
- Everything else is deterministic by construction
Because a fault is an input like any other, it composes with everything else you already have. A test case in Test Manager can enable a belt slip, run the sequence, and assert that the machine reached a safe state rather than carrying on regardless — which turns “we should test the failure paths” into a test that runs on every change.
What this is for
The failure paths are the ones nobody gets to rehearse.
Every machine ships with recovery logic that has never run. The jam handler, the re-home routine, the branch that fires when a sensor disagrees with a position — written from imagination, reviewed on paper, and first executed in front of a customer.
Fault injection is how that code gets exercised before anyone is watching. Not by simulating the fault in the logic, which only tests the simulation, but by making the machine genuinely misbehave underneath a controller that has no idea anything is different.
The controller you break is the controller you ship.
Same sequence, same timers, same conditions. The only thing that changed is that the machine stopped cooperating — which, on the day, is exactly what happens.
TwinTick — Digital Twin — building the twin the faults run on.
The Test Manager — turning a fault scenario into a test that runs on every change.
Monitoring & Logs — watching what the logic did while the machine lied to it.