First, it is a controller.

StateTick is not a dashboard reading a PLC, and not an orchestrator sending setpoints down to something else that does the real work. It is the controller. It installs as a service on the box bolted to the machine, comes up with the power, and drives the I/O directly. Pull the network out and nothing happens, because nothing upstream was in the control path.

What is different is how the machine is described to it. Instead of a program that scans the whole plant, you describe the machines themselves — a filler, a capper, a rinse station — each drawn as the states it can be in and what has to be true to move between them, each running on its own terms and coordinating with its neighbours deliberately.

Two things follow from a machine being a drawing rather than a program. It can be read by people who are not automation engineers, which changes what happens in a design review. And it can be watched: connect to a running plant and the drawing lights up, the active state in every machine glowing while the line works. Diagnosing a stopped machine starts with looking at the picture you designed from, not with reconstructing it from a status word.

Faults and pauses are part of what a machine is here, too — stopping on a condition, holding, and resuming where it left off rather than at the beginning is behaviour the controller provides, not scaffolding you build around every sequence.

Alarms live in the controller

This is worth being clear about, because most systems put it the other way round. In StateTick a condition is a first-class object in the controller — built by picking the signals you mean and joining them, with a name, a group and a severity of its own. The condition that stops the machine is the alarm. It is defined once, in the controller, and it is the controller that decides an alarm has occurred.

Whatever shows it — an operator panel, a SCADA system, a log — is only displaying something the controller already determined. There is no separate alarm database to author, and no way for the alarm list and the logic to end up describing different things.

What you actually program in

The language is a visual, parallel state machine designer. Not one sequential program with parallelism bolted on, but many machines laid out side by side, each holding its own sequence and running alongside the others — which is how a line is actually built, so it is how the drawing looks.

Behind the drawing sits an extremely structured variable space. Nothing is a flat list of tags. Interfaces describe a kind of connection, equipment gathers the ones a device has, instances are the devices themselves — and a value can be a boolean, a number, a duration, a string, a fixed array, a keyed map or a record with named fields of mixed types. The structure is the plant itself, not a naming convention agreed in week one and half-ignored by week ten.

And where a sequence needs real procedural code, logic blocks are written in Structured Text Lite — a focused subset of the ST your team already knows. Whoever writes ST today is productive here on the first afternoon, and the ST sits inside the state machine rather than replacing it.

The project is text, so it belongs in version control

A project saves as a folder of small plain-text files — one per state, condition, interface, piece of equipment, machine — written in a fixed order every time. That is not an export or a second copy to keep in step; it is simply how a project is stored and opened.

Which means the machine gets treated like everything else your company builds. A change is a readable diff rather than a new copy of an opaque file, so it can be reviewed before it reaches the plant. Two engineers can work the same week without taking turns, because separate parts of the machine are separate files. And you can branch a customer variant, tag what shipped, and go back to exactly the version that ran in March — using Git, or whatever your organisation already trusts, since none of it needs to understand the format to store it. See version control.

One runtime, published for the box in front of you and installed as a service that starts with it:

The low end is not theoretical. A four-core ARM board with a single gigabyte of RAM — the sort of thing that costs less than the connector kit on a mid-range PLC — runs a live plant model at around fourteen percent CPU. A three-station cell does not need a rack, and a large line is not capped by what one controller can carry, because machines can be split across boxes.

EtherCAT is the one exception: it runs through a real-time bridge and needs a Linux kernel underneath it. Everything else behaves identically on both operating systems.

All of these run at once, in one project, with as many named instances of each as you need — three separate Modbus networks are three instances, not a problem:

The machine logic never names an address. Where a value lives on the wire is held in a separate mapping layer, which is why re-wiring a panel does not touch a sequence — and why the twin above can be swapped for the plant by changing routing rather than logic.

StateTick ships its own HMI builder and its own digital twin. Touch Studio builds the operator panel; TwinTick Studio is a 3D physics-based digital twin in which your real controller drives a model of the line. Neither is a third-party integration and neither works standalone — both are StateTick applications that bind to the controller.

Everything above is the controller. These are the applications that connect to it — and the reason they are worth having together is that they all read the same description of the plant, so there is no tag list to maintain in two places and no export to keep in step.