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

In short

A code brought to an installed reader means fixed mount, and a reader carried to the code means handheld. A part in an operator's hand does not decide it. A code marked into the part is a lighting problem first. Code type and module width must both fit one orderable variant, with its light, optics, interface and trigger. Then test real samples: record every presentation, check for missing results and compare returned values with the expected ones.

What moves: the code or the reader?

Our code reader category makes this the first split (catalog snapshot). Its 34 fixed-mount readers sit at one point and are triggered by the process. Its 12 handheld readers are portable and aimed by an operator.

Who holds the part does not decide it. Ask four questions. Which object moves? Who aims? Where do the trigger and the feedback live? How is the decoded string tied to the workpiece? The two classes differ in triggering, integration and duty cycle, so answer these before comparing sensors. Handheld readers complement fixed inline readers rather than replace them (KEYENCE, vendor guidance).

A mark in the part is a lighting problem

A direct part mark, or DPM, is a code cut, dotted or etched into the part itself. On shiny or textured material it has almost no printed contrast, so the light direction decides what the sensor sees. Diffuse light arrives from many angles and evens out glare. Polarized light is filtered to block the mirror-like reflection and pass the scattered light that carries the mark. Handheld DPM guidance is to enable the polarized and diffuse read setups (Cognex, vendor documentation).

So light is chosen per variant, not per family. The handheld variant MV-IDH9000B/13DP/04RP/LS states DPM codes and four lighting modes: diffused reflection and bi-directional on red LEDs, direct and polarized on white LEDs (datasheet). The fixed MV-ID5050XM ships with a half-polarization lens cap by default (datasheet). Confirm the exact variant's lighting and DPM support with us. Whether your mark decodes under that cap depends on geometry and finish, which only samples show.

Code type and module width: both must fit

One variant has to pass two checks. The first is the symbology: the code type, plus its version where the application fixes one. The second is the module width, or narrow-element X-dimension: the width of the smallest cell or bar, usually in mil (a thousandth of an inch). A list of code types sets no size limit. A 3 mil or 10 mil figure says nothing about which code types are enabled.

Datasheets tie reading distance to both. For MV-IDH9000B, the Code 128 range is 0–100 mm at 3 mil and 0–350 mm at 20 mil. At the same 5 mil, the range is 5–79 mm for Data Matrix and 0–150 mm for Code 39 (datasheet). Code type support also changes between variants. MV-ID2004M lists QR Code and Data Matrix for its 6.72 mm lens columns, and its solid-state-focus column adds MicroQR, AZTEC, HanXin and PDF 417 (datasheet).

Check both across the presentation envelope, everything the reading point must accept: the smallest and largest symbol, quiet zone (the clear area around the symbol), distance range, position spread, orientation and codes per presentation. If you only know the symbol size, ask for the version or cell count to get the module width. The step from there to pixels is in code size, camera resolution and pixels per module.

What line speed does and does not decide

Line speed and field width set how long each code stays in view. Speed and code flow set the capture rate the reader must hold. Speed alone does not set the exposure, the time in which the image forms. First state the blur you accept in millimetres on the object. If you think in pixels, divide by the sampling (pixels per millimetre) first. That blur divided by the speed gives a time limit. Under continuous light, it limits the exposure. With pulsed light, it limits the pulse, if the pulse fits inside the usable exposure window and ambient light is negligible.

On MV-ID3016XM, the exposure range of 25 to 30 000 µs lists the settings the reader accepts, not the motion you can freeze with your light. Its 110 codes/s is a declared datasheet maximum, not a rate measured on your symbols. Where one datasheet covers several variants, each maximum belongs to its own column. MV-ID2004M states 38 and 41 codes/s for its 6.72 mm lens columns and 45 codes/s for the solid-state-focus column (datasheet).

Choose the variant, not the family

A family name covers several orderable variants. Optics, focus, light, cover and connection vary independently inside a family. So the best of each field can add up to a device that no part number matches. Configuration here means the whole installed system: variant, optics, light and cover, decoder settings, mounting, trigger and host link.

Host links differ by variant too (datasheet). MV-ID2004M connects over USB 3.0 or Fast Ethernet. MV-ID5050XM and the MV-ID7080EM-35F-WHA V3.0 line reader use Gigabit Ethernet. The handheld reaches its host through a smart base, over Fast Ethernet and RS-232 or over USB 2.0. MV-ID3016XM and MV-ID5050XM have three inputs and three outputs, all opto-isolated, on a 12-pin M12 connector. MV-ID2004M has non-isolated I/O on a 17-pin connector. Confirm connector, trigger I/O and protocol on the exact variant before a shortlist becomes an order.

A read test that catches wrong values

End with a read test on samples at the envelope's extremes, with real material and finish, the contamination expected at the reading station and your required presentation rate. Give every presentation an event or workpiece ID, and store the expected value before the read. Record what the reader returned, with timestamp and status. Then count five outcomes separately: correct, missing, wrong, duplicate or late, and attached to the wrong item. Decide in advance what the line does with the last four.

Without this comparison, two failures stay hidden. A missed trigger can leave no no-read message, because nothing asked the reader to decode. A wrong value that fits the symbology's structure shows as a success on the indicator. Decoded data needs a link to the application or database before its content counts as confirmed (GS1, normative guidance). The comparison itself is your plant's acceptance control, not a GS1 protocol for your line.

Worked example: a conveyor label, then a metal part

Cartons ride a belt at 1 m/s (assumption of this example). Each carries a printed label and nobody handles them, so this is a fixed-mount job. Everything else is open: symbology, module width, position and height spread, working distance (reader to code), field width, blur allowance, presentation rate and controller interface. Speed alone does not choose between compact, mid-range, large-sensor and line-reader architectures.

The MV-ID7080EM-35F-WHA V3.0 line reader looks like a shortcut. Its datasheet gives a maximum conveyor belt speed of 2.5 m/s, a different field from codes per second. That is above our 1 m/s, but the figure 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. Fill in the open values and run the calculations below before you compare speeds. Then test real labels at both height extremes.

Now change the station. An operator carries a portable reader to a machined metal part with a code dotted into its surface. The reader moves and the operator aims, so this is a handheld job. A traceable candidate is MV-IDH9000B/13DP/04RP/LS, with 1280 × 1024 pixels, the four lighting modes above, an Ethernet smart base and a stated minimum accuracy of 3 mil (datasheet). Read that 3 mil as a declared capability under this variant's own conditions, not a limit for your part. Had the operator brought the part to a bench reader triggered by a sensor or a button, the station would be fixed mount. Either way, you still need the marking process, module width, surface finish and curvature, distance and angle range, and contamination. Then try direct, diffuse and polarized lighting on representative parts.

Calculate for your case

No MVisionPro calculator ranks reader families. First get the sampling from code size, camera resolution and pixels per module. Enter the module width in millimetres (1 mil = 0.0254 mm), the field width, the working distance, the camera and the pixels-per-module figure your decoder documents. Then check the exposure or light-pulse duration and its timing in exposure, motion blur and strobe. Enter that sampling, the line speed and the blur you accept. If a code fails after installation, see why a code does not read.

Common mistakes

• A declared codes-per-second maximum is not your line's throughput. Yours depends on your symbols, presentation rate and trigger timing.
• Line speed without a blur allowance sets no exposure limit, so name the blur you accept first.
• 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 one. Field, module width, optics, lighting and exposure must agree.
• One good frame is not a passed trial. Count presentations by event ID, counter or timeout to catch missing answers. Compare each string with the expected one to catch wrong answers.

When this rule breaks

This path picks 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 2D symbols, and ISO/IEC 29158:2025 adapts it for direct part marks and their lighting (normative). Call a candidate a verifier only if its own datasheet states that function.

The path also breaks down when one reading point must cover more than any single variant can, such as labels and direct marks together. Split the job between two reading points, or narrow it with fixturing and a defined presentation, then compare devices again.

Next step

Send us which object moves, how the code is presented and a photo of the worst code beside a ruler. Add the module width if you know it, the distance and angle range, the presentations per second and the controller interface. Field of view and reading distance follow the lens and focus of the exact variant. We check the matching variants against their datasheets and say what is decided and what still needs a sample test.

Related

• Why a code does not read, and what to check first
• Working out the camera resolution a code needs
• Setting exposure for a moving part, and deciding whether to pulse the light

How this material was prepared

Prepared by MVisionPro from the stated sources and the MVisionPro calculation engine. A physical test is claimed only when the material says so explicitly. Read the editorial method.

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