Conveyor tracking with vision instead of a sync switch

A synchronization switch tells a conveyor-tracking controller where the belt is. It cannot tell the robot which part is coming, where it sits across the belt, or at what angle. An upstream camera answers all three, which is why integrators replace the switch with vision. The swap raises one hard question: how do measured coordinates enter the tracking queue while the belt keeps moving? The working answer is to trigger the camera from the belt encoder, attach the capture count to every measurement, and let the queue transform stored coordinates as the belt advances. This guide gives the sizing arithmetic, the calibration into the conveyor frame, the socket message, the controller settings and the checks to run before the first production pick.

What the sync switch does — and what the camera replaces

Two signals run any tracking line. The encoder interface counts belt travel continuously and reports the conveyor position relative to the synchronization switch input, together with the queue tracking distance — the window in which the robot may pick. The conveyor tracking option itself installs a conveyor work area into the controller configuration, which is where the system parameters live. The switch contributes only a reference edge: position zero, or the announcement that a part has arrived. Wire the camera's exposure output to that same reference input and the physical switch disappears while the encoder, the input and the configuration all stay.

The decision: keep the encoder interface exactly as it is and give the camera the switch's job. If the interlocks live in a safety-rated PLC instead of the robot controller, choosing a sync method for conveyor tracking is its own documented decision on that controller family.

The one rule: queue the capture count, not the receive time

The queue stays accurate only if each stored coordinate is tied to the belt position at the moment of capture. The encoder count at exposure is exact. The count at the moment the robot receives the message is not, because detection, encoding and socket transfer add tens to hundreds of milliseconds:

At 300 mm/s, an 80 ms delay puts the part 24 mm from where the robot thinks it sits: 300 × 0.08 = 24 mm. Processing jitter of ±20 ms moves it ±6 mm more. Trigger captures from encoder counts and the delay stops mattering: a part identified two seconds later still enters the queue at its capture position. If you cannot encoder-trigger, measure the total latency once per belt speed and subtract it — workable, but every jitter reappears as position error.

When vision results and live robot data arrive out of order, matching them is its own problem; asynchronous vision result frame matching with timestamps shows the matching scheme, and camera timestamp clock rollover and monotonic time mapping applies on the vision side.

Worked example: size the camera for the belt

Take one plausible line and redo the arithmetic with yours: belt 300 mm/s (18 m/min), belt width 240 mm, pick tolerance ±0.5 mm, parts presented flat with their top face 20 mm above the calibration plate, camera looking straight down from a 600 mm working distance.

Pixels first. A location tolerance of ±0.5 mm wants a pixel no larger than a fifth of it, 0.1 mm/px. Across a 250 mm field (240 mm belt plus margin) that is 250 / 0.1 = 2,500 px. A 12 MP, 4:3 sensor with 3.45 µm pixels reads 4,096 px across — clear of the requirement — and its width is 4,096 × 3.45 µm ≈ 14.1 mm.

Focal length next. Field of view, working distance and sensor width fix it: f = WD × sensor width / FOV, so f ≤ 600 × 14.1 / 250 = 33.8 mm. The nearest standard shorter focal length is 28 mm, which gives FOV = 600 × 14.1 / 28 ≈ 302 mm and a pixel of 302 / 4,096 ≈ 0.074 mm/px — half the budget.

Exposure last. Blur is speed × exposure; keep it under half the tolerance. Exposure ≤ 0.2 / 0.3 mm/ms = 0.67 ms, so set 0.5 ms: blur = 300 × 0.0005 = 0.15 mm. Half a millisecond needs a strobed LED light driven hard for the pulse; a continuous lamp will not hold contrast there. The exposure time vs shutter speed for moving-part inspection trade is worked through separately.

Use a global shutter. A rolling sensor reads its rows over roughly 10 ms, and at 300 mm/s the image skews 0.3 × 10 = 3 mm between first and last row, carrying every measured angle with it.

Both cards below are global-shutter cameras; the higher-resolution one carries the worked example, the other suits narrower windows where a single part fills the frame.

Calibrate the camera into the conveyor frame

Pixels become belt millimetres through one calibration capture. Bolt a flat plate to the belt with two marks 200 mm apart along the belt and one mark 100 mm across it. One frame yields scale in px/mm, the rotation between camera axes and belt axes, and the offset. Store the transform and map every detection through it before sending. Verify by placing a part on a known mark and requiring the reported position to land within 0.2 mm; the locating pipeline is the same as robot vision for locating part center points.

Height is the error that bites. A feature above the calibration plate images farther from centre than it truly is:

With the example numbers, H = 600 mm, h = 20 mm, r = 100 mm: 100 × 600 / 580 − 100 = 3.4 mm outboard. Three fixes in order of cost: calibrate at the height the robot grips (the part's top face), double the working distance — at 1,200 mm the same feature shifts 100 × 1200 / 1180 − 100 = 1.7 mm — or fit a telecentric lens, which removes the perspective term for small fields.

Check that the belt direction lies exactly along the calibrated axis; a skewed camera adds a sine error that grows with cross-belt position. Later, a growing gap between predicted and actual part positions means the encoder is slipping on its roller — conveyor encoder calibration troubleshooting: position resets covers that diagnosis.

Trigger the capture from the encoder

Scale the encoder first. A 2,048-count incremental encoder on a drive roller with 200 mm circumference gives 2048 / 200 = 10.24 counts/mm; fire the camera every 205 counts, which is 20 mm of belt. At 300 mm/s that is 300 / 20 = 15 captures per second, so exposure plus readout plus detection must fit inside 66 ms. If detection takes 80 ms, either double the interval to 40 mm — the 302 mm field still covers every part many times over — or crop the image to the region that matters and get detection under budget.

Trigger in hardware: the encoder interface or a controller digital output drives the camera's external trigger input, never a software timer. A hardware trigger grab loop in Python: acquire and save each frame shows the pattern, and why encoder-triggered image capture drops images at high RPM explains the ceiling you hit as speed rises. Keep straight which timestamp belongs to the exposure and which to trigger reception; trigger call versus exposure time: understand capture timing separates the two. Where two cameras split a wide belt, trigger both from the same count so their capture positions are identical — hardware sync two USB cameras: trigger both cameras together shows the wiring.

The socket message: pose plus capture count

Four fields, nothing less: a sequence number, x and y in calibrated belt millimetres, the angle in degrees, and the encoder count at exposure. One ASCII line keeps the whole chain debuggable from any terminal:

P,1043,132.4,-58.7,3.2,418816

That reads: message type P, sequence 1043, x = 132.4 mm, y = -58.7 mm, angle = 3.2 degrees, capture count 418816. Send counts as unsigned integers, and if the counter wraps at 32 bits compute deltas with unsigned wraparound, never raw subtraction. Agree the rotation sign and axis convention in writing before integration; a mirrored y or an inverted angle stalls more commissioning days than any camera setting. The framing, reconnection and retry logic around this message are covered in send camera part coordinates to a robot controller over TCP, and the connected-but-silent fault has its own fix in robot socket communication: no response, fix the send loop. Add a checksum once the basics work, and log every line on both sides with receive times.

Configure the controller and feed the queue

In the conveyor work area of the system parameters, set at minimum: the encoder unit's counts per millimetre (10.24 here), the reference input source, the start window, the queue tracking distance and the maximum queue depth. The reference input — the terminal where the sync switch used to land — now takes the camera exposure pulse, so the reference edge and the capture share one count. On the bench, force that input from the controller's I/O simulation instead of wiring it; conveyor tracking configuration for two vision-guided lines shows how the work areas multiply when one controller serves more than one line.

Size the window from the numbers. Parts every 350 mm of belt, pick cycle 2.5 s: a part travels 300 × 2.5 = 750 mm while the robot works, so the window needs one pitch plus that travel, 350 + 750 = 1,100 mm — set 1,500 mm. Depth: 1500 / 350 = 4.3, so four parts fit. Mount the camera 900 mm before the window start: 900 / 300 = 3 s of queue lead before any part becomes pickable.

On each receive, add the part to a FIFO held in capture order; each robot takes the oldest part that has entered the window. The FIFO versus shift-register queue question for conveyor vision tracking in a PLC is documented on the PLC side. Two robots on one belt share the encoder interface and split one queue — conveyor encoder sharing for multi-robot vision picking shows the wiring — and queue behaviour under varying belt speed is covered in vision queue conveyor speed control for continuous picking. Each robot family exposes these pieces differently; a teach-pendant walkthrough for conveyor picking vision tracking shows one full sequence on the robot side.

The controller running detection, strobing the light and holding the robot link needs several Ethernet ports, USB 3 for I/O devices and built-in light channels for the strobe.

Filter the range by LAN ports, memory and light outputs in the vision controllers category.

Checks before the first production pick

Run these with real parts before releasing the line:

1. Static position: belt stopped, part on a marked spot; the reported position must land within 0.2 mm.
2. Moving accuracy: single parts at production speed, five positions across the window; pick offset under a third of tolerance, 0.17 mm on the example.
3. Latency proof: log capture and receive times. With receive-time queueing the offset grows with delay — 24 mm at 80 ms — with capture-count queueing it does not move.
4. Window edges: a part captured at the window start picks cleanly; a part near the far end is still reachable. Widen the queue tracking distance if not.
5. Missed capture: block the camera mid-run. No queue entry, belt continues, downstream watchdog faults. Camera disconnects should fail fast instead of freezing the line, as GigE camera disconnected detection: fail fast instead of freezing shows.
6. Reversal: jog the belt back 100 mm and forward with parts queued; every pick must still land. Delta arithmetic on counts survives reversal, receive-time logic does not.
7. Slippage: run 30 minutes at speed; the predicted-versus-actual offset stays flat. A growing offset is encoder slip.

Burst arrivals that overflow the queue show up as cycle-time losses; conveyor target availability: diagnose cycle-time losses helps pin them down.

When vision-only tracking is the wrong tool

Keep a presence sensor beside the camera when parts are shiny, black, overlapping or inconsistently presented: the sensor triggers, the camera locates, and neither has to do the other's job — the photoelectric sensors category is the place to start. Parts that arrive touching are a singulation problem no queue can fix; space them upstream. If the task shrinks to stopping the robot unless a part sits at the pick point, the switch plus a gate signal is cheaper, and the camera earns its cost only when pose matters. When the pick also needs part height, stack depth or top-surface geometry, that is a 3D decision — 2D or 3D camera for conveyor pick and place: choosing the system lays out the trade.

The decision in numbers

For the worked line — 300 mm/s belt, 240 mm wide, ±0.5 mm tolerance — the decision reads: 12 MP global-shutter camera, 28 mm lens at a 600 mm working distance giving a 302 mm field at 0.074 mm/px, 0.5 ms strobed exposure, capture every 205 encoder counts (20 mm), pose plus capture count over the socket, 1,500 mm tracking window, queue depth four, camera mounted 900 mm upstream for 3 s of queue lead. Re-run the four formulas with your belt speed, width and tolerance — pixels across, focal length, exposure, window length — and the same decision falls out with your numbers.

Size the camera in the area scan cameras category or the camera finder, pick the controller from the vision controllers category, and if you send us the belt speed, part and tolerance, the numbers come back filled in through the contact page. The applications topic page collects the rest of the conveyor integration guides.