Choosing an industrial code reader: fixed or handheld, label or direct part mark

In short

Four answers narrow the catalog, and sensor resolution is not one of them. Decide first which object moves and who aims: a code brought to an installed, triggered point is a fixed-mount job, a portable reader carried to the code is a handheld one, and a part in an operator's hand settles neither. Decide second whether the code is printed on a label or marked into the part, because a direct mark is a lighting problem before it is a decoding one. Then fix the symbology and the module width together with the rest of the presentation envelope, and confirm lighting, optics, interface and trigger on the exact orderable variant. A sample read test comparing every presentation with its expected value settles the rest.

Which object moves, and who aims

Our code reader category separates 34 fixed-mount readers from 12 handheld ones and asks first whether the code is presented to an installed reading point or handled with a portable device (catalog snapshot). A fixed-mount reader sits at a defined point and is triggered by the process; a handheld reader is portable and aimed by an operator.

The presence of a person settles nothing on its own: an operator carrying a part to a reader bolted over a bench is working at a fixed-mount station. Four questions separate the cases: which object moves, who aims, where the trigger and the feedback live, and how the decoded string is tied to the workpiece. Triggering, integration and duty cycle differ across that split, so answer them before comparing sensors. KEYENCE describes handheld devices as a complement to fixed inline readers rather than a substitute (vendor guidance).

A direct part mark is a lighting decision

A direct part mark, or DPM, is a code cut, dotted or etched into the part itself instead of printed on a label. On reflective or textured material it has almost no printed contrast, so what the sensor sees depends on where the light comes from. Cognex instructs handheld users to enable polarized and diffuse read setups for such marks (vendor documentation). Diffuse light arrives from many angles and evens out glare, while polarized light is filtered so the mirror-like reflection is suppressed and the scattered light carrying the mark gets through.

Lighting is therefore decided one level below the family name, on the variant, and the handheld MV-IDH9000B shows how. Its /13DP/04RP/LS variant states DPM codes with four modes: diffused reflection and bi-directional lighting on red LEDs, direct and polarized lighting on white LEDs (datasheet). MV-ID5050XM ships with a half-polarization lens cap by default (datasheet); send us the variant and we confirm the light and the direct-mark support it carries. Whether a mark then decodes under that cap depends on geometry and finish, which only samples show.

Both symbology and module width have to pass

Eligibility has two gates and one variant has to pass both. The first is the symbology, the code type plus its version where the application fixes one. The second is the module or narrow-element X-dimension, the width of the smallest cell or bar, usually quoted in mil, one thousandth of an inch. A symbology list carries no physical limit, and a 3 mil or 10 mil statement says nothing about which code types are enabled.

Datasheet geometry is written the same way. The MV-IDH9000B record gives reading distance per symbology and per module size. Code 128 runs from 0 mm to 100 mm at 3 mil and from 0 mm to 350 mm at 20 mil, while at the same 5 mil a Data Matrix runs from 5 mm to 79 mm against a Code 39's 0 mm to 150 mm (datasheet). Symbology support moves between variants too: MV-ID2004M lists QR Code and Data Matrix for its 6.72 mm lens columns and adds MicroQR, AZTEC, HanXin and PDF 417 for the solid-state-focus column (datasheet).

Judge both with the rest of the presentation envelope, the span of positions, angles, distances and sizes the reading point has to accept: smallest and largest symbol, quiet zone, distance range, position variation, orientation and codes per presentation. Where only the overall symbol size is known, ask for the version or cell count, which is what turns it into a module width; the arithmetic from there to required pixels is in code size, camera resolution and pixels per module.

What line speed decides and what it does not

Line speed is an input of the choice in its own right: with the width of the reading field it fixes how long each code stays in front of the reader, and with the flow of codes it fixes the capture rate the device has to hold. Exposure is the one step speed cannot settle alone: state the blur you are willing to accept, in millimetres on the object or in pixels at your sampling, and the interval in which the image is formed stays at or below that allowed blur divided by the object speed. Exposure, motion blur and strobe carries the calculation, the continuous-light and pulsed cases and their assumptions.

Two datasheet fields near speed are easy to mistake for it. On MV-ID3016XM the exposure range of 25 µs to 30 000 µs says which settings the camera accepts, not which motion you can freeze at your light level. Its 110 codes/s is a declared datasheet maximum for that device, not a rate measured on your symbols or a throughput figure for your line. Where one datasheet covers several variants the declared maximum follows the column it is printed against: MV-ID2004M states 38 and 41 codes/s against its 6.72 mm lens columns and 45 codes/s against the solid-state-focus column (datasheet).

A family name is not an orderable device

A family name covers several orderable variants, and configuration in this article means the installed system of variant, optics, light and cover, decoder settings, mounting, trigger and host link. Optics, focus, light, cover and connection vary independently inside one family, so the best value from each field describes a specification no single part number has to satisfy.

Host integration is decided at the same level. Interfaces run from USB 3.0 or Fast Ethernet on MV-ID2004M to Gigabit Ethernet on MV-ID5050XM and the MV-ID7080EM-35F-WHA V3.0 line reader, while the handheld reaches its host through a smart base over Fast Ethernet and RS-232 or over USB 2.0 (datasheet). Discrete input and output follow the variant as well: three opto-isolated inputs and three opto-isolated outputs on a 12-pin M12 connector for MV-ID3016XM and MV-ID5050XM, non-isolated I/O on a 17-pin connector for MV-ID2004M (datasheet). Confirm connector, trigger I/O and protocol on the exact variant before a shortlist becomes an order.

The read test that can see a wrong value

Selection ends with a sample-based read test over the declared envelope at its extremes, with the real material and finish, the contamination of the cell and the presentation rate you must hold. The test also needs a way of knowing what should have come out. Give every presentation an event or workpiece identifier, store the expected value before the read, and record what the reader returned with its timestamp and status. Then count five outcomes separately: a correct result, no result, a wrong result, a duplicate or late result, and a result attached to the wrong item. Decide in advance what the line does with the last four.

That comparison exposes the two failures people assume announce themselves. A missed trigger can leave no no-read message anywhere, because nothing asked the reader for a decode; a wrong value that still fits the symbology's structure looks like success on the indicator. GS1 separates verification from scanning and notes that decoded data has to be linked to the application or database before its content is confirmed (normative guidance), though the comparison is your plant's acceptance control rather than a protocol GS1 defines for your line.

Worked example: a label on a conveyor, then a mark on a part

Cartons travel on a belt at 1 m/s (assumption of this example), each carrying a printed label, and nobody handles them, so the architecture is settled at once as a fixed-mount job. Nothing else is settled: symbology, module width, position and height spread, working distance, blur allowance, presentation rate and controller interface are all open, and 1 m/s does not choose between the compact, mid-range, large-sensor and line-reader architectures.

A tempting shortcut runs through the line reader. The MV-ID7080EM-35F-WHA V3.0 record states a maximum operating speed of the conveyor belt of 2.5 m/s (datasheet), a different field from codes per second and above the 1 m/s of this example. That headroom is real and it belongs to the geometry printed beside it, a 35 mm lens at a best working distance of 1000 mm with a field of 1000 mm at 10 mil (datasheet). Comparing the two speeds means first naming what this scenario has left open: the module width of the labels, the working distance and field width at the reading point, the presentations per second and the blur allowed at that sampling. Work in that order: module width to sampling, sampling and blur allowance to an exposure ceiling, then a read test on real labels at both height extremes.

Now change the station. An operator holds a portable reader and brings it to a machined metal part whose code is dotted into the surface, so the reader moves, the operator aims, and the handheld branch is justified. A traceable candidate is MV-IDH9000B/13DP/04RP/LS at 1280 × 1024 pixels, with the four lighting modes above, an Ethernet smart base and a stated minimum accuracy of 3 mil (datasheet). Read that last figure as a declared capability of that variant under its own conditions, not as a limit you can carry onto your part. Had the operator instead carried the part to a bench reader triggered by a sensor or a button, the station would be fixed mount even with the part in a hand. Either way the marking process, module width, surface finish and curvature, distance and angle range and contamination are still missing, and direct, diffuse and polarized lighting have to be tried on representative parts.

Calculate for your case

None of the MVisionPro calculators ranks reader families, and the two calculations this path does need live in other articles. Take the sampling in code size, camera resolution and pixels per module, entering the module width in millimetres, converted from mil at 0.0254 mm per mil, with the field width, the working distance, the camera and the pixels-per-module figure your decoder documents. Then take the exposure ceiling in exposure, motion blur and strobe, entering that sampling, the line speed and the blur you accept. When a code fails after installation rather than during selection, the checks are in why a code does not read.

Common mistakes

• A declared codes-per-second maximum is not your line's throughput. It is the manufacturer's figure for the variant it is printed against, while yours follows from your symbols, your presentation rate and your trigger timing.
• A line speed quoted with no blur allowance sets no exposure limit. Name the blur you accept in millimetres or pixels, then derive the interval in which the image is formed.
• A bigger sensor is not automatically a better reader. Over a wide field it can put fewer pixels on a module than a small sensor over a narrow field, so field, module width, optics, lighting and exposure have to agree.
• One good frame is not a passed trial, and two separate controls stand behind it. Counting presentations by event identifier, counter or timeout exposes a missing answer, and comparing the returned string with the expected one exposes a wrong one. Without the matching control the error can go unnoticed, so count correct, missing and wrong results separately.

When this rule breaks

The path chooses a reader for decoding, and decoding is not verification. Grading a symbol is a separate calibrated measurement: ISO/IEC 15415:2024 specifies print-quality testing for two-dimensional symbols, and ISO/IEC 29158:2025 modifies it for direct part marks and their illumination (normative). Call a candidate a verifier only when its own datasheet states that function.

The path also stops short when one reading point has to cover an envelope no single variant covers, such as labels and direct marks in the same flow. Split the envelope between two reading points, or narrow it with fixturing and a defined presentation, then compare devices again.

Next step

Send us how the code is presented and which object moves, a photograph of the worst code with a ruler in the frame, the module width if you know it, the distance and angle range, the presentations per second you must hold and the controller interface the result has to reach. Field of view and reading distance follow the lens and focus of the exact variant, so we check the matching variants against their datasheets and say which fields are decided and which still need a sample test.

Related

• Why a code does not read, and what to check first
• Turning a code's size and module count into a camera resolution
• Setting the exposure for a moving part, and deciding whether the light should be pulsed

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-21.