StateTick
Tick one box. The signal is on the panel.
Getting a value from a machine onto an operator screen is usually a small project of its own: a second tag list, a driver, an address typed twice, and a week of finding the one that was typed wrong.
Touch Studio is StateTick's own HMI builder. There is no second tag list, because it reads the machine's variables directly from the runtime.
One tick per variable
The panel is not integrated with StateTick. It is part of it.
Open Bus Manager. Beside the columns for your fieldbuses and the digital twin there is a Touch column, and it works exactly like the others: tick the variable, set its direction, save, deploy.
The direction is the whole configuration. Read means the panel writes into StateTick, so that variable is something a button pushes. Write means StateTick publishes it out, so it is something a lamp or a gauge shows. Two options, one per variable, and they are set in the same table where the rest of that variable's routing lives.
That is the end of the setup. The runtime brings its own service up as soon as anything is Touch-routed — nothing to install, no host configuration, no address to allocate.
The picker only offers what will work
Bind a widget and the variable browser lists the variables that fit that binding — right type, right direction. A button offers you the booleans the panel is allowed to write. A state colour offers you the booleans the runtime publishes. Tick show incompatible and the rest appear with their type and direction shown, so a wrong-direction bind is something you see rather than something you commission.
Buttons write a clean edge, too: Toggle, RisingEdge or FallingEdge, with a pulse width you set. A press produces the 0→1 the machine is waiting for, held long enough that a scan cannot miss it.
An HMI package is a separate product with its own tag database, so the variables have to be described twice and then kept in agreement for the life of the plant. Most panel bugs are not logic bugs; they are the two lists disagreeing.
Touch Studio has one list, held by the runtime, so there is nothing to disagree with.
Alarms come from the controller
Alarms belong to the controller. The panel is a display for them, not the place they are defined.
Alarm handling is normally a subsystem of its own: a definition list, an expression language, severities, a historian, and a mapping from each of those to the others. Half of it restates things the control logic already knows, in a second place, in different words.
In StateTick the alarm already exists before Touch Studio is opened, because the controller owns it. A condition is a first-class object there — it has a name, a group and a severity, and it is StateTick that decides the alarm has occurred. You build one by picking the signals you mean and joining them — a term, an operator, another term, brackets if you need them, any of them negated. No expression to type, no syntax to get wrong, and the same builder you use everywhere else.
That condition is what stops the machine. The banner just names it.
What you add in Touch Studio
A group, a priority — Info, Warning, Alarm, Critical — and the words. Whether it hides itself after a few seconds, and whether the operator can dismiss it. That is the whole configuration.
The message can come from the machine too: bind the banner to a string variable and whatever the runtime puts in it becomes the text, so a fault that knows which head or which zone can say so.
The history writes itself
Every banner that rises writes a row into every alarm table in the project — timestamp, group, priority, message. Rows for alarms that are still live keep a coloured spine, and dismissing a banner never erases what happened. You did not configure a historian; you configured a banner.
A table can filter to one group, so a station screen shows its own alarms while a supervisor page shows everything. It holds a bounded number of rows so an unattended panel cannot grow forever, and carries a close all for the moment when the screen is full.
A real alarm page, not a workaround
A page can be marked as the alarm page, and any widget can be the button that opens it — with a back action that returns wherever the operator came from. No hidden screen, no popup pretending to be a page, no navigation logic in the machine to make it work. Navigation writes nothing to the runtime at all, so the alarm page opens on a panel that has lost its link, which is exactly when somebody wants to read it.
Dialogs follow the same rule. The runtime raises a popup, the operator answers, and the answer pulses back on its own variable as a clean edge. The panel never writes the trigger back — that one belongs to the machine — so a dialog cannot argue with the logic that raised it.
Everywhere else, an alarm is authored twice: once as the logic that detects it and once as the alarm-system entry that describes it. Two lists, two vocabularies, and a long tail of alarms that fire without a message or messages that fire without a cause.
Here the detection is the definition.
The parts that actually move
Skipping the parts every drawing tool has, for the two that decide whether a screen is worth looking at.
Colour is ranked, not conditional
A widget carries as many states as you like, each bound to its own variable, and the top of the list wins. Rank Fault above Running and a faulted motor reads as faulted even while it is still turning — which is the behaviour you want and the behaviour that is tedious to build out of nested conditions. Nothing active leaves the widget the colour you drew it.
Movement is a value, mapped
Four transforms take a live value: move on X and Y, rotate, resize, and stretch from an anchored edge — the last being how a tank fills from the bottom. Each takes an optional map and cap, so a level of 0–100 swings a needle through 0–270 degrees without the machine knowing anything about needles.
Readings arrive in steps, so movement is interpolated at a rate you set. A widget that teleports between readings reads as a glitch rather than as motion. The first reading always snaps, so a panel opening shows the plant as it is rather than sweeping everything in from where it was drawn.
Rehearse it before you connect anything
Every motion has a preview strip. Drag a slider to scrub a pretend reading, or press play and watch it sweep on the canvas. The readout shows reading → applied, so a mapped or capped value shows both numbers, and while it travels you see the target too — which is how you judge an interpolation rate before it matters. It runs the same map-then-clamp path the runtime will, and never touches the project.
The tank fills correctly on your desk, before the plant exists.
Where the panel lives
Build emits one self-contained web page, so the panel is a URL rather than a box you have to buy.
| Runs on | Typical use |
|---|---|
| Wall-mounted touch screen | The machine panel, at the machine |
| Tablet | Maintenance rounds, a trolley, line-side checks |
| Desktop or laptop | Engineering, the line office, a supervisor view |
| Any device with a browser | Windows, Linux, Android, iOS — nothing to install |
It is hosted the way the controller is, too. The panel is served from a StateTick host, so the deployment options are the ones you already have — an industrial PC, an embedded box, or a low-cost single-board computer in the cabinet. No dedicated panel hardware, no per-seat player licence, no extra server to stand up beside it.
Touch Studio is not a standalone HMI product. It is part of the StateTick ecosystem and it talks to exactly one thing: a StateTick controller. It carries no tag database of its own, no driver stack, and no connection to a PLC, a fieldbus or a SCADA system.
That is the design, not a gap. StateTick is what binds to the outside world — the fieldbuses, the servers, the instruments — and the panel reads the machine through it. Which is precisely why there is no second tag list to keep in step. TwinTick works the same way.
Press Build and Touch Studio emits a self-contained web application — runtime, styling, scene and images all inlined into one page. Nothing is fetched at runtime, so a panel keeps working with no file server behind it.
Projects hold as many pages as you like, and any widget can be the thing that navigates. The built panel reconnects on its own and wears a corner badge: green connected, amber connecting, red offline.
And as many panels as you want
One runtime serves as many panels as you care to point at it. A screen at every station, a line overview in the office, a tablet on the maintenance round, an engineer's laptop — all live, all reading the same machine at the same time.
Panels are target devices in the project, so a dev box, the line PC and a test rig are three entries you switch between rather than three copies of the project. Adding the fourth panel costs what the fourth screen costs: there is no per-seat player to license, no client to install, and no extra server to stand up beside the runtime.
One report that catches the classic mistake
Variable Mapping lists every binding in the project on one page, sorted by variable, so every place a variable is used sits together. Two widgets writing the same variable is visible at a glance rather than at commissioning, and it tells you the Bus Manager direction each binding needs.
VARIABLE DIR PAGE WIDGET BINDING BUS MANAGER
Pump1.Drive.Running READ Overview Motor lamp State Touch Dir = Write
Pump1.Drive.Fault READ Overview Motor lamp State Touch Dir = Write
Tank1.Level.Pv READ Overview Tank Stretch Touch Dir = Write
Line.Cmd.Start WRITE Overview Start button Click Touch Dir = Read
Line.Cmd.Start WRITE Manual Start button Click bound twice
Why it is worth having them together
The argument in one paragraph.
The panel knows what the machine knows.
Because the HMI and the machine come from the same project, the variable list is never a copy and never out of date. Rename something and the panel is looking at the same object, not at a string that used to match. Add a signal and it is one tick away from being on screen.
What that buys you is not really a feature list. It is that the panel stops being a separate deliverable with its own schedule, its own database and its own class of bugs, and becomes the last hour of the machine rather than the last fortnight of the project.
The Plant, Described — where those variables come from: interfaces, equipment and instances, and why the bus mapping is kept as its own world.
The Machine, Drawn — the machine behind the panel: reusable states, fault and pause paths as standard, and a drawing the whole project can read.