Conveyor case classification with multiple shape models

Mixed-product packing lines cannot run one label all shift. Cases for different varieties, sizes and grades arrive in random order, and each one needs its own GS1-128 label with the right data in the right spot. This application guide is for packaging and intralogistics engineers building that station. You get the timing budget at 60 cases per minute, the pixel math for the camera, the model-ranking and tie-break rules that keep look-alike cartons apart, the trigger and strobe set-up, and a parts list to order against.

How fast must classification run on a 60 cases-per-minute line?

At 60 cases per minute the line gives you one case every 1,000 ms, so capture, transfer and classification together must finish inside about 150 ms and leave the rest of the second for printing and applying the label.

Divide it out: 60 cases / 60 s = 1.0 case per second, which means the station owns 1,000 ms per case. A documented stone-fruit packing line searched more than 100 shape models and read the packers' checkbox marks in about 65 ms per case, then printed and applied the label for roughly 0.5 s end to end. That split is the pattern to copy: vision takes the first tenth of the second, the print-and-apply head takes most of the rest.

Work the budget on your own hardware. A 2 MP mono frame is about 2 MB; over GigE at roughly 100 MB/s of usable throughput that is 20 ms of transfer. Add a 2 ms strobed capture and a 65 ms library search and the vision side sits near 90 ms — inside the 150 ms budget with margin for a busy CPU. If your number lands above 150 ms, the library is too big for one search or the hardware is too small for the library.

How do you train a shape model library for 100 case types?

Capture one image of each case type on the running line, build each model from the box edges plus its printed artwork, and expect hard pairs to need several models — one documented line needed up to six models for a single case before two look-alikes separated.

Train under the strobe, with the case square to the camera, because the model stores edge geometry from exactly those conditions. Include the artwork in the model, not just the box outline: many cartons share a die-cut and only the print tells them apart. Version every model and record which model answered for each case in the database, so a mislabel traces back to a training fault rather than a mystery.

Fix the position reference while you train, because every runtime match inherits the coordinate frame you taught. The pattern matching reference coordinate system guide shows how a wrong origin turns correct scores into wrong case positions downstream of the vision step.

At runtime, search the whole library in one pass and rank what comes back — never stop at the first hit above cutoff.

How do you keep look-alike cases from swapping labels?

Keep every model whose score clears a minimum cutoff, then treat a close race as a reject: when the top two scores sit within 0.05 of each other, run the grayscale check or the checkbox regions before you accept the winner.

Normalise scores to a 0-to-1 scale and start the cutoff near 0.6, then move it against data: raise it until good cases begin to fail, lower it until a wrong model wins. The margin between first and second place is the number that actually protects the label. Where two cases differ only in print colour, a grayscale histogram on the same image breaks the tie; where they differ in what the packer marked, the checkbox regions decide — read as a second classifier, not decoration. The documented line read which boxes were checked and used that to establish the size and count inside the case.

Judge a match score the way you would judge a decode: the barcode read confidence guide shows how to separate trustworthy results from lucky ones. A swapped label ships product under the wrong code, so plan the failure budget for that worst case with the vision inspection error rate planning guide. The same conflict appears when several models answer one scene — multiple inspection models in the same scene covers why first-hit logic loses there and ranking wins.

How many pixels does the classification camera need?

Give the smallest mark you classify at least 3 pixels across — for the 3 mm checkbox tick and a 600 mm field of view that means 1 mm per pixel, or 600 pixels across the field, which even a 1.3 MP camera clears.

Run the numbers backwards for a real sensor. Take a 2 MP camera with a 1,600 × 1,200 array over that 600 mm field: 600 mm / 1,600 px = 0.375 mm per pixel, so the 3 mm tick spans 8 pixels and shape matching has abundant edge to score. The squeeze appears in small print — a 0.5 mm grade character spans about 1.3 pixels there, too coarse to read, which is why stamped or stickered variety text belongs on a higher-resolution sensor or a dedicated reader station.

Which camera runs the match: on-device vision or a PC?

Run the library on the device when one camera serves one station and the library stays in the low hundreds of models; move the match to a multicore PC when classification, OCR, code reading and database logging all share one image.

The classification image is a strobed still, so mono and a global shutter are the sensible choice: shutter skew and colour cost money here and buy nothing. For a single-station line, vision sensors and smart cameras run the match where the image is born and leave the line PC free for logging. The HK-TD032-12-WBN is a 1.6 MP mono vision sensor with a global shutter and an M12 mount, the resolution class this application has always lived in.

Finer artwork pushes you up in pixels. The LS-SMC-0017 is an 8.8 MP smart camera on the x86 platform, with a C-mount and a global shutter, so the library and the match run on the device with no PC in the loop — its full sensor and interface details are on the card below.

Past a few hundred models, or when OCR and code reading share the image, a multicore PC wins: run the search where the CPU cores are and keep the camera as the image source. Both routes start in the same camera finder.

What triggers the shot, and how do you freeze the case?

Fire the camera from an infeed sensor and strobe the lights for a pulse of tens of microseconds, so exposure — not conveyor speed — sets the blur: at 0.375 mm per pixel and 0.5 m/s the shutter must be 0.75 ms or faster.

A 0.5 m/s belt — 30 m/min, a common packing-line speed — sets that 0.75 ms limit; at 1.0 m/s it halves to 0.375 ms. A 20-50 microsecond strobe beats either limit by more than an order of magnitude, which is why trigger-plus-strobe beats a short shutter here: one sensor pulse fires the exposure window and the light together, and the frame comes back bright and frozen. If your camera takes its exposure from the trigger pulse itself, check the pulse width against the trigger pulse width and exposure guide; for cases arriving back to back, the hardware trigger frame rate guide walks the trigger-to-frame pipeline.

One photoelectric sensor covers single-file triggering: a diffuse-reflective type with a settable distance and an NPN output such as the MV-PE5502 fires when the case front breaks its red LED spot, and the trigger sensor finder sorts the longer-range and through-beam types.

Aim the strobes 30-45° off the camera axis so gloss from shrink-wrap reflects away from the lens, and keep the sensor-to-shot delay constant. Belt creep between trigger and exposure moves the case by speed × delay — 0.5 m/s × 20 ms = 10 mm, enough to slide every model off its trained position.

How does the result become a printed GS1-128 label?

Merge the case identity with grower, pack date and packer ID into a GS1-128 string, push it over Ethernet to the print-and-apply head, and read the packer's own barcode sticker with a reader so the database logs who packed each case.

GS1-128 is GS1's data-carrying symbology: a Code 128 symbol that prefixes each field with an Application Identifier. The three this station needs are (01) for the 14-digit GTIN, (11) for the production date as YYMMDD and (10) for the batch or lot, so a case label reading (01)09506001345678(11)250615(10)PEACH42 tells any supply-chain partner the product, the pack date and the lot in one scan.

The classifier output becomes those fields: case type and size from the model, count and grade from the checkbox regions, variety from OCR where the packer used a sticker or a stamp. Reading several text strings from one case face is a solved job — the OCR on a fixed code reader guide walks the multi-string case.

Read the packer's sticker at the same station or the next one with a fixed code reader. The LS-CRD-0028 is a 2560 × 2048 reader with a 5 MP sensor, a global shutter, an 8 mm lens and a decode rate of 60 codes per second: at one case per second the line uses a sixtieth of that budget, so a missed read costs a retry rather than a case.

Trigger the reader the same way as the camera — sensor, serial command or free-run all work, and the fixed barcode reader trigger modes guide compares the three. Close the loop by grading the label you just applied: the barcode reader verification guide turns the fresh print into a pass/fail quality result before the case leaves the station.

When is a shape-model library the wrong answer?

Skip the library when cases already carry a scannable label that says what they are — a fixed code reader then classifies for a fraction of the engineering effort — and think again when artwork changes every seasonal print run, because stale models misclassify quietly.

The library earns its keep when the identifying marks are unstructured: hand-checked boxes, rubber stamps, grade codes printed on plain board. When the marks are already machine-readable, read-then-look-up is simpler and cannot drift. When appearance varies beyond geometry — printed film, wet stock, natural product — a learned classifier may beat edge models, and the AI versus rule-based inspection guide weighs that decision.

What should you check before ordering?

Prove three failure cases on 100 images each before you commit: a case type with no model must divert, two models finishing within 0.05 of each other must tie-break, and an artwork change must fail loudly rather than match the old model at 0.62.

• Search time on the target device. Time 100 full library searches and average them; the mean must sit under about 50 ms so classification fits the 150 ms vision budget with capture and transfer included.
• Score margins on real cases. Log first and second place for a full shift; if the top two finish within 0.05 more than a handful of times per thousand cases, the tie-break needs work before the printer is connected.
• The abstain path. Run an untrained carton through and prove the PLC diverts it; the no-model outcome must be a designed state, not an exception.
• Trigger-to-shot delay. Measure it at top belt speed; at 0.5 m/s a 20 ms delay is 10 mm of belt creep and 10 mm of model misplacement.
• Checkbox ground truth. Mark the checkbox regions per case type and prove a wrong-tick case fails; those regions are the label data, so they deserve the same rigour as the model scores.
• Model governance. Version-stamp the library into every record and add each new case type on the line, under the strobe, before its first label prints.

Size the camera, reader and trigger as one system in the configurator, starting from the trigger step if the station layout is already fixed. More label-side techniques sit on the code reading topic page, and the guides hub indexes everything else. To have a library sized against your own case list, contact the applications team.