What the clock actually guarantees.

Every machine you describe in StateTick runs on its own execution thread with its own period, set where the machine is defined. A safety interlock can sit at a few milliseconds while a recipe sequencer above it runs an order of magnitude slower, on the same controller.

The practical consequence is isolation. Adding a slow machine to a project does not lengthen the scan of a fast one, because they were never sharing a scan. The usual pressure — where every addition to the program taxes the tightest loop in it — does not arise, because there is no single program.

It also means the number you choose is a decision you can defend. A machine that reads a flow meter does not need to be visited every two milliseconds, and one watching a light curtain should not be visited every fifty.

The obvious way to hold a period is to do the work, measure how long it took, and sleep for the remainder. It is also the way that drifts: every scan carries a little measurement overhead and a little wake-up inaccuracy, and because each sleep is calculated from now, those errors compound. An hour later the loop is running visibly late and nothing reported it.

StateTick advances a fixed deadline instead. Each cycle adds exactly one period to the target timestamp and sleeps until that absolute moment, so a scan that runs slightly long is absorbed by the next sleep rather than pushed into the next cycle. Error does not accumulate.

The second half of that figure is the part worth dwelling on. If a scan falls behind by more than one whole period — the operating system scheduled something else, a disk stalled, a burst of work arrived at once — StateTick does not try to make up the lost cycles. It resets the deadline to the present and carries on at the normal rate.

That is a deliberate choice. Firing several cycles back to back to “catch up” would mean a machine briefly running its logic far faster than it was designed to, which is worse than the lateness it is correcting.

Every machine records its own timing while it runs, in microseconds, on the controller. Not sampled in a lab once — continuously, on the machine you deployed, available live and in the logs.

That last column is the difference between knowing a scan is slow and knowing why. When a machine starts running long, the profile says whether the cost is in evaluating conditions, in the actions a state performs, or in a collection pause — and those have completely different fixes.

Because the numbers are recorded rather than estimated, they also travel. A timing question from a commissioned machine is answered with that machine’s own figures rather than with a benchmark from somewhere else.

If a machine throws an unhandled error, StateTick stops every machine in the project, not just the one that failed. That is the deliberate choice: half a line running with the other half stopped is a more dangerous state than a full stop, because the remaining machines carry on acting on a plant that is no longer whole.

Three things happen at that moment. The fault is recorded with the machine name, message and stack trace. It is written into the FSM trace log alongside the state history, so the sequence leading up to it is there rather than lost. And a crash file is written to disk, so the evidence survives a restart.

The stop is treated as transient rather than as an operator decision. StateTick installs as a service — a systemd unit on Linux — and comes up with the machine, so a restarted controller resumes normally rather than waiting for someone to notice it is down. A stop somebody deliberately commanded is remembered; a fault stop is not.

Safety

StateTick integrates directly with external safety modules and safety relays. It sees the guard circuit, knows the moment the safety chain drops, and sequences the machine around it — bringing the process to a controlled state, holding, and resuming cleanly when the chain is restored.

This is the architecture most machines are already built around, and StateTick slots straight into it. Your safety hardware does what it is there to do; StateTick runs the machine and responds to it.

Motion

StateTick speaks the protocols your drives and motion controllers use, and coordinates them: when each axis is commanded, what has to be true first, how moves interlock with the rest of the machine, and what happens if one does not arrive. The drives execute the profiles; StateTick choreographs them against everything else on the line.

Because the coordination is a state plan rather than buried code, the motion sequence is something the whole project team can read and review.

Fieldbus and I/O

EtherCAT is used primarily for digital and analog I/O, and has been validated against standard bus couplers and I/O modules. Modbus TCP and RTU, OPC UA as both server and client, serial and raw TCP cover the rest, with the mapping held separately from the logic so the same machine can be pointed at different hardware without touching its sequence.

StateTick runs production machines at three sites today, in packaging and palletising — lines where product moves through several stations, the timing between them matters, and a stoppage is counted in cases that did not get made.

Those machines are why this page reads the way it does. The deadline scheduler, the per-phase timing instrumentation and the decision to stop a whole line on a fault are not design-office preferences; each one is there because a running line demanded it. That is a shorter feedback loop between a machine and the software that drives it than most platforms will ever have again.