← Back to MVisionPro
About the library

MVisionPro Engineering Library · fix

Why a code does not read, and what to check first

In short

Save one failed and one good frame from the same station with their exposure, gain, focus, speed and decoder recipe, changing one variable per test. Then compare them at identical settings: a directional trail along the travel direction points to motion blur, while a sharp, correctly framed capture points at the decoder, its timeout and the path the result takes. Stopping the line narrows the search rather than proving the cause.

The order of checks

The steps run from cheap geometric causes to the decoder; this is practice, not a norm.

  1. Framing and the quiet zone. A finder pattern (the structure that locates a 2D code) or a bar end touching the edge of the region of interest, the area the decoder searches, can mean the code is clipped; widen that area until the quiet zone, the clear margin around the symbol, fits inside. The margin is one module per side for Data Matrix and four for QR Code (GS1 and DENSO WAVE); GS1-128 asks ten module widths at each end, and other applications follow their own symbology specification.
  2. Pixels per module. Divide the symbol's pixel width by its module count; the module is its smallest cell or bar. Minima are engine-specific: Basler's Data Matrix Code Reader asks 3 px per module in Starter and 6 to 20 px in Basic, so check your decoder's figure before treating 3 to 5 px/module as a starting target (engineering synthesis, not a standard). If short, narrow the field or add pixels, then re-check that the whole code fits.
  3. Focus and motion. A directional trail is blur: shorten the effective image-forming time, the exposure under continuous light or the pulse length under pulsed light, and judge brightness, noise and module-edge contrast separately; gain amplifies signal and noise together, adds no photons and never removes blur (vendor guidance). Soft edges without a trail, where the nominal height reads and higher or lower parts fail, are focus: refocus on the code plane and shoot both extremes statically. Our depth-of-field estimate assumes a thin lens and a two-pixel circle of confusion, not proof of edge contrast (our calculator).
  4. Glare and illumination. A saturated patch that moves with the lamp or camera angle is glare: hold the exposure fixed and change only light geometry or polarisation, since reflective metal can read as black (vendor guidance). On a direct part mark, a code marked into the part itself, try one geometry at a time, judging by dot-to-substrate contrast: diffuse light wrapping the surface, dark field at a grazing angle, coaxial light along the lens axis, polarised light against specular return. That order is practice; ISO/IEC 29158:2025 defines evaluation conditions for such marks (normative).
  5. The mark itself. Scratches, voids, faded ink, a damaged clocking pattern (the cells that set the Data Matrix grid) or broken dots are physical and no setting repairs them, though some engines decode them anyway: ReadIDMax tolerates damaged quiet, finder and clocking patterns (vendor documentation). Compare a known-good symbol under the same optics before touching the recipe.
  6. Pose. When failures follow tilt, rotation or curvature rather than speed or height, present the code square, then add the pose back in steps. Cognex recommends staying inside 40 degrees of incidence when installing ReadIDMax, a setup recommendation rather than a decoding limit (vendor documentation).
  7. The decoder recipe. Decoder options are hypotheses, not a list to switch on. Enable the expected symbology, then change the one setting matching the failure: polarity for a light-on-dark code, damage mode for a damaged mark, your engine's perspective or grid mode for a deformed one, result count when only the first code returns, timeout when decoding stops early. Rerun the same frame after each change (vendor-specific settings).

Calculate for your case

These are inputs of the example, not typical values: 2448 px across a 160 mm field, a 0.30 mm module, 1200 mm/s and a known 100 µs exposure. Sampling is 2448 divided by 160, or 15.3 px/mm, so the module spans 4.59 px, and the trial exposure gives 1200 mm/s × 0.0001 s × 15.3 px/mm = 1.836 px of blur (calculated). For those 2448 px on 160 mm our calculator puts the one-pixel ceiling at 54.466 µs (calculated). The tool page fits a real lens to the request, so its numbers differ: a 160.5 × 134.2 mm field, 55 µs for its chosen pair and "at the minimum exposure time of 50 µs, calculated motion blur is 1.00 px". It has no field for an exposure already used, so multiply by hand, as the exposure article shows.

Common mistakes

Next step

Send us the failed frame with its settings and the reader's part number, and we confirm what that variant's passport states for distance, field and speed.

Sources

Related

How this material was prepared

Prepared with MVisionPro AI agents from stated sources and the calculation core; MVisionPro retains editorial responsibility. A physical test or human engineering review is claimed only when explicitly stated. Read the editorial method.

Editorial status: verified. Content updated 2026-09-19.