Software-Defined Gantry
When a machine's character is decided by code, manufacturing has to relearn one thing: control.
Controlled Industrial Intelligence
CIICII № 01 · Software-Defined Gantry
Contributors & Collaborators
- Triple-I
- QLab
- XLab
- ASC
Editorial
CII is a magazine about controlled industrial intelligence. It is less interested in how large a model is than in whether a production line still behaves as expected at three o’clock on a Tuesday afternoon — and, when it does not, whether anyone can say precisely why.
The launch issue starts with a gantry machine that was rebuilt rather than replaced. It is old enough to still carry the marks of relay logic, and new enough that its acceleration profile is now decided by a program that can be read, reviewed and reverted.
(Placeholder copy.)
In this issue
Contents
Stories
Rebuilding a Gantry in Software
Moving motion control off dedicated hardware and onto general-purpose computing saves procurement cost. What it puts at risk is determinism.
The machine had been in service for eleven years. Its servo drives were still dependable and its mechanical accuracy had never fallen outside tolerance at the annual inspection. What showed its age was the control cabinet: a closed system that only the original manufacturer’s engineers were permitted to modify. Every process change, however small, joined a three-week queue.
The goal of the rebuild was therefore not faster. It was changeable. The team kept the mechanics and the drives untouched and moved only motion planning and logic control onto an industrial computer, with an open real-time kernel carrying the control cycle.
The first problem is jitter
In the laboratory, a general-purpose operating system runs a one-kilohertz control loop without breaking a sweat. On the shop floor, the same code arrives late by 1.4 milliseconds somewhere around the four-millionth cycle — and that single late arrival is enough to leave a visible tool mark on the workpiece.
This is the part that surprises people who arrive from web engineering, where an average is a perfectly reasonable thing to optimise. An average is not a promise. A machine tool does not care what the mean cycle time was over an hour; it cares about the worst cycle in that hour, because that is the one that shows up in the surface finish. The tail is the specification.
The second problem is authority
Once the control logic is a repository, who is allowed to merge? The work that actually consumed the schedule was not porting code. It was writing down, as procedure, who may change how the machine behaves: a branching strategy, a rollback window, and a change note that a process engineer has to sign before anything reaches the floor.
None of that is glamorous, and none of it appears in a demonstration. It is also the only reason the rebuild was allowed to run unsupervised after the first month.
(Placeholder copy, set to test the two-column measure and the page depth.)
On site
The temporary layout, mid-rebuild
The new cabinet sat beside the machine for a full quarter. The original loom stayed in place the entire time — both systems ran, and only one of them was trusted.
Placeholder image
The future of control is not in the hardware. It is in the code — but the code has to learn to keep time first.
Insights
Control Is a Property You Can Audit
If the intelligence in an industrial setting cannot be reproduced, explained or reverted, it was not intelligence. It was luck.
Take the word “controlled” apart and at least three things fall out of it: behaviour that can be reproduced, state that can be observed, and changes that can be reverted. Remove any one of them and the system can only be run by watching it.
Reproducible means the same input produces the same output on any run — including in time. Observable means that when something goes wrong, the site holds enough record to reconstruct what actually happened, rather than depending on one engineer’s memory of a Thursday. Revertible means every deployment has a stated way back, and that the way back has been rehearsed recently enough to believe in.
This has nothing to do with model capability
A stronger model does not deliver any of the three. If anything it makes them harder to obtain, because it introduces more intermediate state that cannot be explained line by line. That tension is the line CII intends to report along.
It is worth being precise about the disagreement here. Nobody in a plant objects to a system that is difficult to explain in principle; they object to a system that cannot be bounded. A controller whose behaviour is opaque but provably confined — it will never command more than this torque, never leave this envelope, always fail into this state — is deployable. A controller that is beautifully documented and unbounded is not. Auditability is about the boundary, not the internals.
What this means for the reporting
The practical consequence is that most of what this magazine covers will look unglamorous: interlocks, logging formats, rollback drills, the paperwork that decides who signs. The interesting question is rarely whether a technique works in a demonstration. It is what the technique costs when it has to be maintained by a three-person team for a decade.
(Placeholder copy.)
Research
Measuring Control-Loop Jitter
Four configurations, one piece of control logic, seventy-two continuous hours, and the actual arrival time of every single cycle.
Research
The Tail Is the Promise
Control-loop cycle jitter · µs · lower is better
- Median (p50)
- Tail (p99)
Legacy PLC1,450
Soft PLC, stock kernel820
Soft PLC, PREEMPT_RT210
Soft PLC, isolated core96
Table view
| Configuration | p50 (µs) | p99 (µs) |
|---|---|---|
| Legacy PLC | 180 | 1,450 |
| Soft PLC, stock kernel | 96 | 820 |
| Soft PLC, PREEMPT_RT | 41 | 210 |
| Soft PLC, isolated core | 28 | 96 |
Placeholder data — 72h continuous run, 1 kHz loop.
Readers
Aggregated city-level access