Industries · 6 min read
An assembly line capacity monitor from a camera and a count, with no code written
Bottles counted in each sampled frame, a count above the line's normal as the rule, and the line lead told before the backup reaches the filler.
Summary
This post describes a capacity monitor for a bottling conveyor built from one camera and one count: bottles boxed in each sampled frame, the count compared with the line's own normal, and an alert to the line lead when it climbs before the backup reaches the filler. It concludes that the threshold belongs to the line and the product rather than to the model, and that the count over weeks is the earliest sign a machine is about to stop. It is for line leads and plant operations teams.
Ayman Quadir · Head of Product · Sep 30, 2026

Bottling line, bottles queued under a fill head, generated scene with detections from our model
At 10:20 am on bottling line 1 the capper slows. Nobody sees it slow, because a capper that runs at nine tenths of its speed sounds the same as one at full speed. What happens next is visible: bottles back up on the conveyor between the filler and the capper, the accumulation table fills, and the filler stops when there is nowhere for its bottles to go. The line lead finds out when the filler stops, walks to the capper, and clears a jam that was five minutes old.
The conveyor between the two machines was showing the problem the whole time. It had more bottles on it than usual.
Object detection counts bottles in each sampled frame
The camera over that stretch of conveyor does one small thing. Object detection finds each bottle in the frame, and the number of boxes is the count. One class, sampled about every two seconds, and the count per frame written down. No tracking, no speed measurement, no identity across frames, because the question is how many bottles are on this stretch right now, and a count answers it.
You type "bottle" once, Lexi puts a box on every bottle in every frame, and a person checks the boxes before anything trains. The checker's attention goes to the bottles touching each other in a backup, since a queue of glass necks under the line's lights is exactly where two bottles read as one. The frames come from the camera at its mounted position, on line 1, on the product line 1 runs.
That is all the model does. Everything after the count is a rule, and the rules are written in sentences.
The line's normal is a number the line lead already knows
Ask the line lead how many bottles sit on that stretch when the line is flowing and the answer is immediate, give or take a few. That is the normal. A backup is a count above the normal that stays above it for a run of frames, and the threshold for "above" is the line lead's number plus a margin the line lead chooses.
The threshold is not a property of the model. It belongs to line 1, to the product line 1 is running, and to the speed the filler is set to that shift. Line 2 next to it, running a larger bottle at a slower speed, has a different normal, and its rule is written separately with its own number. Nothing in the model changes between them.
My own view is that this is where most monitoring projects go wrong: they treat the threshold as something to tune from the model's side, when it was always the line lead's number. Ask the line lead first. The model is only there to count.
The alert reaches the line lead before the backup reaches the filler
The rule is written as a sentence: more bottles than the line 1 normal on the stretch before the capper, for a run of frames, routine severity, with a cooldown so a slow morning does not produce an alert every two seconds. It is approved before it goes live. What arrives is the frame, with the bottles boxed and the count in the corner, on the line lead's screen at the filler station.
The monitoring and alerts doc covers how a model is attached to a feed and how an alert is described. The plant's part of the work is deciding who gets it. On the lines we run, it is the line lead, on a screen, and the alert lands while the accumulation table still has room, which is the difference between walking to the capper and stopping the filler.
The line lead on line 1 still listens to the conveyor. A backup has a sound, glass on glass, and an experienced ear hears it from the office door. The camera is the same instinct made available to the person who is at the other end of the hall.
A rising count over weeks is the earliest sign a machine is about to stop
A backup that clears in a minute is a jam. A stretch of conveyor whose count creeps up a little every shift, for a fortnight, with no jam, is a capper that is wearing. The predictive maintenance use case says why that signal is hard: it accumulates over weeks, so the record is a time series of the same equipment rather than a set of independent frames, and it is worthless unless the frames are comparable.
The count from one camera over one stretch is comparable by construction. Asked in LexInsight, "what did the count before the capper on line 1 do this month", the answer is a curve with the frames behind it, and the curve turns up before the capper fails. The maintenance planner reads the curve and puts the capper on the list for the next planned stop, which is the whole point of the question.
The question retrains nothing. It only reads.
The threshold is re-set at changeover and the model is not
Line 1 changes product on Thursday, from a small bottle to a tall one. Fewer tall bottles fit on the stretch before the capper, so the normal drops, and a rule written for the small bottle now fires all morning on a line that is flowing. The line lead knows this on the first frame. The fix is a number in a sentence, the tall bottle's normal, and a rule per product rather than a rule per line.
What does not change is the model. A tall bottle is still a bottle, and the boxes hold. The first version was trained on the small bottle, so the tall one comes back as doubted frames for a shift, a person confirms the boxes, and the corrections go into the next version. The count was already right by the afternoon; what the corrections buy is the count being right without the doubt.
Foam and fallen bottles are the frames that come back
LexData takes the bottle model through its whole life. You type what to look for, Lexi puts a box on every bottle in every frame, and a person checks each label before anything trains on it. The model then watches the camera over line 1, in the cloud, on your servers, or on a runner beside the recorder. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime.
The frames that come back in the first month are a bottle on its side in the queue, foam over the necks after the filler, glare on the glass at the hour the sun comes through the loading door, and the tall bottle from Thursday. Each is a correction, and when the corrections cross the project's threshold a new version trains. In manufacturing the figure we hold to is 99%+ accuracy maintained in production, and on a bottling line it is maintained by the line lead correcting a count on the frames that came back, between one changeover and the next.
See it on your own footage.
Start with your footageMore in Industries

Industries · 6 min read
Perimeter security with fixed cameras, object detection and a drone sent to look
A frame every two seconds is enough to catch a person at the fence, a CPU is enough to run it, and the drone is the second look rather than the detector.
Andreas Ohrvall · Sep 30, 2026

Industries · 7 min read
Food service QA with a camera over the tray packing line
Every component on the tray gets a box, the missing one is flagged before the sealer, and the alert count is read against the line's own history.
Ayman Quadir · Sep 30, 2026

Industries · 7 min read
Railway safety with trackside cameras, zones and a signaller who can live with the alerts
People and vehicles boxed, the track bed and crossing drawn as zones, the frame sent to the control room, and a false alarm rate a signaller will keep reading.
Rajiya Sultana · Sep 30, 2026