How to choose a 2D and DPM industrial code reader

Reader types: laser scanner vs image-based, 1D vs 2D vs DPM

The first decision is technology class. A laser scanner sweeps a single beam across a linear (1D) barcode and times the reflected light/dark transitions. It is fast, inexpensive and tolerant of long working distances, but it reads only 1D symbologies, needs the code presented at a roughly known orientation, and cannot read 2D matrix codes at all. For anything beyond linear barcodes you need an image-based reader: a camera that captures a full 2D image and runs decode algorithms in firmware or software.

Image-based readers decode 1D and 2D symbologies (Data Matrix ECC 200, QR, PDF417, plus GS1 and all common 1D codes) omnidirectionally, meaning the code can appear at any in-plane rotation. That omnidirectional capability, plus the ability to capture several codes in a single image, is the main reason 2D readers have largely displaced laser scanners on modern lines. The trade-off is that imaging is more sensitive to focus, lighting and motion blur, and it needs enough pixels on the code to resolve every module.

DPM (Direct Part Marking) is a harder special case of 2D reading. Instead of being printed on a label, the code is dot-peened, laser-etched, electro-chemically etched, ink-jetted or cast directly into the part surface. The marks are often low-contrast, curved, on shiny or textured metal, and sometimes the same colour as the substrate. DPM does not change the symbology — it is usually still a Data Matrix to ISO/IEC 16022 — but it dramatically changes the optics and lighting needed to make that symbology legible. A general-purpose 2D reader will often fail on DPM unless it has the right integrated lighting and a decode engine tuned for degraded, low-contrast marks.

• Laser scanner: 1D only, roughly fixed orientation, long range, low cost, no 2D or DPM.
• 2D image-based reader: 1D and 2D, omnidirectional, multi-code; needs adequate pixels-per-module and good lighting.
• DPM reader: a 2D reader with specialised lighting geometry and a decode engine hardened for low-contrast, distorted marks on metal, plastic and curved surfaces.
• Fixed-mount vs handheld: fixed-mount for automated inline read stations; handheld for manual verification, kitting and traceability spot checks.

Resolution and field of view vs code and module size

The governing rule for any image-based reader is pixels per module, also called pixels per cell (PPC). A 2D matrix code is built from small square modules (cells), a 1D code from narrow bars, and the decoder needs enough pixels spanning the smallest feature to recover it reliably. As a working rule of thumb, plan for roughly 4-6 pixels per module for printed 2D codes — using the upper end for DPM and otherwise degraded marks — and at least 2-3 pixels per narrow bar for 1D. Some decoders can resolve clean, high-contrast codes at as little as 2 px/module, but read rate falls off quickly below the rule of thumb, especially with any motion blur or marking defects.

From that rule you can size the sensor. First fix the field of view (FOV) from mechanical reality: how large is the zone where the code may appear, including part-to-part position tolerance? Then take the code's smallest module size (for example a 0.25 mm Data Matrix cell). The required pixel count across the FOV is approximately (FOV width / module size) x (pixels per module). Worked example: a 50 mm-wide FOV with a 0.25 mm module at 5 px/module needs about (50 / 0.25) x 5 = 1000 px across the width, so a 1.2-2 MP sensor with margin is sensible. Halve the module to 0.125 mm and the same FOV now needs about 2000 px across, pushing you toward a 5 MP sensor or a tighter FOV.

This is why there is a permanent tension between FOV and resolution. A large FOV is convenient for loose part placement and for reading several codes at once, but it spreads pixels thin and can drop you below the pixels-per-module floor for small codes. The levers are: raise sensor resolution, shrink the FOV (tighter mechanical positioning or a second read station), or enlarge the printed code. Always size for the worst case — the smallest module, the most degraded mark, and the corner of the FOV where lens distortion and illumination fall-off are greatest — not the clean sample on your desk.

• Pixels-per-module target: ~4-6 px/module for 2D (high end for DPM); ~2-3 px per narrow bar for 1D.
• Required horizontal pixels = (FOV width / smallest module size) x pixels-per-module.
• Bigger FOV = fewer pixels per module; compensate with higher resolution, a tighter FOV, or a larger code.
• Size for the worst case (smallest, most degraded code at the FOV edge), not a clean reference sample.
• Leave headroom: never design exactly at the minimum PPC, because marking drift and wear erode margin over time.

Working distance, depth of field and optics

Working distance (WD) is the gap from the reader's front element to the code. It is constrained by mechanics (guarding, conveyor width, robot reach) and it interacts with the lens to set magnification and FOV. For a fixed sensor and lens, a longer WD gives a larger FOV but fewer pixels per module, so WD is part of the same resolution budget as FOV. Many compact fixed-mount readers integrate the lens and offer a few interchangeable optics or focus settings tuned to common WD/FOV combinations; PC-based and smart-camera setups let you choose any C-mount or S-mount lens for full control.

Depth of field (DoF) is the range of WD over which the code stays sharp enough to decode. It matters whenever code height varies: mixed box heights on a conveyor, parts sitting at different Z in a tray, tilted surfaces, or hand presentation. DoF grows as you stop the lens down (smaller aperture, higher f-number), but that costs light and forces brighter illumination or longer exposure, which in turn risks motion blur. It also grows with a shorter focal length and a longer working distance. When Z variation exceeds what a fixed aperture can cover, a liquid lens (an electrically tunable focus element) or an autofocus reader is the clean solution: it refocuses per part in milliseconds, holding pixels-per-module across a wide height range without sacrificing aperture.

Two related effects deserve attention. Motion blur is set by part speed and exposure time, not by resolution; if a code moves more than roughly half a module width during exposure you lose contrast, so fast lines need short exposures plus enough light, often from a strobed (triggered) illuminator. And telecentricity matters when codes appear at varying WD or on stepped surfaces: a telecentric lens keeps magnification constant with distance, stabilising module size in pixels, but it limits FOV to roughly the lens diameter and is expensive, so it is rarely needed for routine code reading versus precision metrology.

• Working distance is set by mechanics and feeds directly into FOV and pixels-per-module.
• Stop down (higher f-number) for more depth of field, then add light to compensate.
• Use a liquid lens or autofocus when part height / Z position varies beyond a fixed-focus range.
• Keep exposure short enough that motion stays under about half a module during capture; strobe the light to the trigger.
• Reserve telecentric optics for metrology; standard (entocentric) lenses are normal for code reading.

Lighting and optics for DPM: dome, low-angle, polarized, on-axis

For DPM, lighting geometry is the single biggest determinant of success, ahead of resolution or decode software. The goal is to create contrast between the marked cells and the surrounding substrate, and the right geometry depends entirely on how the surface and the marks reflect light. Dot-peen and laser marks on shiny metal behave very differently from etched marks on a matte casting, so there is no universal light. This is why dedicated DPM readers ship with several switchable, integrated illumination segments and let you select the geometry per application.

Diffuse dome (cloudy-day) lighting wraps the part in even, multidirectional light and is the workhorse for shiny, curved or specular surfaces because it suppresses hotspots and glare. Low-angle / dark-field illumination skims light across the surface at a shallow angle so peened dots or engraved pits cast micro-shadows, lighting the marks against a dark background; it excels on dot-peen and embossed or debossed marks but is sensitive to mark depth and surface texture. On-axis / coaxial (bright-field) light travels straight down the optical axis: on a smooth, mirror-like surface the flat background reflects brightly back into the lens while laser-etched or flush marks scatter and appear dark, giving dark marks on a bright field. Cross-polarised illumination — a polariser on the light plus a matched analyser in front of the lens — cuts the specular glare from very shiny or wet surfaces and can rescue marks that direct light would otherwise wash out.

In practice you select lighting empirically: image the actual worst-case parts under each geometry and keep the one with the highest, most repeatable contrast. Colour and filtering help too; a monochrome sensor with a bandpass filter matched to the illumination wavelength (often red, sometimes blue for finer features or specific substrates) rejects ambient light and sharpens the mark. Standoff distance, ambient-light shrouding and a non-reflective fixture all matter. Because no single geometry wins on mixed parts, many readers cycle through lighting and exposure presets across successive captures until a decode succeeds — robust, but slower, so budget cycle time for it.

• Diffuse dome: shiny, curved, specular surfaces; suppresses glare and hotspots.
• Low-angle / dark-field: dot-peen, embossed, engraved pits; shadows the marks against a dark field.
• On-axis / coaxial bright-field: flat, flush marks and laser-etch on smooth, mirror-like metal.
• Cross-polarised (polariser + analyser): very shiny or wet surfaces where specular glare dominates.
• Monochrome + bandpass filter matched to the light wavelength rejects ambient light and boosts contrast.
• Validate with real worst-case parts; expect to cycle lighting presets on mixed-part lines, at a cost in cycle time.

Decode engine, error correction and grading

The decode engine is what turns a noisy image into data. A capable 2D reader does substantial preprocessing — locating the finder pattern (the solid L and the clock track on a Data Matrix), correcting for perspective and curvature, normalising contrast, and sampling each cell — before it ever applies error correction. The strength of a good DPM reader is in this front end: the ability to find and reconstruct a distorted, low-contrast grid that a naive thresholding decoder would miss. When you evaluate readers, test them on your own worst-case parts and compare read rate and decode time, not just the marketing claim that they 'read DPM'.

Modern 2D symbologies carry Reed-Solomon error correction, so a code can still decode with a fraction of its cells damaged, dirty or unreadable. Data Matrix ECC 200 is the dominant industrial format precisely because this redundancy makes it robust to the print defects, partial occlusion and wear that DPM parts accumulate in service. Error correction buys margin, but it is not a substitute for adequate pixels-per-module and contrast — it recovers a marginal read, it does not rescue an image the engine cannot locate or sample.

Reading a code and grading its quality are two different jobs, and it is worth being explicit about which you need. A reader answers 'what does this code say?'; a verifier answers 'how good is this mark, on an A-to-F scale, against a standard?'. Label and printed 2D symbols are graded to ISO/IEC 15415 (with ISO/IEC 15416 for 1D), while direct part marks are graded to ISO/IEC TR 29158, the standard that absorbed the older AIM DPM Guideline (AIM DPM-1-2006) and adapts the 15415 parameters for low-contrast marks and defined DPM lighting. True grading requires calibrated, controlled illumination and a verifier; many inline readers report indicative quality metrics, but a formal grade for customer or regulatory requirements (for example UDI traceability) needs a dedicated verifier.

• Good decode engines locate, de-warp, normalise and sample the grid before applying error correction — this front end is what separates DPM-capable readers.
• Data Matrix ECC 200 uses Reed-Solomon error correction, so it still decodes with a portion of cells damaged or worn.
• Reading != grading: a reader returns data, a verifier returns an A-F quality grade against a standard.
• Standards: ISO/IEC 15415 (2D labels), ISO/IEC 15416 (1D), ISO/IEC TR 29158 / AIM DPM (direct part marks).
• Formal grading needs a calibrated verifier with controlled lighting; inline readers give indicative metrics, not certified grades.

Communication, triggering and line integration

A code reader is only useful once its result reaches the controller, so match the interface to the line. EtherNet/IP and PROFINET are the common industrial fieldbuses for PLC integration; RS-232 / serial and TCP/IP sockets remain widespread for simpler hosts and legacy equipment; and discrete digital I/O carries the trigger in and a good-read / no-read pulse out for fast, deterministic handshakes with a reject mechanism. Confirm the specific protocol your PLC platform expects rather than assuming generic 'Ethernet' will interoperate.

Triggering and timing decide whether reads land on the part. A hardware trigger from a photoelectric sensor or an encoder is more deterministic than a free-running internal trigger, and on indexed or fast lines it is essential to fire the strobe and exposure at the moment the code is in the FOV and in focus. Budget the full cycle: trigger latency, exposure, decode time, and — on readers that cycle lighting presets for difficult DPM — the extra captures needed before a successful decode. The slowest worst-case part, not the average, sets your achievable line rate.

Finally, plan the data and the failures. Decide what gets logged (the decoded string, a timestamp, the image on a no-read), how no-reads are handled (reject, re-present, or operator review), and whether images must be archived for traceability or regulatory audit. Getting reject handling and logging defined up front avoids a reader that decodes well in a demo but cannot be integrated cleanly into the line's control and traceability scheme.

• Interfaces: EtherNet/IP and PROFINET for PLCs; RS-232 / TCP sockets for simple or legacy hosts; discrete I/O for trigger and good-read/no-read.
• Use a hardware trigger (photoeye or encoder) for deterministic timing; strobe the light to the trigger.
• Budget the full cycle including multi-capture DPM lighting cycling; size the line rate to the worst-case part.
• Define no-read handling (reject / re-present / review) and image logging for traceability or audit up front.

When to add OCR/OCV or deep learning

A code reader should be your default whenever the part carries an encoded symbol: a Data Matrix or barcode is self-describing, carries error correction, and decodes to an exact string. Reach for OCR or OCV only when there is no encoded symbol to read, or when human-readable text such as a lot or expiry must be confirmed alongside the code. OCR reads unknown text; OCV verifies known text against an expected reference and returns a pass/fail. The two are complementary to code reading, not a replacement for it.

Deep-learning tools earn their place at the margins of legibility — faint, deformed, dot-matrix, laser-marked or low-contrast marks on awkward surfaces — where classic template- and feature-based decoding produces unacceptable false-reject rates. The cost is representative training images (including realistic defects) and a validation approach suited to a learned model. The decision rule is simple: decode the encoded symbol with a code reader wherever you can, verify human-readable fields with OCR/OCV where required, and bring in deep learning only where print quality or surface variability defeats the deterministic tools. For the imaging and algorithm detail behind text reading, see the dedicated OCR/OCV guide.

• Default to code reading: encoded symbols are self-describing and carry error correction.
• Add OCR (read) or OCV (verify) for human-readable text, or when no encoded symbol exists.
• Use deep-learning tools only where faint, deformed or variable marks defeat classic decoding.
• Deep learning needs representative training images and a model-appropriate validation plan.