Production decisions
When the machine waits, speed is not the problem
An RFID encoding line was producing half of what it could. The transport was ready to advance; unseen retries were holding it back. Solving that doubled output and meant rethinking how the product was checked.
A machine that encodes and personalises RFID tickets on a reel. It advances in groups of ten, waits for the group to be encoded, prints, and continues.
It worked. There were no errors, no stoppages, no failed parts. It produced 11 or 12 reels of a thousand tickets per eight-hour shift.
After a single change, the same machine, on the same job, produced 25 or 27.
That change was not a faster motor or a new transport system. It was understanding where the time was going.
A machine that "works" can be losing half its output
The first instinct when a machine produces too little is to look for speed: accelerate the feed, shorten movements, squeeze the cycle.
Here, none of that would have helped. The transport was already ready to advance. The machine was not running slowly: it was waiting.
Each group of ten tickets must be encoded before the web advances. The machine waits for confirmation and only then continues. If encoding takes time, everything takes time.
And encoding was taking time because it had to be repeated.
Retries: a defect that does not look like a defect
The encoding stations were very close together. That makes sense: the more compact the area, the more tickets can be encoded at once. But in RFID, nearby antennas interfere with each other. One station could affect the station for the neighbouring ticket, encoding would not be confirmed at the first attempt, and the program had to repeat the operation.
The final result was correct. The tickets were properly encoded. That is why the problem did not appear in any defect log.
But every retry meant time with the web stationary. Multiplied by thousands of groups a day, that time accounted for half the shift.
A retry is a defect that corrects itself, which is why nobody counts it. There is no faulty part to set aside, no alarm, no complaint. Just a machine delivering less than it should, until everyone assumes that is its normal pace.
The solution: isolate each station
A proprietary isolation system was developed between stations: each operates inside its own enclosure, without interfering with its neighbours.
This allows all ten stations to encode simultaneously and drastically reduces retries. The machine stops waiting, and the transport, which was already ready, can finally work at its own pace.
The figures for the reference job:
| Before | With isolation | |
|---|---|---|
| Reels per 8-hour shift | 11–12 | 25–27 |
| Average time per reel | 40–44 min | ~18.5 min |
| Additional tickets per shift | — | 13,000–16,000 |
More than double. An increase of between 108% and 145%, calculated over the full shift, including reel changes and stoppages.
It is also worth stating what those figures are not: performance depends on the product and the validations its encoding requires. Other jobs will produce different results. The principle remains the same.
Where to look before speeding anything up
If a machine produces less than it should, ask these questions before changing a single speed parameter:
- Is the machine moving or waiting? Time a cycle and separate moving time from stationary time. If most of it is waiting, faster movement will not help.
- What is it waiting for? A confirmation, a signal, a reading, an external system. That is the operation setting the pace.
- Does that operation succeed first time? Retries, repeated readings, automatic repetitions. If the program handles them on its own, you may never have noticed them. Count them.
- Why is it being repeated? This is usually where the real cause lies: interference, positioning, an unstable reference, an incorrectly set waiting time.
A machine's bottleneck is almost never its most visible part. It is the operation on which all the others depend, and whatever makes it repeat.
What happens when you double the pace
There is a consequence worth anticipating, because it follows naturally.
Before the improvement, the operator could visually check the product while the machine worked. At twice the pace, that monitoring was no longer realistic. Nobody can sustain attention on twice as many tickets for eight hours.
That is why the next step was to integrate vision inspection into the process itself: it checks both sides, personalisation and chip position, and stops the machine if it finds an incorrect ticket. The operator invalidates it and continues.
It is a rule that applies to any line: when you improve capacity, review the controls. A check designed for one pace will not necessarily work at twice that pace. Unless it is reviewed, increased output may also mean more defects getting through.
An improvement that reaches more than one machine
This improvement did not originate in the latest machine in the series. It was introduced in an intermediate machine and then retrofitted to those already working.
If six machines run that same job at the same performance, the difference amounts to between 78,000 and 96,000 more tickets per shift. Without buying six new machines.
That is the other lesson of this case. When a fundamental problem in a machine is solved, the next question is not just "how do I include this in the next one?", but "how many of the machines I already have share this problem?" Often, the most profitable improvement is in equipment that has already been paid for.
At 7Axis Industrial, we design and build complete purpose-built machines and develop existing equipment based on what happens in production. Before speeding things up, we find out where the time goes.
See the full CCPB7 case study → Machinery modifications and upgrades →