Barcode verification before picking with multiple robots

A downstream barcode reader can confirm an item detected upstream, but only if the control system preserves that item's identity between stations. A successful decode alone does not establish which tracked object was read or which robot may pick it. For conveyor integrators, the practical task is to build a transaction connecting detection, reader trigger, verification and robot assignment. This approach lets you reject late, duplicated or ambiguous results before they authorize the wrong pick.

Make verification an item-specific decision

Use a separate verification transaction for each physical item. Do not connect a reader's general good-read output directly to a shared pick-enable signal. That signal can remain active while another item enters the station, or arrive after the robot assignment changes.

The decision should require all of these conditions:

• The tracked item still exists and its position estimate remains valid.
• The barcode result belongs to that item's scan transaction.
• The decoded identity matches the permitted product or order rule.
• The result arrived before the transaction deadline.
• The current robot assignment matches the pick request.
• The authorization has not expired or already been consumed.

Treat this as a process permissive, not a safety-rated function. Guarding, emergency stops and other protective functions need an independent, appropriately designed safety system. Barcode acceptance must never override them.

This article addresses identity and authorization before motion. The separate guide to visual servoing loop design covers the different problem of correcting motion from vision feedback.

Define the identity and message contract first

Create an internal item ID when the upstream detection becomes an accepted track. Keep that ID separate from the barcode payload: two physical packages can carry the same product code.

A useful transaction record contains:

The expected identity might be a product identifier from the production order or a unique serial identifier from a trusted upstream record. State that rule explicitly. A decoder reporting valid syntax is not equivalent to confirming the required identity.

Use the reader's documented result-correlation mechanism where available. If it cannot return a transaction identifier, the integration needs another unambiguous method, such as one outstanding trigger per reader with bounded result timing. Confirm that behavior before choosing hardware.

Track position using conveyor travel

For a straight conveyor with a suitable encoder reference, estimate position from encoder displacement rather than elapsed time alone. A basic model is:

For example, a displacement of 2,400 counts at 0.1 mm/count represents 240 mm of conveyor travel. Add that displacement to the original detection position to predict arrival at the reader.

This model assumes the object follows the measured conveyor motion. Belt slip, rolling packages, transfers and accumulation can break that assumption. Establish an error allowance through measurements at the actual scan station, including the most difficult packaging and speed changes.

An upstream MV-DPS200P-02 is a projected structured-light 3D camera candidate. Confirm its detection output, coordinate conventions and acquisition timing before designing the tracking interface.

Browse 3D sensors for the sensing role, but do not assume that a sensor-generated object label remains stable across frames. The tracking layer must define how repeated detections become one item record.

Associate the scan with one physical item

At each reader, predict when the tracked item enters a validated reading zone. Open a scan transaction for that item, record the trigger sequence, and accept results only within that transaction's bounds.

The reading zone must make physical association credible. A reader can decode a perfectly valid label on a neighboring package. A trigger sequence proves which acquisition produced the result; it does not, by itself, prove which package supplied the barcode.

Use controlled presentation, restricted field of view or documented position-resolved decoding when nearby labels could appear together. If two tracked items could plausibly produce the result, mark the association ambiguous rather than selecting the nearest prediction without validation.

The LS-RS100-12 is an Ethernet fixed code reader candidate. Check its documented trigger handling, result framing and correlation capabilities against the transaction requirements.

The fixed code readers category and camera and reader finder help shortlist hardware. Interface compatibility is only the first filter; result association and bounded behavior determine whether the integration works.

For the software receiving side, see barcode scanner data capture in an application. Message framing and application-level acceptance still matter after a reader decodes successfully.

Calculate the deadline from the available travel

The result must be verified early enough for the assigned robot to accept or reject the transaction before its last valid pick-entry boundary. Calculate that boundary from the actual cell geometry and documented robot interface behavior.

At constant conveyor speed, a first timing estimate is:

Suppose the scan reference is 400 mm upstream of the last pick-entry boundary, and conveyor speed is 500 mm/s:

These are application assumptions, not specifications for any listed product. Replace them with validated upper bounds, including reader retries, message queues and controller scheduling delays. Average latency is insufficient for a deadline decision.

With acceleration or changing speed, use a conservative earliest-arrival prediction instead of the constant-speed estimate. Include position uncertainty in the boundary calculation. If the operating conditions exceed the validated envelope, withhold the permissive.

The guide to camera triggering with external pulses helps distinguish trigger arrival from completed acquisition. Add decoding, transport and handshake time separately.

Use a state machine instead of independent bits

Keep one authoritative transaction state, with explicit transitions. Several unrelated Boolean flags can accidentally describe an impossible combination, such as verified and expired at the same time.

A transaction can also require cancellation when tracking becomes invalid or ownership changes. Define those transitions before writing the normal sequence.

Perform the final validity checks atomically in the coordinator: item ID, run epoch, assignment revision, state, deadline and token-consumption status must agree at the decision point. If separate tasks update those values independently, use synchronization that prevents a mixed snapshot.

Retain rejected messages in the diagnostic log, but do not let them modify an active record with a different transaction key.

Bind authorization to the assigned robot

For multiple robots, reservation and verification must refer to the same assignment revision. A shared verified queue without ownership control can let two robots claim the same object.

An authorization should identify the item, run epoch, assigned robot, assignment revision, validity limit and unique pick token. The robot interface must check the fields it receives and return an acknowledgement identifying the same transaction. Establish these semantics through the supported robot-controller interface; do not assume a generic input bit carries them.

If ownership changes, cancel the old authorization and advance the assignment revision. A delayed acknowledgement from the previous robot must not complete the new assignment. Reuse a previous identity observation only when the design explicitly permits it and the physical track remains unambiguous.

The MV-SVC2506-16G60-128G is a vision controller candidate. Confirm that the selected software and communication interfaces support the required coordination logic.

Compare vision controllers by the complete integration requirements, not simply their available camera connections. Also define recovery for an acknowledgement lost after a request was accepted: a retry must not create a second physical pick request.

Define no-read, mismatch and communication failures separately

A no-read means the reader did not provide an acceptable decode for the transaction. A mismatch means it decoded an identity that the acceptance rule rejects. An ambiguous association means the payload cannot be confidently attached to the tracked item. These are different diagnostic outcomes, even when all inhibit picking.

Choose a defined response for each outcome: allow the item to pass unpicked, route it to an independently validated reject path, or request a controlled production stop. The correct response depends on cell mechanics and the production requirements. Do not substitute a previously accepted barcode or a general good-read latch.

Bound retries by both count and remaining travel. Every retry must remain tied to the original item and must leave sufficient time for the final decision. If the remaining window is too short, expire the transaction rather than extending its deadline.

A reader disconnection should close affected pending scans. Encoder discontinuity or lost tracking may require invalidating all affected items. After a controller restart, create a new run epoch and prevent buffered results from the previous run from being accepted.

For tightly controlled production, barcode matching is one process control, not evidence by itself that the complete application meets traceability or regulatory requirements.

Check the integration before ordering

Select the sensor, reader and coordinator around a written message contract. Ask for documented answers to these questions:

• Does the sensor provide enough timing and coordinate information to establish conveyor tracks?
• Can the reader associate results with triggers, and how does it report no-read or multiple-code conditions?
• Are result buffering, reconnection behavior and message delimiters documented?
• Can the coordinator maintain item ownership and transactional state under concurrent events?
• Does the robot interface support item-specific acceptance, cancellation and acknowledgement?

The LS-R172-S1 is a USB-interface reader candidate. Its interface alone does not establish whether the required transaction information is available.

A keyboard-style data stream may be convenient for manual entry but insufficient for unattended multi-item coordination. Confirm the documented operating mode and receiving-software behavior rather than inferring capabilities from the connector.

The usual upstream-detection, downstream-reading arrangement is wrong when objects can exchange order, leave the tracked belt, or accumulate without individual tracking. In those cases, move identification earlier, add a re-identification station, or change the mechanical presentation. Software cannot recover certainty from an observation that never distinguished the objects.

Commission with deliberate transaction faults

Test the identity chain independently from the final pick, using the documented commissioning mode and approved safety procedures. Start with a simulated robot acceptance endpoint where practical, then validate the complete sequence under the cell's commissioning plan.

Use this checklist to challenge the design:

• Send the same reader result twice. Only the first valid result may affect the transaction.
• Delay a correct result beyond its deadline. It must remain rejected.
• Place identical product codes on adjacent packages. Internal item IDs must remain distinct.
• Present two readable labels together. An uncertain association must not authorize either item.
• Reassign an item while a scan or acknowledgement is pending. The old assignment must lose authority.
• Disconnect and reconnect the reader with buffered messages present. Previous transactions must not revive.
• Stop, accelerate and reverse the conveyor where those operating modes are permitted. Position tracking must remain valid or explicitly invalidate affected items.
• Restart the coordinator with pending work. Old epochs and authorizations must be rejected.
• Drop a pick acknowledgement and retry the message. The transaction must not be consumed twice.

Log the item key, encoder reference, trigger sequence, decoded payload, state transitions, assignment revision and rejection reason. Use coordinator-side monotonic timing for local deadlines; compare timestamps across devices only when synchronization and its error bounds are established.

Repeat these tests after relevant software changes using the software upgrade validation checklist. Record the permitted operating envelope, including speed, spacing and tracking uncertainty.

Before selecting parts, send the station layout, timing budget and message contract through applications support. The next step is to confirm that each interface supports the transaction—not merely that each device can detect, decode or move an item independently.