Gate vision picking with an upstream reject signal

An upstream inspection has already judged every part before it reaches your camera: one digital line says accept or reject, and you want the robot to place the good parts while the rejected ones pass by — but keep their slots in the container empty, so the box pattern still matches the inspection record. The camera may see one part, several parts, or none in a frame, and the line state applies to the whole frame. The design that works is a per-frame gate: latch the line into the frame at trigger time, carry one accept/reject bit with every pick record, and branch at the place pointer. This guide gives the wiring, the queue logic, the timing arithmetic and a half-day prove-out.

When should the reject line be read: at trigger or at pick?

Latch the line state at the instant the camera trigger fires and freeze it into the frame's metadata, because at conveyor speeds the verdict is 2 to 4 s stale by pick time and a live read there gates the wrong part.

The upstream controller owns a verdict only while the part it measured is the part in front of your camera. By the time that part reaches the robot, the line may already describe the part behind it, so sampling at the pick point shifts every decision by one item. Latching at trigger ties the verdict to a frame, and the frame counter is the one name the camera and the robot both know.

Treat the latched bit as part of the image. A frame returns zero, one or several parts, and the single bit applies to every part in that frame — exactly the contract the upstream line offers, so honor it at frame level and never split it per item. If the line or trigger source needs configuration first, the GenICam line settings in hardware trigger source not detected: check the line configuration cover LineSource and LineSelector; if one trigger must produce several images, see multi-image capture per trigger.

Where does the input line physically land?

Land it on the camera's own opto-isolated input — Line 0 or Line 1 in GenICam terms — so the verdict reaches the software as chunk data inside the same frame that shows the parts.

Three landing places work:

• On the camera. Select the line, enable chunk data for line status and frame counter, and the camera stamps the verdict into the frame header itself. No PLC scan can flip it afterwards.
• On a smart camera. Smart cameras and vision sensors with on-device logic read their own digital input, apply the gate and run the pick queue without a PC:

The LS-SMC-0063 carries its own 16 mm lens and white light, so the gate, the optics and the illumination arrive as one unit. The LS-SMC-0017 is an 8.8 MP model with a global shutter and a C-mount, for cells where you choose the lens.

• On the acquisition side. A frame grabber or PoE NIC powers the camera and gives the frames a stable pipe:

Wiring rules: take the common convention — low = accept, high = reject — and document your polarity on the commissioning sheet. Set the input debounce to 1–5 ms so connector chatter never toggles a verdict. Keep the camera and the trigger eye on a single rigid structure; a camera stand with a slide table lets you trim the latch geometry by hand:

The LS-MNT-0040 stands 700 mm tall on a 400 x 450 mm base with a slide-table top. Stands and cards browse together in the accessories finder; vision sensors also surface in the camera finder.

For the robot-side handshakes that carry the queue acknowledgements, this robot digital-in and digital-out wiring guide for multi-part picking covers the same pattern at the controller.

How does the flag travel from the frame to the robot?

Stamp one gate bit and the frame counter into every detection record at vision time — frame 4821, item 2, x 96.4 mm, y 12.0 mm, angle 8.5°, reject true — and never let the robot query the live line again.

Write the record before detection touches the image: latch line state, frame counter and timestamp into the frame object, then run the finder. Each detection inherits the frame's gate bit and an item index in a fixed scan order that matches belt arrival. Push the records to the pick queue in that order. The queue is a FIFO; a priority rewrite is how the slot pattern stops matching the inspection log.

The robot pops one record at a time and acknowledges the frame when its items are done. That handshake is the one behind vision queue conveyor speed control, with the gate bit riding along.

How is a place slot reserved for a skipped item?

Advance the place pointer for every detection, accepted or rejected, and branch only on the motion: rejected entries move the pointer and skip the robot, so the container holds one empty slot per rejected part.

The place routine gains one branch and nothing else:

• Accept record → approach, pick, place at slot n, then advance n.
• Reject record → advance n with no motion, and log the reserved slot against its frame id.

A 4 x 6 container receiving accept, accept, reject, accept finishes with slot 3 empty and the fourth part in slot 4. The box pattern and the upstream record stay one-to-one, which is the entire point of reserving instead of closing the gap. If a downstream station cannot tolerate an underfilled box, fill the slot from a later good part, keep a parallel expected-empty list and log the substitution; the default is the empty slot.

The cousin design — pushing rejects physically off the line instead of reserving slots — is covered in single camera inspection routing to a robot and reject pusher. Vendor picking tools meet the identical queue problem, as in this walkthrough of rejecting a queued part without picking it.

How do I build it, step by step?

Budget half a day: two hours for wiring and line configuration, an hour for the queue change, the rest for a 20-part prove-out with a hand-toggled reject switch.

1. Wire the upstream verdict into the chosen input with the polarity documented — low = accept, high = reject — and set the debounce to 1–5 ms.
2. Select that line and enable chunk data for line status and frame counter; confirm the frame trigger still fires on its own line.
3. In the frame handler, latch line state, frame counter and timestamp into the frame record before detection runs.
4. Run detection and emit one record per item: frame id, item index, x, y, angle, gate bit.
5. Push the records in scan order to the pick queue and treat the queue as read-only everywhere else.
6. On the robot: accept → pick and place at slot n; reject → advance n with no motion and log the reserved slot.
7. Add the alarm rule: ten consecutive rejects pause the feed and flag the input line.
8. Log every record — frame id, gate, slot, result — so any container can be reconstructed from the log alone.

How much time does the gate have to react?

At 250 mm/s with the camera 900 mm upstream of the pick point you have 3.6 s of queue travel, and the verdict only needs to be stable for the ten milliseconds around the trigger edge.

The timing chain:

Worked example on a 250 mm/s belt:

• Upstream inspector 600 mm before the camera: 600 / 250 = 2.4 s of verdict lead time before the trigger. You demand 10 ms of stability at the edge and have 240 times that.
• Camera 900 mm before the pick point: 900 / 250 = 3.6 s in the queue.
• One frame per 400 mm of belt: 400 / 250 = 1.6 s per frame, so 3.6 / 1.6 = 2.25 → 3 frames in flight; queue depth 6, or 8 if the robot pauses mid-cycle.
• Exposure 500 µs is irrelevant to the race: the latch happens on the trigger edge, before integration starts.
• Resolution check for the pose: a 400 mm field of view on a 5 MP sensor (2448 px across) gives 400 / 2448 = 0.163 mm per pixel, so a 30 mm part spans 30 / 0.163 ≈ 184 px — well past the roughly 50 px a pickable pose wants.

If the upstream verdict needs longer than that lead time to settle, the fix is geometry, not software — see the last section.

How do I prove the gate before production?

Run 20 known parts with the reject switch toggled per frame — 10 accept, 10 reject, mixed with empty frames — and require 20 out of 20 correct slot patterns before release.

• Single rejects between accepts: the box shows isolated empties in the right positions.
• A two-part reject frame: both parts skipped, two adjacent slots reserved.
• Back-to-back reject frames: the place pointer advances without starving the queue.
• Pull the input connector mid-run: latched rejects, feed stop after ten.
• Toggle the line 50 ms after a trigger edge: the frame keeps its latched value and the mismatch counter increments.
• Photograph each container and diff it against the expected pattern; keep the photos with the commissioning sheet.

What usually goes wrong?

Four faults cover most failed gates: reading the line at pick time, inverting the accept/reject polarity, dropping the flag on multi-item frames, and a PLC scan that flips the line between trigger and latch.

• Off-by-one gating. Alternating verdicts expose it instantly: the box pattern lands shifted one part against the upstream log. The fix is the trigger-edge latch, always.
• Inverted polarity. Swap the active level in the line configuration, not in the wiring, and record the change. Re-test after any upstream firmware update.
• One flag for the first item only. The bit belongs to the frame, so every item in a multi-part frame carries it. The two-part reject test catches this in one run.
• PLC scan race. A scan of a few milliseconds can flip the line between the trigger and any later software read. Chunk-data latching at the edge removes the window; ask the upstream controller to hold each verdict stable until your per-frame acknowledgement.
• Queue keys colliding after a reconnect. A camera reboot resets the frame counter; re-key the queue on reconnect before resuming.

If your frame pitch comes from an encoder pulse train, the rate limits in camera hardware trigger frame rate with external pulses apply to the latch cadence as well.

When is frame-level gating the wrong design?

Frame-level gating is wrong the moment one frame can hold both accepted and rejected items, or the upstream verdict lands after the camera trigger; in both cases track items individually with an encoder-keyed FIFO instead.

Decide by case:

• Mixed verdicts in one frame. The upstream line must carry per-part verdicts in arrival order. Key the queue to encoder counts, latch one verdict per part as it crosses a fixed mark, and let the frame do only the measuring.
• Verdict arrives after the trigger. Move the camera downstream of the inspector by at least belt speed × (verdict time + 0.5 s margin): at 250 mm/s and a 200 ms verdict that is 0.7 × 250 = 175 mm. If the camera cannot move, gate at a second latch point just upstream of the pick, keyed the same way.
• Per-lot, not per-part verdicts. A sampling plan upstream says nothing about the individual part in front of you. Gate whole lots — latch a lot flag, route the container — and leave slot reservation out of it.
• No verdict line at all. Then there is no gate; add the upstream output before building queue logic that guesses.

For where the camera and latch point should sit relative to the robot, conveyor tracking camera placement relative to the robot works the geometry, and 2D vision pick and place: selecting a planar guidance system frames the wider cell design.

Start at the trigger step of the system configurator to fix the camera input and line, or send your belt speed, verdict timing and container pattern through the contact page and we will lay out the latch point and queue depth with you.