Inline packaging inspection: run multiple checks and track each unit

A packaging line that checks caps, labels, date codes and barcodes usually grows one station per check, and then rejects start arriving at the wrong place. The cleaner architecture puts one triggered frame per pack through all of its visual checks and tags every result with an ID the track controller already knows. This guide lays that out: which check families a single station carries, how the ID and result channel work over OPC UA, the speed budget at 100 packs per minute with the arithmetic shown, the resolution math behind the label and date check, and the points where you should still split the work across stations.

Which checks should one inline packaging station run?

Most packaging recalls trace to four visible failures, so one station should check all four from a single triggered frame: seal or cap presence by blob analysis, label position and completeness by matching, the printed date and allergen text by OCR, and the 1D or 2D code by decoding.

Run each family on its own ROI inside that one frame; you can split one image into multiple ROIs and grade each separately. Keep the verdicts independent: a passing cap check must never rescue a missing date code.

• Seal and cap, blob analysis — missing cap, tilted cap, open seal corner, underfill shadow where product should be.
• Label, matching — missing, doubled or skewed label, wrong label variant for the SKU on the belt.
• Date and allergen text, OCR — missing best-before line, wrong date format, allergen statement the upstream printer never applied.
• Codes, decoding — unreadable symbology, or a readable code whose content does not match the recipe.

If two tools watch the same ROI, fix the evaluation order in advance. A scene can match more than one model, and first result wins unless you sequence the tools on purpose.

Can a smart camera run all the checks, or do you need a vision controller?

A vision sensor or smart camera settles one or two check families on the device in tens of milliseconds; a four-family set with per-unit IDs, recipe handling and PLC reporting belongs on a vision controller that also hosts the code reader.

Split the work by what each device does best. Codes go to a dedicated fixed code reader, because a reader's decoder is faster and tolerates steeper code angles than a general camera tool. Label and seal checks sit on a smart camera. The vision controller owns OCR, the ID bookkeeping, the recipe set and the result channel, and merges both devices' verdicts into one record per pack.

For the 100 packs per minute example the split looks like this. The MV-SC5060XM-08M-WBN carries the label and seal checks on a 6 MP mono sensor with an 8 mm lens over GigE.

The MV-ID3013PM-12M-WBN reads the retail code through its 12 mm lens on Fast Ethernet.

The MV-VC2140-128G40-1T runs the merged inspection and the recipes, with 8 GB of memory and 4 built-in light channels driving the strobe.

The same three roles exist in other series, for lines whose checks or interfaces differ:

How does each result stay matched to the right pack?

The track controller issues an incrementing ID with every trigger, and the vision station returns each verdict tagged with that ID; at 100 packs per minute a new ID arrives every 0.6 s, so the result channel must publish one verdict per ID before the next trigger.

Put the ID where the physical tracking lives. A photoelectric sensor at the infeed raises the trigger, the track controller increments its unit counter and starts following that pack's encoder position, and it hands the vision station a trigger plus the ID over Ethernet. Each camera acquires on the hardware trigger — set the trigger mode explicitly, because free-run is the default to switch off, per camera. Code readers take the same scheme through their own sensor, serial or free-run trigger modes. The station writes back one record: ID, verdict per check, overall verdict, timestamp.

Two timing traps break the matching. First, the verdict must return inside the 0.6 s window, or the pack outruns its result. Second, the verdict attaches by ID, never by order of arrival; if two results ever swap, timestamp matching exposes it. With the reject station 1,200 mm downstream and the belt at 1,000 mm/s, the controller holds each verdict for 1,200 mm ÷ 1,000 mm/s = 1.2 s — two pack pitches at 600 mm — then fires the valve against that ID.

How fast must the station be at 100 packs per minute?

One image per pack every 0.6 s sets the whole budget: a flash around 30 µs, processing allocations near 320 ms for the four checks, and about 280 ms of margin for retries and the result write.

Work the budget from the line rate, not from a camera's maximum frame rate:

• 100 packs per minute ÷ 60 = 1.67 packs/s, so one image every 1 ÷ 1.67 = 0.6 s.
• Pack pitch 600 mm, so belt speed v = 1.67 packs/s × 600 mm = 1,000 mm/s.
• Blur limit of 1 px at 0.05 mm/px gives t_max = p ÷ v = 0.05 mm ÷ 1,000 mm/s = 50 µs.

A 30 µs strobe tightens that further: the pack travels 30 µs × 1,000 mm/s = 0.03 mm, about 0.6 px, so motion is frozen and brightness comes from the flash rather than a long exposure. Then allocate the 600 ms cycle:

The rows total 600 ms. Treat the allocations as starting values and measure each on your own label stock before the station is committed.

What field of view and pixel size does the label and date check need?

Size the pixel from the smallest mark you must judge: a 0.25 mm date-code dot resolved at 4 px needs 0.0625 mm/px, so an 80 mm wide field asks for 1,280 px of sensor width — any 5 MP class sensor, from roughly 1,600 px wide, clears it with margin.

Field of view comes first: one frame must cover cap, seal and label. On a 70 mm wide pack with the label centered, an 80 mm × 60 mm field leaves margin for belt wander. The pixel budget then follows from the inkjet date dot:

• Required pixel size: 0.25 mm ÷ 4 px = 0.0625 mm/px.
• Sensor width needed: 80 mm ÷ 0.0625 mm/px = 1,280 px.

Working distance follows from the sensor; treat this part as an estimate. A 1/2.4" sensor is about 5.7 mm wide, so magnification m = 5.7 mm ÷ 80 mm = 0.071, and WD = f × (1 + m) ÷ m = 8 mm × 1.071 ÷ 0.071 ≈ 120 mm over the belt. Keep the ROIs tight around each check region: ROI area, more than sensor size, sets processing time, and the ROI discipline for inline code reading shows the same lever at work for decodes.

How do the results reach the track controller and reject valve?

Publish the verdict set over OPC UA as one record per ID — pass or fail plus per-check detail — and let the track controller drive the reject valve; on a pass or fail line, a single discrete reject output from the vision controller does the same job with less setup.

OPC UA fits because both ends already speak it on packaging machinery. The vision controller publishes a result object per ID, the track controller subscribes, and the pair keeps a permanent record linking code content, OCR text and verdict per unit — the same pattern as inline traceability validation. A smart camera can publish its own results the same way; the OPC UA result setup for smart cameras walks through the variable layout. At 1.67 records per second the update load is negligible for any industrial UA server, and the record stays small: ID, four booleans, overall verdict, timestamp.

Where the PLC only needs pass or fail, wire one discrete reject output and keep the per-check detail in the vision controller's own log.

What does a product changeover need?

Each SKU needs a recipe holding its template images, ROI positions, OCR whitelist for the date format and code content mask; load the next recipe before the first new pack reaches the field of view, then prove it on golden packs before releasing the line.

Give every SKU one recipe with the label template or shape model, the ROI positions, the OCR whitelist (allowed characters and date format), the code content mask (expected GTIN or URL) and the blob limits for the seal. The PLC calls the switch by number — one unique command code per recipe keeps the handshake unambiguous — and the station loads it during the gap before the first new pack arrives.

Date codes come from the printer upstream, and ink drift is a common false-reject source. If the project also adds inline batch printers to form-fill-seal machines, plan the printer and the OCR whitelist together so the printed format and the check agree from day one.

What should you prove before ordering the station?

Before ordering, prove four things on samples: every seeded defect gets caught, a full 600 ms cycle holds with all checks live, the reject valve fires the right ID 1.2 s after the camera, and the recipe set covers every SKU the line runs.

Run the proofs as written tests, not impressions:

1. Seeded-fail capture: at least 20 known-good packs plus three seeded defects per family — missing cap, skewed label, wrong date, unreadable code — all caught, none passed.
2. Cycle hold: 30 minutes at the full 100 packs per minute with every check live and no growth in the result queue.
3. ID-to-reject mapping: mark 50 packs, seed defects into 25 of them, and confirm each rejected pack is a seeded ID while all 25 clean packs pass untouched.
4. Recipe coverage: load every SKU recipe in sequence, rerun its golden set, and confirm each passes and fails as expected.

Log the failing check per ID in every test. At 144,000 packs per day, even a 0.1 percent false-reject rate sends 144 packs to review, and a log that names the failing check is what keeps those reviews short.

When is one multi-check station the wrong answer?

Split the checks when one frame cannot serve them: codes on the pack bottom, foil that needs backlight while the seal needs a directional light, or rates past about 300 packs per minute, where the 0.2 s cycle no longer fits four checks on one controller.

The cases, with the numbers that force them:

• Codes on the bottom face: add a second station looking up through a clear belt window, same ID scheme, verdicts merged on the controller.
• Conflicting light: transparent film wants backlight while the seal wants a directional bright- or dark-field arrangement; one light cannot serve both, so run two stations.
• Rate above roughly 300 packs per minute: 60 ÷ 300 = 0.2 s per pack, under the 320 ms four-check allocation, so give each station one or two families.
• Appearance too variable for templates: recurring print drift can defeat matching; the choice between AI and rule-based checks applies per check family, not per station.

One ID still rules all of it. Merge every station's verdicts on the vision controller and publish a single record per pack, so the reject logic keeps the same shape as stations multiply.

Ready to lay this out? Size the cameras in the camera finder, assemble the station in the configurator, and send your check list, pack pitch and SKU count through the contact page if you want a review before ordering. More integration patterns sit in the applications guides and the guides hub.