Barcode reader module confusion: vision vs MES vs web scanner paths

You specify a scanner for a line, open the platform documentation, and find a "barcode scanner module" that seems to belong to three products at once. It usually does. Most platforms ship one component that binds a serial port inside a client, an MES utility that adds code-reading components to traceability screens, and a third pattern in which web-enabled handhelds post scans to an HTTP endpoint. This explainer separates those three paths, gives the numbers that decide between them (cable reach, transport latency, pixels per module, exposure) and ends with the hardware that fits each one, so you can specify a reader the same day.

Is the barcode scanner module part of vision, MES or the web layer?

None of them exclusively: one and the same scan string travels a serial or USB component bound inside a client, an Ethernet reader serving TCP or HTTP to any consumer, or a web-enabled handheld posting to an endpoint — the choice follows the consumer, not the module name.

The naming trouble is historical. HMI and SCADA platforms with a vision toolkit sell display and inspection tools for screens; MES suites then add utility modules that place code-reading components on a client and bind them to one serial port. Neither of those owns the scanner. Separately, warehouse handhelds with Wi-Fi run a browser or a small agent and deliver scans as HTTP posts, and some vendors wrapped that too in a "scanner module" name.

The model that settles it: a scanner is a data source with one job, turning marks into a string. Everything called a module is transport. Pick the transport by answering three questions — who consumes the string, on what machine does that consumer run, and how many consumers are there?

Which capture path should my line use?

Use serial or USB when one station consumes scans and the cable stays under 5 m for USB or about 15 m for RS-232; move to an Ethernet reader the moment a second consumer needs the string or the run passes those limits.

The first row wins on simplicity: one cable, one component, done in an afternoon. The middle row wins everywhere else, because a network reader lets the PLC take the scan for control while the MES takes the same string for traceability, with no second scanner. The third row belongs to warehouses and picking flows, not to conveyors with reject gates. Browse fixed code readers for the first two rows; the finder sorts by interface and resolution.

Is serial too slow compared with Ethernet?

Both are far quicker than the scan itself: at 115,200 bit/s an RS-232 link moves a 20-character code with start and stop bits in about 2 ms, and the same frame crosses Fast Ethernet wiring in microseconds, so throughput never decides the path.

The arithmetic: a 20-character code at 10 bits per character (8 data bits, no parity, 1 stop) is 200 bits; 200 ÷ 115,200 = 1.7 ms. The same payload as a 200-byte frame on 100 Mbit/s wiring needs 16 µs on the wire, and 1-5 ms door to door once host stacks touch it. A line sending 50 codes per second keeps the serial port busy under a tenth of the time.

So speed never rules serial out. Cable reach does: 5 m is the passive limit for a USB run and about 15 m for RS-232 at full rate. The number of consumers does too, and so does the client type — a serial binding lives inside one installed client and nowhere else. For host-side command timing, see barcode scanner serial trigger: fix silent host commands and RS232 barcode scanner connection to an embedded host; for the USB path, USB barcode scanner data capture in your application.

What hardware fits each path?

Buy a compact USB or serial reader for the single-station path, a Fast Ethernet or GigE fixed reader for the shared path, and a smart camera only when the same station must also inspect the part — one camera then covers both jobs.

For one client and one station, the LS-CRD-0047 is a compact fixed reader with a 1.2 MP sensor, USB 2.0 and a 60-120 mm reading distance: mount it, aim it, bind the port, done.

For the shared path, the MV-ID3013PM-12M-WBN is a Fast Ethernet reader with a 12 mm focal length and 1.3 MP resolution, aimed at single-label stations.

When one camera must cover a wide belt or several label positions, the MV-ID5120RM-08M-RBN brings a 12 MP sensor on GigE and the MV-IDS006M-12C-C is a 6 MP logistics reader on GigE.

When the station must also judge print quality or part presence, one camera does both jobs: the LS-SMC-0063 is a 1.6 MP GigE smart camera with a 16 mm lens, 60 fps and built-in white light, and it hands the string to the network like any reader.

Shiny labels and black plastics are where readers stumble; code reader accessories add polarizing covers and light boards that fix glare without touching the decoder.

How do you size the reader for your code and label zone?

Size at 2 pixels per module for 1D codes and 3 pixels per module for 2D codes such as DataMatrix, then work backwards to the field of view, the sensor and the working distance — the sensor is chosen last, not first.

Worked example: a DataMatrix with 0.25 mm modules can sit anywhere in an 80 mm zone (a 60 mm label plus ±10 mm of placement wander).

• Pixels required across the zone: 80 ÷ 0.25 × 3 = 960 pixels. A 1.3 MP sensor with 1280 pixels across clears it with about a third of margin.
• A 12 mm lens on a 4.8 mm-wide sensor at 300 mm working distance gives a field of view of 4.8 ÷ 12 × 300 = 120 mm. Pixels per module fall to 1280 ÷ 120 × 0.25 = 2.7 — below the rule.
• Move to 200 mm: field of view 4.8 ÷ 12 × 200 = 80 mm, and pixels per module rise to 1280 ÷ 80 × 0.25 = 4.0. Pass.
• Pixel pitch implied by that sensor: 4.8 mm ÷ 1280 = 3.75 µm.
• The belt runs at 0.5 m/s. One third of a module of blur is 0.083 mm, so the exposure limit is 0.083 ÷ 500 = 0.00017 s: cap exposure at 150 µs and strobe the light.
• Part height varies ±15 mm. With magnification m = 4.8 ÷ 80 = 0.06 and a 2-pixel blur of 7.5 µm, depth of field ≈ 2 × N × 0.0075 × 1.06 ÷ 0.0036 = 4.4 × N mm. The 30 mm band needs N ≈ 7, so a lens closed to f/8 holds focus through it.

Fixed-lens readers ship with aperture and focus preset, so treat the depth-of-field line as a check against the stated range. When the height band or the field of view beats the preset, step up to a C-mount body such as the MV-ID6200PM-00C-NNG, a 20 MP logistics reader, and pick the lens yourself. Run your own numbers through the camera resolution calculator before you shortlist anything.

How does the scan string reach the PLC and the MES?

To both, in that order: the PLC needs the string within one scan cycle — plan 1-10 ms over Ethernet — to merge it with the reject decision, while the MES needs one timestamped write per part, which is bookkeeping, not control.

Framing comes first. Agree a start character and a carriage-return-line-feed terminator with whoever writes the PLC logic, or the merge logic guesses; barcode scanner capture without a prefix: preamble and serial covers that exact problem.

Transport comes second. A fixed Ethernet reader pushes each string to a TCP socket the PLC owns and, in parallel, to an HTTP endpoint or database writer the MES owns — the planning steps are in barcode reader PLC communication: plan a reliable link. Legacy MES imports that only watch a folder are served by the pattern in Ethernet barcode reader to CSV for watched-folder imports.

Reliability comes third. After a power blink, readers that took a new address must be told apart, per identify barcode scanners by serial number after reconnects, and each accepted read should carry a score, as barcode read confidence: how to judge whether a decode is trustworthy explains. Keep the image with the string for audit — barcode inspection image archiving to cloud storage — and trace the full chain in inline traceability validation: connect codes, OCR and rejects. For control-side detail, integrating barcode readers with PLCs over ASCII, serial and MES goes a level deeper.

When is the standard answer the wrong one?

The usual advice is wrong in three places: web clients cannot open serial ports, a Wi-Fi handheld is not a fixed reader when a reject gate must fire in under 100 ms, and a line that already owns a smart camera should not add a separate code reader at all.

Browser and thin clients break the serial path. The binding runs inside a full installed client; a web client has no COM ports to open. Move the binding to the server, or move the scanner to Ethernet. The failure looks like silent input on the screen — barcode scanner input not reaching a vision screen walks that diagnosis.

Reject timing breaks the handheld path. A Wi-Fi gun posting over HTTP is a person-paced tool: plan tens of milliseconds plus retries. A divert gate that must act inside 100 ms needs a fixed reader wired to a PLC.

Robot cells are the third exception. When the robot is the only consumer, skip the PLC entirely — barcode scanner robot communication without a PLC shows the direct link. And when a smart camera already images the part, decode on it instead of adding a reader; the smart cameras range covers that case.

What should you check before ordering?

Check eight things in order: who consumes the string, the cable run, the module size, the zone width that sets the field of view, the belt speed against exposure, the reconnect behavior, the framing agreement, and the image archive — then pick the model.

• Consumer named — one client, a PLC, the MES or all three; it fixes the transport.
• Cable run — under 5 m for USB, 15 m for RS-232, otherwise Ethernet from day one.
• Module size — measured with a loupe or taken from the label spec; 2 pixels per module for 1D, 3 for 2D.
• Field of view — from the formula, plus 20% spare for placement wander.
• Exposure — blur held under a third of a module at belt speed, strobed if the limit lands under 200 µs.
• Reconnect plan — reader identity by serial number and a queue sized for a 30-minute outage.
• Framing — prefix and terminator agreed with the PLC programmer before commissioning.
• Archive — image and string stored per part, and the reader configuration backed up before every change, per vision reader configuration backup before troubleshooting.

Then order. The camera finder filters readers and smart cameras by interface and resolution, accessories carries the covers and light boards, and the system configurator walks camera, lens and light in one pass. For a station already on paper, send us the details and we will size it, or compare notes with the other code reading guides.