StateTick
The hardware decision comes last.
On most projects it comes first. Somebody picks a controller in week one, and from then on every question — which protocol, which I/O, what the logic can even look like — has already been answered by that purchase order.
StateTick runs on the machine you choose, on the operating system you already have, over whichever protocols your plant actually speaks.
It runs on the machine
Worth being unambiguous about, because plenty of software in this space only watches.
StateTick is not a supervisory layer. It is not a dashboard that reads a controller, and it is not an orchestrator sending setpoints down to something else that does the real work. The state machines execute on the box bolted to the machine, driving its I/O directly.
Which means the usual question — what happens when the network goes? — has a boring answer. Nothing happens. There is no link to lose, because nothing upstream was in the control path to begin with.
It installs as a system service and comes up with the box. Execution state and variable values persist across a power cycle, so a machine that was running before the outage is running after it, without anyone logging in. Studio connects when you want to deploy, watch or diagnose, and disconnects when you are done; the plant does not notice either way.
Windows or Linux, big or small
One codebase, published for the box in front of you.
The runtime ships as a self-contained single file with nothing to install alongside it. Four targets are built and used in anger: Windows on x64, and Linux on x64, 64-bit ARM and 32-bit ARM.
TARGET TYPICAL BOX FIELDBUSES
Windows x64 industrial PC, panel PC all except EtherCAT
Linux x64 industrial PC, embedded box all
Linux ARM64 modern single-board computer all
Linux ARM 32-bit low-cost single-board computer all
EtherCAT is Linux only. It runs through a real-time bridge on the host,
so the cyclic bus needs a Linux kernel underneath it. Every other
transport runs the same on both operating systems.
Small really does mean small
The low end is not theoretical. A reference target during development is a four-core ARMv7 board with a single gigabyte of RAM — the kind of thing that costs less than the connector kit on a mid-range PLC. It runs a live plant model at roughly fourteen percent CPU across its four cores, leaving the rest for whatever else you want on the box.
The 32-bit ARM support is deliberate rather than accidental, down to the pointer-width handling in the timing calls. A board that old is still a perfectly good machine controller, and there is no reason to throw one away.
Which means you can size the hardware to the machine instead of to the vendor's catalogue. A three-station cell does not need a rack, and a large line is not capped by what one controller could carry, because machines can be split across boxes.
And as many panels as you want
Operator screens are not a separate purchase either. Touch Studio panels are part of StateTick, and a runtime serves as many of them as you care to point at it — one at each station, a line overview in the office, a tablet for the maintenance round. They are web panels, so the screen is whatever has a browser, and there is no per-seat player to license or extra server to stand up. Adding the fourth panel costs what the fourth screen costs.
Deterministic on both
Cross-platform is only worth having if the timing survives the crossing.
Portability usually costs timing, because the easy way to write a loop that runs everywhere is to sleep and hope. StateTick does not do that on either platform.
The waiting is done the way each operating system does it best, chosen at startup. On Linux that is a monotonic-clock nanosleep, which blocks precisely and burns no CPU while it waits. On Windows it is the high-resolution timer for the bulk of the wait plus a short spin at the end, because Windows will not reliably wake you on time without one. Same behaviour, two implementations, and the machine author never picks between them.
Each machine holds its own period independently of the others, so a fast interlock is not competing with a slow recipe for the same slot — a point covered properly in The Plant, Described.
And the timing is measured, not asserted. Every cycle records its own scan time and its jitter against the target period, so the number you quote for a machine is one you read off that machine rather than one from a datasheet. If a box is too slow for what you asked of it, it tells you which machine and by how much.
This is deterministic scheduling with measured jitter on a general-purpose OS: a control loop that holds its period and tells you when it did not. It works alongside your safety hardware, integrating with external safety modules and relays and sequencing the machine around them. For the timing and safety architecture on a specific machine, send us the project specification.
Speaks what the plant speaks
Eight transports, any number of named instances of each, all in one runtime.
A real plant is rarely one bus. There is the fieldbus the machine builder chose, the Modbus device somebody added in 2011, an instrument with a serial protocol that exists in a PDF, and a SCADA system that wants OPC UA. StateTick carries all of it at once, and a transport is a named instance rather than a slot — three separate Modbus networks are three instances, not a problem.
Nothing about the machine logic changes when the hardware does. The sequence names equipment; the bus mapping names addresses. Swap Modbus remote I/O for EtherCAT and you edit mappings, not machines — which is why the hardware decision can wait until you know what the machine actually needs.
What it connects to
The protocols it speaks, and the hardware it works alongside.
What StateTick speaks
- EtherCAT — digital and analog I/O, validated against standard bus couplers and I/O modules.
- Modbus TCP and Modbus RTU — with named address aliases so a mapping row reads as a signal, not a register number.
- OPC UA — as a server exposing structured machine paths, and as a client onto other systems.
- Serial, ByteSerial and raw TCP — for devices with their own telegram formats.
What it works alongside
- Drives and motion controllers — StateTick speaks their protocols and coordinates them against the rest of the machine, while the drives execute the profiles.
- Safety modules and relays — StateTick integrates with them directly, sees the safety chain, and sequences the machine around it.
- Running in production — three sites today, in packaging and palletising.
- Building something specific? Send us the project specification and we will go through it with you.
Because the bus mapping is a separate layer from the logic, adding a protocol is a change to the mapping table rather than to any machine. The same state plan can be pointed at EtherCAT I/O on one build and Modbus on the next without a line of its sequence changing — which is also how the same plan drives a digital twin instead of hardware.
What that adds up to
One sentence, then the reason it is true.
Choose the box for the job, not the job for the box.
A small cell can run on a board that costs less than a day's engineering. A large line can be split across several boxes, each holding the machines that belong together. A retrofit can keep the serial instruments and the Modbus I/O already in the cabinet and add EtherCAT drives beside them, on one runtime, with one variable model.
None of that is flexibility for its own sake. It is what happens when the logic is not owned by the hardware — the same reason a mapping change is not a logic change, and the same reason a machine can be drawn before anybody has chosen a valve.
The Plant, Described — why the bus mapping is its own world, kept apart from the logic and the equipment model.
The Machine, Drawn — the machine that runs on all of this, and the drawing the whole project can read.