The context
Our client runs a converting line that unwinds a reel of material and a backing at the same time, prints the result from plates mounted on a limited number of ink units, perforates, then slits the web lengthwise to produce several finished reels in a single pass.
Preparing a machine pass — what the trade calls a production plan — means coherently choosing the feed reel and its backing, the perforating tooling, the cutting layout that fixes the exact sequence of widths, the finished products placed in each slot, then the print plates and how the colours are spread across the available ink units.
None of those choices is independent of the others, and that is where the trade gets hard.
Before the project, all of this lived in the heads of a few experienced operators, with a spreadsheet for support. The consequences were predictable: heavy dependence on two or three people, long preparation, sub-optimal combinations accepted for lack of time to explore better ones, and mistakes caught at the machine — meaning setup done twice and material wasted.
The question put to the software looks simple: given what the operator has already selected, what can they still choose? Answering it exactly means solving, on every click, an exact tiling with sequencing, alongside a colouring problem under a resource constraint. Those sub-problems are NP-hard, the catalogue runs to several thousand references, and the answer has to arrive fast enough to pass for a user interface.
What we did
We built the software, put it into service in 2019, and have maintained and extended it ever since.
- An interactive configurator, not a black-box optimiser. The decision stays with the operator; the software only forbids the dead ends. What is greyed out is impossible, and when a constraint leaves a single candidate, the software selects it and propagates. An optimiser handing over an “ideal” plan without explaining it would have been worked around within three weeks.
- Propagation to a fixed point. On every action, some twenty filters mutually reduce the candidate sets and iterate until nothing moves. They are ordered from cheapest to most expensive, and as soon as a cheap filter eliminates anything the cycle restarts: the expensive filters never work on a set that could have been reduced for less.
- Reduction by equivalence classes. Two references sharing width, number of imprints and colours are interchangeable as far as feasibility goes. The engine groups them behind one footprint: the search space collapses, and a result becomes reusable from one reference to another.
- A doubly indexed feasibility cache. Valid combinations already found are stored as multisets of footprints. The cache answers either directly on the current selection, or by inclusion, reusing a larger known combination as long as it contains the selection and its complement is still available. In real use, the large majority of questions put to the engine never reach the search at all.
- A proof of existence rather than an enumeration. Validating an option only requires exhibiting one feasible combination: the search stops at the first witness, and candidates are explored in an order chosen to hit one quickly.
- Continuous synchronisation with the ERP. Items, stock and sales history are replicated incrementally on modification timestamp, in batches, with recovery on error. Two quirks of the source had to be absorbed: a timezone offset on dates, and a timestamp rounded to the minute, which forces a sliding window to be re-read so nothing is lost. The shop floor works on current data without re-entering it, and the ERP stays the source of truth.
- Direct dialogue with the line’s PLC. A dedicated service polls its speed several times a second and restarts the link when it stalls. That raw stream is aggregated into production periods, stoppage periods and metres produced: output is no longer declared, it is measured. An emulator makes it possible to develop and demonstrate away from the shop floor.
- Planning, quantities and reporting. Calendar, opening hours, maintenance windows, and changeover durations split across the roles involved. Sales history feeds a quantity calculation that ranks each product by criticality, from mandatory to overstocked: the operator sees not only what they can produce, but what they should. The daily report is generated as a PDF, archived and sent with no human involvement.
On the engineering side, two decisions carried the rest. The trade vocabulary is encoded in the type system — some sixty types formally describe materials, tooling, cutting layouts and scheduling objects — and that file is more authoritative on the business than any documentation. And the engine knows nothing about display: it exposes a state the interface merely renders, which is what allowed it to be reworked deeply without touching a single screen.
The outcome
The software has been running on the shop floor since 2019. It is in daily use at the core of the business: no machine pass gets prepared without it. It keeps receiving changes, including a migration of its storage engine — the most reliable sign that a line-of-business application has found its place: people keep investing in it.
Preparation know-how moved from the memory of a few people to an asset of the company. Preparing a plan became a matter of minutes, and invalid combinations no longer reach the machine. Real output is measured at source, and the daily report costs no human time.
The most useful lesson is an implementation detail that decides whether the whole thing holds: each filter returns the original array by reference when it eliminates nothing. Convergence detection is then a reference comparison, free, instead of a deep comparison on every iteration. On a loop that runs on every click, that is the difference between an interface and an hourglass.