The line is down. Nobody saw it happen.

Three in the morning, and the night shift is telling you a machine stopped about twenty minutes ago. It has not faulted. It is just sitting there.

The question is never really “what went wrong.” It is where is it stuck, and why did it not do the next thing. StateTick is built to answer both without a guess.

How the night goes

01 Where it is stuck Open the plan. The state it is sitting in is lit up. That took four seconds. 02 What could move it on Select the state and get exactly the signals that state and its transitions interact with. 03 Why it did not The log has every condition it checked and what each one came back as.

Where it is stuck

The first question, and usually the longest one to answer.

You connect from home. The plan opens — the same drawing the whole project has been looking at since week one.

The capper is lit on WaitForBottle. The filler beside it is lit on Settle and has been for twenty minutes. Nobody had to describe anything over the phone.

Every machine's active state glows on the plan while the plant runs. Because machines sit side by side rather than nested inside one another, you see all of them at once — which one moved on, which one did not, and which one everything else is waiting for.

That is often the whole diagnosis. A machine parked in a state it should have left is a fact, not a theory, and you have it before you have finished sitting down.

Why this is the hard part elsewhere

Without a live drawing, “where is it” is reconstructed from a status word, a step number, or someone reading lamp colours down the phone — and each of those is a translation that can be wrong.

Focused observability

Select the state you are stuck in. Get exactly the signals that matter to it — and nothing else.

A plant has thousands of signals. At three in the morning, roughly six of them matter, and knowing which six is the actual skill. StateTick already knows, because the state and its transitions say so.

Click the state the machine is sitting in and the monitor fills with the signals that state and its transitions interact with: the equipment variables its actions drive, the timers it started, the globals its conditions read, and the machine's own state track. Nothing else. You are not building a watch list at three in the morning; you are being handed one.

EquipmentEvery device variable the state and its transitions interact with.

TimersWhatever it started, and whether it is still running.

GlobalsThe plant-wide flags its conditions depend on.

Its own stateThe state track itself, on the same time axis as the rest.

The machine's state is drawn as a band on the same time axis as its signals. When the band stops changing, the reason is usually in the rows underneath it — here, a valve feedback that never returned.

Booleans draw as square waves, numbers as traces, and states and enumerations as labelled bands. Drag the cursor to any moment and every signal reports what it was at that instant. You can record a session and load it back later, so a fault that happened while nobody was watching is still there in the morning.

And if you want to test the theory rather than think about it — force the valve feedback from the chart itself and watch whether the machine moves on.

Why it did not move on

Not what the machine did. What it checked, and what the answer was.

The waveform tells you what the world looked like. The log tells you what the machine made of it. Every action, every transition and every condition the machine evaluated is written down with a microsecond timestamp — including the conditions that came back false, which are the ones that matter when nothing is happening.

FSM LOG · Filler · 03:07:28 – 03:07:31

03:07:28.114302  TRANSITION  Filler   Drain → Settle
    03:07:28.114488  ACTION      Filler   Settle     VentValve.Cmd.Open = True
    03:07:28.114690  ACTION      Filler   Settle     Timer.Start('SettleTime')
    03:07:29.116043  CONDITION   Filler   Settle → Idle       SettleTime.Done = FALSE
    03:07:31.020117  SET         Filler             SettleTime.Done = True
    03:07:31.021884  CONDITION   Filler   Settle → Idle       SettleTime.Done AND VentValve.Fb.Closed = FALSE
    03:07:31.026551  CONDITION   Filler   Settle → Idle       SettleTime.Done AND VentValve.Fb.Closed = FALSE
    03:07:31.031204  CONDITION   Filler   Settle → Idle       SettleTime.Done AND VentValve.Fb.Closed = FALSE

The timer finished. The condition still says no. Only one term is left, and it is named right there in the line.

This is the difference between knowing the machine is stuck and knowing why. The condition is logged as it was written, with the answer it produced, so you are reading the machine's own reasoning rather than reconstructing it. Two lines and the night is over: the vent valve is reporting open, the machine is correctly refusing to move on, and someone needs to look at a limit switch rather than at your code.

Logs are written continuously to session files on the machine, so the twenty minutes before the phone call are already recorded. Nobody had to have anticipated this fault and turned something on.

The part that saves the argument

“The machine did not do what it was told” and “the machine did exactly what it was told, and here is the condition that stopped it” are the same night with very different endings. The log settles it in writing.

The diagnostic toolset, plainly

The same capabilities as above, named rather than narrated.

Live machine diagnostics

Live state monitoring — the active state in every machine, lit on the plan you designed from.
Waveform signal monitoring — selected variables captured over time and read as traces, not sampled by eye.
Condition inspection — each term of a guard shown with its own value, so a false transition names the term that blocked it.
Queue and timer inspection — depth, contents and elapsed time, live.

Recorded evidence

FSM trace logging — every state entry, exit and transition with a microsecond timestamp.
Timing profiling — scan time and jitter per machine, plus per-phase cost inside the cycle.
Fault capture — the failing machine, message and stack trace, written to disk so it survives a restart.
Root-cause troubleshooting after the event — the record answers what happened overnight without reproducing it.

Two things are worth stressing. None of it is a debug mode that has to be switched on beforehand — it is how the runtime always behaves, so unplanned downtime is diagnosable after the fact rather than only if somebody was watching. And the timing figures come from the machine itself, which is why determinism and timing can be discussed with numbers rather than adjectives.

Four seconds, four minutes, and no guessing

The same three questions, every time.

None of this is a debug mode you remembered to switch on.

The live plan, the focused signal list and the log are how the machine runs, not a special build of it. You do not reproduce the fault, you do not add instrumentation and wait for it to happen again, and you do not need the person who wrote it to be awake.

Where it is stuck comes from the drawing. What could move it on comes from the state itself. Why it did not comes from the log. Three questions, three answers, and the only judgement call left is the one that actually needs an engineer.

Also worth reading

The Machine, Drawn — the plan that lights up: reusable states, fault and pause paths as standard, and why machines sit side by side rather than nested.

The Plant, Described — the shape underneath: each machine on its own clock, and the logic, equipment model and bus mapping kept as three separate worlds.