Multi-camera conveyor tracking: one merged results table

Four cameras photograph the same part on one belt, and each station stores its result and the drive position in its own shift table. When two stations reject the same part, the line stops twice for two positions that differ by a hundredth of a micron, and the operator acknowledges twice. This guide shows how to merge the four tables into one: store a stop distance with each station, round each sum to a fixed bin, and let one record carry four results to one stop. The arithmetic runs on a worked line with stations 200 to 550 mm upstream of the stop.

Why does one bad part stop the line four times?

You get four stops because the table is keyed on a raw encoder value, and on this class of line the four stored sums for one part differ by hundredths of a micron — 0.00001 mm — even though the belt itself only stops to a few tenths of a millimetre. The digits that disagree are real encoder counts, but the mechanics never honoured them, so equality matching finds four distinct keys where one part exists.

Walk the worked line used below: four fixed stations photograph each part on the fly, the belt runs from CAM4 toward CAM1, and the encoder reads 2000 mm at the CAM4 shot, 2080 mm at CAM3, 2250 mm at CAM2 and 2350 mm at CAM1. Each station adds its own stop distance and stores the sum. Exact matching then compares 2550.00001 mm against 2550.00003 mm against 2549.99997 mm: four keys, four stop requests, four acknowledgments, one scratch.

Controls engineers meet the same shape whenever parallel conveyor FIFOs accumulate independently; consolidating several conveyor FIFOs into one tracking table is the same merge, one level down on the PLC side. The fix here is to quantize before storing: round each sum to a bin wide enough to swallow the jitter, and write the result into the one record that bin already holds.

What should each camera station write into the tracking table?

Each shot writes four fields — station ID, pass or fail, capture position, and that station's stop distance — so CAM1 at 200 mm from the stop and CAM4 at 550 mm away both feed the same record instead of opening four of them. The stop distance is what turns four different capture points into one shared destination.

Teach the stop distance once per station with a golden part: log the capture position when the camera fires, let the part run to the taught stop, log the drive position there, and store stop_distance = stop − capture. On the worked line the constants are 550 mm for CAM4, 470 mm for CAM3, 300 mm for CAM2 and 200 mm for CAM1. They belong in station configuration, never in the table itself.

Keep the raw capture position beside the result, because the raw value is your diagnostic: when one station's records stop merging with the other three, the raw positions show whether the camera moved or the trigger drifted. Where each station sits along the belt is what sets its stop distance, and the placement reasoning in conveyor tracking camera placement relative to the robot applies to fixed inspection stations as much as to robot-mounted ones.

How do four capture positions become one stop position?

Add the station's stop distance to the capture position and round the sum to the bin grid: on the worked line all four sums land at 2550 mm give or take a hundredth of a micron, and a 1 mm bin turns them into the single key 2550. Call the variables capture_position and stop_distance, both in millimetres, and bin_width_mm the grid pitch.

Rounding to nearest is the right default: a floor operation splits every nominal sum that sits exactly on a whole millimetre, while round-to-nearest only breaks on a sum landing exactly halfway, at x.5 mm — if your line does that, offset the whole grid by 0.5 mm and the problem disappears.

Read the last two columns together: exact equality yields four keys for one part, the 1 mm grid yields one. CAM2's sum lands 0.00003 mm below 2550 and still rounds up, because the nearest grid edge sits at 2549.5 mm — more than 10,000 times further away than the jitter. That margin, not luck, is what makes the merge hold shift after shift.

How wide should the position bin be?

Size the bin between five times your stop spread — about twice the belt's repeatability — and one fifth of the smallest part pitch; at ±0.1 mm repeatability and 250 mm pitch that window runs from 1 mm to 50 mm, so pick 1 mm. Both bounds come from numbers you can measure on the line this week.

Measure the lower bound by running twenty parts and logging the four sums each one collects: the full spread of those sums is your stop spread. A servo-driven index belt lands anywhere between ±0.1 mm and ±0.5 mm of stop repeatability, so a 1 mm bin clears a 0.2 mm spread five times over, and a 5 mm bin covers the worst belts. The upper bound keeps parts apart: consecutive parts' stop positions sit one pitch from each other, and a bin no wider than a fifth of the pitch can never hold two of them — 50 mm at a 250 mm pitch.

The costs of getting it wrong are asymmetric. Too narrow and you are back to double stops; too wide and two parts share a record, and the commanded stop drifts by up to half a bin. A 1 mm bin costs half a millimetre of placement accuracy at the rework stop and discards encoder digits the belt never honoured: one bin spans 100,000 counts of a hundredth-of-a-micron encoder.

How does one merged record produce one stop and one acknowledgment?

Scan the merged table from the far end, and when a record whose bin matches the current position carries any failed flag, issue one stop request to that bin and hold it until the operator acknowledges once, then clear all four flags and keep scanning for the next failing bin. This is your proven single-camera logic with the comparison target quantized; nothing else in the cycle changes.

Give each bin a small record: four result flags, one per station, the raw sums beside them, and the nominal stop value. A record with any failed flag fires exactly one stop request — to 2550 mm in the worked line — and the acknowledgment clears the whole record, so the operator deals with the part once, with all four verdicts on screen.

Two failing parts inside the stop window at once is the remaining edge, and belt order settles it: stop for the nearer part first, acknowledge, then serve the second from the same table. The start/stop sequencing in vision controlled conveyor feeding: start stop logic that works covers that handshake.

What breaks the merged table in production?

Four things break a merged table in production: encoder or position-register rollover, a part removed between stations, a camera that someone moved without re-teaching, and belt slip — check each before trusting the merge, and re-teach all four stop distances after any mechanical change. None of them is exotic; all four show up in the first month.

Rollover first: position registers wrap, and a wrapped value looks like a stop request at the start of the belt. Compare bins in a signed window around the current position, or keep a total-distance figure wide enough never to wrap within a shift, and fire the wrap case on the bench; the failure modes are catalogued in conveyor target acknowledgment at tracking position rollover.

Then the part-handling cases. A part rejected at CAM4 and pulled off before CAM3 must not carry two phantom no-shows: stations that see no part write a no-part flag, and the stop decision reads only the flags that exist. If one station's sums stop merging with the other three, its stop distance no longer matches reality — re-teach it. If every sum drifts together, suspect the encoder or its coupling; conveyor encoder calibration troubleshooting: position resets walks the reset symptoms.

Which hardware should run the merged table?

A four-camera merged table needs a node with at least four camera connections, a link to the belt PLC, and a few kilobytes of table memory; a fanless vision controller with five or more LAN ports hosts all four cameras and hands the PLC a single merged result stream.

Consolidating on one chassis collapses four tables into one process: the controller captures all four cameras, runs the inspections, holds the binned records, and hands over one fault word plus one stop position. Capturing from four cameras on one host has its own timing rules, set out in multi-camera video capture synchronization for four cameras, but the merge itself becomes an array write instead of cross-node messaging.

The catalog vision controllers below differ mainly in LAN port count, onboard memory and bundled license — the port count decides how many camera stations one chassis absorbs:

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The MV-VC5525-256G70-NN lists five or more LAN ports, eight built-in light channels and 32 GB of memory. Four cameras and four strobed station lights therefore run on that one chassis with ports and channels to spare. If you would rather buy the inspection runtime with the box, one catalog controller ships with the VM6200Pro license included:

Keep the stations independent instead by using smart cameras: each camera decides its own pass or fail and reports result plus capture position to the node that owns the stop, which runs the same binned merge on incoming messages. The camera finder filters by shutter type and interface — on a belt that never stops for photos, set the global-shutter filter. Two catalog stations cover the common ends of the range, a 5 MP color sensor for detail work and a 1.6 MP mono sensor for presence checks:

Table memory is trivial at either architecture: a thousand bins at four flags plus two 32-bit reals is about 12 kB, so the merge fits wherever the stop output already lives. Where the PLC owns tracking from the ground up, a high-speed-counter approach to conveyor tracking with camera triggers shows the encoder side done entirely in the controller.

When should you key records by part number instead of position?

Key the table by a sequence number instead of position when parts run closer than ten bins apart, when a photo-eye trigger adds more jitter than half a bin, or when the belt reverses — assign an ID at the entry sensor and let position ride as data. The sequence table is smaller and immune to quantization: the entry sensor numbers parts as they pass, each station writes its flag into record N, and the stop uses the position stored with that same record.

On the worked line the tracking window is 550 mm of stop distance plus a 250 mm pitch — 800 mm of belt — so three or four records cover every part in flight. Belt reversal and trigger bounce stop being position problems at all, because the merge rides on the ID, and the quantization step drops out of the code entirely.

The decision, case by case:

• Servo index belt, parts at 250 mm pitch, repeatability ±0.1 mm: one position-binned table, 1 mm bins, one record and one stop per part.
• Parts closer than ten bins, a reversing belt, or a bouncing photo-eye: sequence-number records assigned at the entry sensor.
• Smart-camera stations reporting over sockets: merge at whichever node owns the stop output, bins included.

Before you order, run four checks: teach all four stop distances on one golden part and re-check after any mechanical change; log raw sums beside bin keys for the first week, where a split-record symptom shows up first; replay 1,000 parts of station logs offline and confirm the merge stops once per bad part, never twice; and fire the rollover case on the bench. If you are consolidating four stations onto one chassis, send the station count, pitch and repeatability through the quote form and we will size the controller and the table with you; the conveyor-side patterns on the systems topic page cover the rest of the line.