Set vision locate tolerances from QR code data

Bearing and bushing families arrive as rings in a dozen sizes. Each part carries a QR code stating its outer diameter, bore and width. Most cells answer that variety by teaching one locate model per part number and paying at every changeover. There is a shorter route: decode the payload, parse the dimensions into typed fields, and let one parametric circle tool search inside a window computed from those numbers — no new model, no teach session. This guide gives the payload grammar, the tolerance sum with the arithmetic shown, the pixel-scale rule that decides the camera, and the five checks to pass before the first tray enters the cell. It is written for the engineer who programmes the smart camera or vision controller.

Can one taught program handle every ring variant?

Yes, when the locate tool searches on dimensions instead of a taught template. A circle finder aimed at a 52.0 mm outer diameter with a ±0.5 mm window accepts every ring whose decoded diameter lands in that band, and no variant needs its own model.

The reason template teaching struggles is that a pattern model memorises appearance — grey levels, edges, the chamfer of one specific size. A parametric tool takes geometry you give it: expected diameter, width, a centre region, and a window it may deviate. Those numbers are exactly what a dimension-bearing code carries. The payload can drive the tool at runtime: a new size arrives, the code decodes, the window rescales, locate runs. Cells that code each ring with its dimensions — the same string setting the gage and the tray offsets — are the natural fit.

The teaching side of parametric models — how to build one quickly — is covered in parametric part teaching by shape and parametric teach for geometric parts, and per-batch model switching in vision locate with changing part sizes. This page adds the runtime half: the numbers arriving from the code itself.

What goes in the QR code payload?

Encode five fields in a fixed grammar — part number, outer diameter, inner diameter, width, and a checksum, with the unit declared once. A working example is R|PN=B7208|OD=52.00|ID=40.00|W=25.50|mm|CS=4A72, which any parser on the line can split without guessing.

Rules that keep the parser deterministic: fixed field order, the unit inside the string, two decimals on every dimension, and the CRC computed over the bytes before CS=. Reject on a failed checksum, a missing field, a wrong unit or a value outside a plausible range — an OD between 5 and 200 mm, say. Treat rejection, not a best guess, as the correct answer. Keep the payload under 50 characters; the example runs 47. Where the parsed values should land — PLC memory or a PC database — is compared in barcode part number parameter lookup: PLC memory or PC database.

How do decoded dimensions become locate tolerances?

Sum three terms: the part's dimensional tolerance, the camera's measurement error, and a fixed margin. For the 52.0 mm ring that is 0.3 + 0.1 + 0.1 = 0.5 mm, so the circle tool searches diameters from 51.5 to 52.5 mm on every part bearing that code.

Why four pixels: subpixel edge fitting repeats to a few tenths of a pixel on a clean edge. The k = 4 budget covers the calibration residual, distortion left after correction, and a couple of degrees of presentation tilt. Soft or bevelled edges double k to 8, and the arithmetic moves the window to ±0.6 mm — the sum sets it, not a feeling. Use the drawing tolerance whenever one exists, tighter or looser; the ISO default only fills silence.

Set the centre window from presentation, not size. Tray pockets positioned to ±3 mm give a centre search radius of 3 + 0.5 + 0.5 = 4 mm; a fixtured cell with ±1 mm pockets drops it to 2 mm.

How many pixels does the locate camera need?

Keep the pixel scale under one tenth of the search window. Δ = 0.5 mm demands 0.05 mm/px or better, which a 6 MP array clears at a 70 mm field of view with 0.023 mm/px — the 52 mm ring spans about 2280 pixels.

The division, shown: 70 mm / 3072 pixels = 0.0228 mm/px, and 52 mm / 0.0228 mm/px ≈ 2280 pixels across the ring. Take the 3072 × 2048 array as the worked example and substitute your camera's real pixel count. Any 5-12 MP sensor lands in the same band at this field of view. The ceiling follows from the rule: 3072 pixels × 0.05 mm/px = 154 mm of view, beyond which the ±0.5 mm window outruns the optics.

The same scale serves the code read. A 0.3 mm QR module measures 0.3 / 0.0228 ≈ 13 pixels, comfortably above the 3-4 pixels per module decoders ask for. Pixel scale also fixes the stand-off: a 1/2.4-inch sensor is roughly 6 mm wide, so a 70 mm field gives m = 6 / 70 = 0.086, and an 8 mm lens sits near WD = 8 × (1 + 0.086) / 0.086 ≈ 101 mm. Call it 100 mm, and treat the sensor width as typical until first light, because format names are nominal.

Which camera reads the code and which finds the part?

One camera does both jobs when the code sits on the locate face and stays inside the field of view. Split the work — a dedicated reader plus a locate camera — when codes are small, curved, or angled away from the measuring direction.

For the one-head cell, a smart camera that runs the code read and the circle fit on the device covers the whole chain with one trigger and one image. The MV-SC5060XM-08M-WBN pairs a 6 MP sensor in 1/2.4-inch format with an 8 mm M12-mount lens over GigE.

Split the cell when the code is hard to read: a symbol etched on the bore, an anodised face with poor contrast, or a mark that sits at 30-60° to the locate optics. A fixed code reader decodes under conditions a locate camera would reject, then hands the parsed payload to the controller. The MV-ID3013PM-12M-WBN is a compact industrial code reader: 1.3 MP on a global shutter, 12 mm focal length, M12 mount, Fast Ethernet.

Whatever reads the code, trigger it from the PLC rather than free-running, so one capture pairs one code with one part; the wiring logic is in trigger a fixed code reader from a GPIO pin. When the cell grows to two heads plus ring or bar lights, keep timing, payload routing and light outputs in one vision controller. The MV-VC2140-128G40-1T combines an Intel N-series processor and 8 GB memory with four built-in light channels, 3-4 LAN ports and 2 USB 3 ports.

Shortlist heads in the camera finder, then walk light and controller choices in the system configurator.

How do you validate the payload-to-tolerance chain before production?

Prove the chain with five checks on a golden tray: every variant's code decodes, every payload parses and passes the checksum, a calibrated ring confirms measured diameters within ±0.1 mm of the gauge value, wrong-checksum parts reject, and mixed-size trays locate each ring with its own numbers.

1. Decode sweep. Image every variant's code at the production pose and the worst angle you allow, ±30°, fifty captures each; accept nothing below 100 % decode.
2. Parser tests. Feed the golden payloads plus corrupted ones — a flipped digit in OD, a missing W, mm replaced by in — and require a reject on every corrupted string.
3. Scale calibration. Image a gauge ring, fit the circle, and require mean error within ±0.05 mm and spread inside ±0.1 mm — the e term you budgeted.
4. Window drill. Present a ring at the band edge, say a 51.6 mm gauge ring or a good ring tilted 3°, and confirm locate still returns it; then an out-of-band part, and confirm it rejects.
5. Mixed tray. Three sizes in one field of view; each ring binds to its own code by proximity and locates with its own numbers, twenty trays in a row.

The pass/fail station around these checks — counters, archiving, retest logic — follows the pattern in barcode match verification: build a pass/fail check station.

When should you still teach each part separately?

Teach separately when appearance, not geometry, identifies the feature: printed faces, forged textures, or families that share an outer diameter but differ in hole count. On those parts a diameter window will happily fit the wrong feature on the wrong variant.

Most of those cases yield to a hybrid: the payload's PN selects a taught model for the variant-specific feature, while OD and W still set the numeric windows inside that model. Selecting a recipe from a code is the same mechanism as selecting one over serial — RS232 vision recipe selection: one command code per recipe shows the command-code pattern. Two habits keep the hybrid honest: range-check every field even when it only selects a recipe, and on a failed or missing code reject the part rather than reusing the last variant's numbers. A silent fallback locates with the wrong tolerance and passes the wrong part, which is precisely the failure the checksum exists to prevent.

Which parts build the station?

A one-camera cell needs four things: the smart camera doing code read and circle locate, diffuse or polarised light to hold a crisp edge on the ground ring face, a controller with built-in light channels, and the tray fixture whose pocket scatter you measured for the centre window.

• MV-SC5060XM-08M-WBN — one-head cell: code read and circle locate on the device, GigE to the controller.
• MV-ID3013PM-12M-WBN — split cell: compact reader for etched or angled codes, payload delivered over the network.
• MV-VC2140-128G40-1T — two-head cell: controller with four built-in light channels driving the lights and both heads.
• Machine vision lights — diffuse dome or low-angle bar light, polarised if the face polishes back.

Order the head first, then the light, then the fixture: draw the pocket, measure its scatter, and set the centre window from the measurement. The system configurator walks camera, lens, light and controller in one pass, or send drawings and a photo of your symbol through the contact page and we will check the window arithmetic with you. More decode-and-feed patterns sit on the code-reading topic page.