One camera, two answers: which part is this, and where is its pick point? A barcode read delivers the first reliably and the second only to a few millimeters. This guide puts numbers on that. You get the x and y accuracy to expect from locating a part by its 1D code, the source of each error term, the pick tolerance a code-driven position can support, and the change that gets millimeter picks from the same image: locate a taught geometric feature for the pose, and let the code carry the ID.
Can a barcode read locate a part for robot picking?
Yes — a code read returns the identity and a coarse position in one image, roughly ±2 mm in x and ±5 mm in y for a hand-applied 30 × 10 mm label, which steers a drop into an open bin but cannot close a gripper on the part.
Every code reader outputs three things per read: the decoded string, the symbol position in image coordinates, and its angle. Calibrated into the robot frame, that position becomes a motion target. The catch is that the two coordinates are not equally trustworthy, and the gap decides your architecture: one device or two, code-driven motion or feature-driven motion. For the workflow itself, locating the part and reading its barcode in one image covers the image and ROI arrangement, and one camera for both pick-and-place and barcode scanning shows the full cell built around it.
A station like this can be a single compact device. The MV-ID3013PM-12M-WBN is a compact industrial code reader with a 12 mm focal length, 1.3 MP resolution and a global shutter on Fast Ethernet.
- Interface
- Fast Ethernet
- Resolution
- Up to 3 MP
- Shutter
- Global
- Lens mount
- M12
How accurate are the x and y coordinates from a 1D code read?
The two axes differ by a factor of about 40 in this budget: x comes from bar edges measured to about 2 pixels, ±0.12 mm at a 0.062 mm/px scale, while y is inferred from where the bars start and end, about ±5 mm on a 10 mm tall symbol.
The asymmetry has a mechanical cause. Decoding measures transitions along the bar direction, so every bar edge is an edge measurement averaged over the bar height — subpixel work, and a 2-pixel budget at your scale is conservative. Nothing in a 1D symbol carries information along its height. The decoder reports a region whose ends are set by where the bars stopped, and threshold, focus and tilt move those stops by a visible slice of the symbol height. Budget half the symbol height for the y datum. The consequence is not intuitive: a taller code is worse, because it moves the y datum further.
Why is the pick offset when the code reads fine every time?
Because the dominant term is usually not the decoder but the label: a hand-applied label lands within about ±2 mm of its intended spot on the part, and calibration removes only the mean offset between code and part, not the part-to-part variation.
Calibration is still worth doing — it deletes the fixed offset between symbol center and pick point. What survives is placement variance, and it enters both axes. Combine the terms as root-sum-square:
Budget the placement step at ±2 mm by hand and ±0.5 mm from a labeler, and substitute your own measured values when you have them. For the hand-applied case at the 0.062 mm/px scale from the worked example below:
| Error term | x | y |
|---|---|---|
| Bar-edge centroid, 2 px at 0.062 mm/px | ±0.12 mm | – |
| Bar-end datum, half of a 10 mm symbol | – | ±5.0 mm |
| Label placement, hand-applied | ±2.0 mm | ±2.0 mm |
| Combined (RSS) | ±2.0 mm | ±5.4 mm |
The arithmetic: sqrt(0.12² + 2.0²) = 2.0 mm in x, and sqrt(5.0² + 2.0²) = 5.4 mm in y. Even a ±0.5 mm labeler leaves y at sqrt(5.0² + 0.5²) = 5.0 mm, because the bar-end datum, not the label, owns that axis.
How much pick tolerance can code-based locating support?
Apply the rule of thirds — keep the locating error under a third of the pick tolerance — and this budget supports about ±6 mm of tolerance in x and about ±16 mm in y: drop-into-bin processes, not gripper picks.
The other two thirds belong to the robot, the gripper and the fixturing, so the rule is not stingy bookkeeping. Code-driven motion genuinely works for drops into open bins, kitting into generous nests, and choosing which of several bins to approach. It fails for ±2 mm class work: assembly, insertion, machine tending.
Worked example: a 40 mm roller picked from a tray
- Part: 40 mm roller, Code 128 label 30 mm wide × 10 mm tall, hand-applied; wanted pick tolerance ±1 mm.
- Field of view 160 mm wide over a 2592-pixel sensor: scale = 160 / 2592 = 0.062 mm/px.
- Decoder terms: x = 2 px × 0.062 = ±0.12 mm; y datum = 10 / 2 = ±5.0 mm; label = ±2.0 mm.
- Totals: x = sqrt(0.12² + 2.0²) = ±2.0 mm; y = sqrt(5.0² + 2.0²) = ±5.4 mm.
- Thirds-rule tolerances: x ≥ ±6 mm, y ≥ ±16 mm. The ±1 mm pick falls far short in y — the code cannot feed it.
- Same image, geometric route: fit the 40 mm circle silhouette to ±0.12 mm in both axes, which supports 3 × 0.12 = ±0.36 mm — the ±1 mm pick passes with margin.
- Decision: the read stays for the ID; the circle drives the pick.
How do you get millimeter pick accuracy and still read the code?
Locate a geometric feature for the pose and let the code carry only the ID: fit the part's circle or rectangle edge to about ±0.12 mm in both axes at this pixel scale, then read the code inside the located region — one image, one camera, millimeter picks.
Order matters. Locate first, then constrain the code ROI to the found region; that also guarantees the ID belongs to the part you are about to grip rather than to a neighbor in the tray. A circle or rectangle fit averages dozens of edge points, so it is more accurate than the code and isotropic — the error no longer depends on which axis you inspect. Estimating edge position accuracy from image sampling gives the math for the fit, parametric teach for geometric parts shows how to teach the circle quickly, and the feasibility checklist tells you before you start whether the part offers a teachable feature at all.
For a ±1 mm pick, keep the pixel scale at or below about 0.1 mm/px, so a 2-pixel edge fit stays under the ±0.33 mm locating share that the thirds rule leaves.
On a device, this is exactly what a smart camera is for. The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with an 8 mm focal length on an M12 mount, sized to run the locate and the decode in one cycle without a PC.
- Interface
- GigE
- Resolution
- 6-10 MP
- Sensor format
- 1/2.4"
- Shutter
- Rolling
Would a 2D code fix the position problem?
Sometimes, and it is often the cheapest fix: a DataMatrix or QR symbol carries position in both axes through its finder patterns, which removes the ±5 mm bar-end term, while label placement still caps the result near ±2 mm.
Re-run the budget with a 10 mm DataMatrix: both axes become sqrt(0.12² + 2.0²) = ±2.0 mm with a hand-applied label, and sqrt(0.12² + 0.5²) = ±0.5 mm from a labeler. That labeler case passes the thirds rule for a ±1.5 mm tolerance, so code-only locating closes on millimeter work when the placement process is good. The 2D symbol also brings error correction, so it survives print damage that kills a linear code. The costs are a new label design, print quality control, and decoder configuration for the new symbology; when the software then refuses to see the new codes, fixing a QR code the vision software will not detect is the first stop.
Do you need a code reader or a smart camera?
A fixed code reader is the right tool when the ID is the product and the position only steers a drop; add a smart camera when the same device must find a part edge and drive the pick itself.
By case:
- ID plus coarse placement — bin drops, tote scans at induction: a fixed code reader is the whole station. When the label is small but the tray is wide, spend pixels on scale: the MV-ID5120RM-08M-RBN reads at 12 MP over GigE, which keeps the pixel scale fine across a large field of view.
- Interface
- GigE
- Resolution
- 12 MP
- Shutter
- Rolling
- Lens mount
- M12
- ID plus millimeter pick, no PC — a smart camera running locate and decode on the device, as in the card above.
- Shiny or curved parts — glare beats the decoder before geometry does. The MV-IDB005EXI-05NRP is a polarized code reader with a 4.63 mm focal length and a 70 mm focus distance, made for codes on reflective surfaces at short range.
- Interface
- Fast Ethernet
- Resolution
- Up to 3 MP
- Shutter
- Global
- Lens mount
- M5.8
Checks before you order:
- The field of view covers the worst-case part scatter, not the nominal position.
- The pixel scale leaves enough pixels on the narrowest bar module, not just on the pick tolerance.
- The camera mount is rigid and the tray is pinned, so the hand-eye calibration keeps holding.
- The code's print contrast and quiet zones meet the decoder's requirements.
If the label is fixed by your process and the tolerance is tight, send the part drawing through the contact page and we will help size the optics — or start at the camera step of the configurator and work forward.
Questions
How many pixels do I need across the narrowest bar?
Work from the module, the narrowest bar of the code. Keep at least 2 pixels across it: a 0.25 mm module then needs a scale of 0.125 mm/px or finer, which over a 2592-pixel-wide sensor limits the field of view to about 320 mm. At 4 to 5 pixels per module, decodes also hold up better against focus error and mild blur.
How much time does the decode add to the pick cycle?
Exposure plus one decode attempt is the cost. For a printed reference point, the LS-CRD-0028 is rated at 30 fps and 60 codes/s. One attempt therefore fits in one 33 ms frame, and at the 60 codes/s limit a code resolves about every 17 ms. Budget one attempt per pick and a retry only when the read returns no decode.
Can I mount the camera on the robot wrist and read on the fly?
Yes, but every camera pose is its own calibration. The hand-eye transform you measured is valid for the robot pose it was measured at, so park the camera at a fixed taught pose for the read instead of decoding during motion, and re-check the transform after any collision or knock to the lens.
Will a code reader work on a clear polycarbonate part?
Bare clear plastic gives the sensor little to work with: the surface transmits light instead of scattering it, so bars read weakly, and a curved face tilts the code further. A printed label solves both at once. If the code must sit directly on shiny plastic, use polarized illumination — the MV-IDB005EXI-05NRP is a polarized 1.3 MP code reader for this — and present the face flat to the camera.
What exposure do I need if the tray moves during the read?
Keep motion blur under half a module width. At 0.25 mm modules that is 0.125 mm, so at a line speed of 500 mm/s the exposure must stay near 0.125 / 500 = 0.00025 s, about 250 µs; use a strobed light to recover the brightness a short exposure costs. On a stationary tray, none of this applies.