Finding Packaging Line Bottlenecks with Basic Production Data

When a packaging line misses its output target, the usual reaction is to look at the slowest machine on the rated-speed list or at whichever machine stops most visibly. Both can be wrong. A line produces at the pace of its constraint, and the constraint is not always the machine with the lowest nameplate speed or the loudest alarms.

Most plants can find the constraint with a shift log or a basic controller counter that records how long each machine spent running, starved, blocked and down. The sections below define those four states, show how to read the pattern across the line, and relate the result to OEE. A worked example with assumed numbers walks through the reasoning.

How machine states reveal the constraint

In a serial line, product moves from one machine to the next. For this analysis each machine is in one of four states at any moment.

• Running: the machine is operating and producing output.
• Starved: the machine is ready but has no product, pack or material arriving from upstream.
• Blocked: the machine has output but cannot discharge it because the next machine or the conveyor between them is full.
• Down: the machine has stopped because of its own fault, a planned stop, a changeover, a jam or an operator intervention.

Starved and blocked are waiting states caused by neighbors. Down is the machine’s own lost time. The analysis depends on keeping them apart, because a machine that shows 90 minutes of “stopped” time tells you little until you know whether it was waiting for others or failing on its own.

Machine state models used in packaging control, such as the PackML state model in the references, define states in a similar way and make automatic logging easier. If your machines do not publish states, a stopwatch and a tally sheet per shift can still work for a first pass.

The logic comes from the Theory of Constraints literature: the throughput of a serial system is governed by its bottleneck, and effort spent elsewhere does not raise output. On a line the constraint leaves a recognizable signature:

• Machines upstream of the constraint fill their outfeed conveyors and spend time blocked.
• Machines downstream of the constraint wait for product and spend time starved.
• The constraint itself is rarely blocked or starved, because product is always waiting for it and there is always room ahead of it. Its lost time is mostly its own.

Reading the pattern: a worked example

The table below uses assumed numbers. Every row adds up to the 480-minute shift.

Start with the machines before the Labeler. The Filler spent 95 of 480 minutes blocked and the Sealer 90. They were ready to run but had nowhere to put their output, so their running time (360 and 352 minutes) was limited by the machine after them, not by their own capability.

The machines after the Labeler show the opposite pattern. The Checkweigher spent 165 minutes starved and the Case packer 175, and neither was blocked at all. They sat waiting for product that did not arrive fast enough.

The Labeler sits between the two groups. It was blocked for only 2 minutes and starved for 30. It ran for 400 of 480 minutes, a running share of 400/480, or about 83 percent, the highest on the sheet. Its 48 minutes of down time is also the highest, against 20 each for the Filler and Sealer and 5 each for the last two machines.

Taken together, the Labeler is the strongest candidate for the constraint: the machines before it back up, the machines after it wait, and it loses the most time to its own stops. It is not the machine with the lowest rated speed. The Filler has that at 120 packs per minute, yet it does not limit the line. It spends 95 minutes blocked because the machine two steps downstream cannot take everything it could make.

The next step is to investigate why the Labeler stops: which causes, how often, and how long each stop lasts. After that, check whether a buffer conveyor between the Labeler and its neighbors could absorb short stops. On this data, raising the speed of the Filler or the Case packer would change little, because the constraint would still cap total output.

Why rated speed is not capacity

A rated speed is the speed a machine is designed or quoted to reach under defined conditions with a defined product and pack. Real capacity on a line is lower, for four reasons:

• The machine spends time in states other than running.
• It may run below rated speed to hold seal quality, fill accuracy or label placement with the actual product and material.
• Its neighbors may limit it through starving and blocking.
• Short stops that never reach a downtime log still cut output.

Rated speed helps when comparing equipment during selection, as described in the guide on packaging machine types. It does not forecast what the line will deliver in a shift. State times come from what actually happened, though you still need counts of good packs to turn them into output.

Building the data set

You do not need a historian to start. A defensible first data set has the elements below.

Element	What to capture	Why it matters
Time window	At least several full shifts under normal production	One unusual shift can point at the wrong machine
State definitions	Written, agreed, and identical for every machine	Prevents one operator calling a jam “down” and another “blocked”
Stop reasons	A short code list for down time	Turns the constraint finding into a target for action
Product and format	Which product and pack size ran	Constraints often move between formats
Counts	Good packs and rejects per machine	Links state time to output

Many controllers can supply state time and counters directly if the machine publishes them through its interface. Ask the machine supplier whether yours can. The line integration checklist lists the signals worth specifying so that “ready”, “running”, “fault”, “full” and “empty” are available from each machine.

Check the constraint can move

A constraint does not stay put. After you improve the Labeler, the next-slowest machine becomes the new limit, and product changes, speed changes and downtime patterns also move it. Re-run the state analysis after each change instead of assuming the previous finding still holds.

How this relates to OEE

OEE combines availability, performance and quality into one figure for a machine or line. ISO 22400-2 defines manufacturing KPIs such as OEE, and the grouping of losses into availability, speed and quality categories traces back to total productive maintenance literature.

State times feed the availability part of that figure directly. Three practical points follow:

• Use OEE at the constraint to see what limits plant output. An hour lost at a non-constraint machine that was blocked anyway may cost nothing in output.
• Do not average OEE across all machines and call the result line performance. Blocked and starved time is a symptom of the constraint, not a loss at the machine that shows it.
• Decide whether blocked and starved time count as availability loss for each machine. Sites define this differently, so write yours down.

If a line shows a low OEE figure and no one can say where the loss sits, the state table above is a cheaper next step than another dashboard.

Information to request from suppliers

When you can influence the data you will get, ask each machine supplier for:

• The list of machine states published on the controller and how each maps to running, starved, blocked and down.
• Which counters are available: good packs, rejects, total starts, and time per state.
• How stops are classified and whether operator-entered reason codes can be attached.
• The interface and data points for exporting this information, and in what format.
• The conditions behind the quoted rated speed, including product, pack format and material.
• The sensor positions that detect “outfeed full” and “infeed empty” and how they are set.

Checklist for a first bottleneck review

• State definitions written and shared with operators and maintenance.
• State times recorded for each machine for several representative shifts.
• Stop reasons captured for down time, with a short code list.
• Product and format recorded alongside each shift.
• Blocked and starved shares calculated for every machine.
• Candidate constraint identified from the pattern across the line.
• Top stop causes at the candidate listed before any equipment change is proposed.

Limits and on-site verification

This method points at a candidate. It does not prove it, and several conditions can mislead.

• If operators feed or clear a machine by hand, the state log may not reflect what the machine could do on its own.
• Stops of a few seconds may not register as down time, which hides losses at the constraint.
• An upstream dryer, a shared compressed air supply, or a single operator covering two machines can limit several machines at once.
• The constraint at one pack size may not be the constraint at another.
• Blocked and starved times are only as accurate as the sensors that detect full and empty conditions.

Confirm the finding by watching the line, checking the stop log against what you see, and testing with real product. Any change to speeds, buffers or guarding needs review by qualified engineers. For safety-related changes, that includes a risk assessment under ISO 12100 or the equivalent in your market.

Related decisions

Once the constraint is known, its stops need causes and plans. A preventive maintenance checklist helps reduce repeat failures, and a format changeover checklist addresses the changeover time that often dominates down time on multi-format lines. If the constraint is at the end of the line, the cartoner versus case packer comparison clarifies which role the machine plays. When a fix means buying equipment, compare the lost output against the total cost of ownership of the options, not only the purchase price.