You need to read an 8 × 8 mm Data Matrix on parts that arrive with centimetres of placement drift, fire the read from a line sensor through a relay, and land each code string in Node-RED on a VM. The pattern repeats across several plants, some acidic and electrically noisy. That spec reads like a camera question; it is really an optics-and-interface question. This comparison runs the numbers for the three candidates — a fixed industrial code reader, a smart camera and a microcontroller camera build — and ends with the configuration to order for close mounts, wide drift bands, multi-camera lines and the 1D batch-tracking fallback.
Which reader should track the code on the line?
For piece-level tracking of small codes with centimetre placement drift, take a fixed industrial code reader with integrated light, a global shutter, a sensor trigger input and an Ethernet port; reach for a smart camera only when the same station must also inspect something.
That single housing carries the whole toolchain: lens matched to sensor at the factory, white light — on some models polarized — built in, the decode engine running on-device, and the output already a string on your network. A smart camera can do the same job, but you specify lens, light and algorithm yourself. The premium reader class exists for very fast belts and hostile direct-marking; for a triggered, fixed-position read of a laser-marked code, the standard fixed code reader line does the same job with less commissioning.
How many pixels does the Data Matrix need?
Design for 5 pixels per module: a typical 24-module ECC200 symbol 8 mm wide has 0.333 mm modules, so the image needs about 0.067 mm per pixel, and that pixel size is what decides which reader can cover your drift.
Three pixels per module is the published floor for a clean printed code; five adds margin for drift, tilt and focus tolerance, and etched codes want it. A denser symbol shifts the arithmetic proportionally — a 26-module symbol in the same width makes the module 0.31 mm and every field below about 8% wider.
The LS-CRD-0028 lands exactly on these numbers: 2560 × 2048 pixels, an 8 mm lens, 30 fps and 60 codes/s, on a global-shutter 1/1.7-inch sensor with Fast Ethernet. Round the mount height out of the same relation — a 1/1.7-inch sensor computes to roughly 7.4 mm across, so FOV = WD × 7.4 ÷ 8, and a 171 mm field sits at 171 × 8 ÷ 7.4 ≈ 185 mm. Check it backwards: 185 × 7.4 ÷ 8 = 171 mm; 171 ÷ 2560 = 0.0668 mm per pixel; 0.333 ÷ 0.0668 = 5.0 pixels per module. The same relation for lenses you choose yourself is in lens field of view: why sensor size and focal length set it.
- Interface
- Fast Ethernet
- Resolution
- 5 MP
- Sensor format
- 1/1.7"
- Shutter
- Global
How much placement drift can one reader absorb?
A 171 mm field absorbs a placement band of about ±60 mm around centre: the code plus its quiet zone stays under 12 mm of frame wherever it lands, and the band comes from keeping the code out of the outer 10% of the image.
Excluding that outer ring leaves about 137 mm of dependable frame, or ±60 mm after the code's own width. Hand-fed parts rarely wander further. A conveyor station that swings worse — panels drifting ±100 mm — wants the next class up, because a 6 MP reader against a 5 MP one adds about 20% of field per axis at the same pixel target (3072 pixels across against 2560). The MV-IDS006M-12C-C is a 6 MP logistics reader on GigE.
Where the bracket must sit low, under about 100 mm, choose the compact class. The MV-ID3013PM-12M-WBN pairs a 12 mm lens with a 1.3 MP sensor over Fast Ethernet. At the same 5 px/module target a 1280-pixel-wide array covers 1280 × 0.0667 = 85 mm — a ±30 mm band — at roughly 90 mm of mounting height.
The three readers to shortlist side by side:
| Specification | MV-ID3013PM-12M-WBN | LS-CRD-0028 | MV-IDS006M-12C-C |
|---|---|---|---|
| Symbologies | 1D codes: Code 39, Code 93, Code 128, CodaBar, EAN 8, EAN 13, UPCA, UPCE, ITF 14, ITF 25, Matrix 25, MSI, China Post, Code 11, and Industrial 25; 2D matrix codes: QR Code (GS1-QR included), Data Matrix (GS1-DM included), MicroQR, AZTEC, HanXin, Maxi code; Stacked codes: PDF417, MicroPDF417 | 1D: Code 39, Code 93, Code 128, CodaBar, EAN8, EAN13, UPCA, UPCE, ITF14, Matrix 2 of 5, Matrix 25, MSI, China Post, Code 11, Industrial 25; 2D: QR Code, Data Matrix; Stack codes: PDF417 | 1-dimensional codes: Code 128, Code 39, Code 93, CodaBar, EAN 8, EAN 13, ITF 14, ITF 25, UPCA, and UPCE; 2-dimensional codes: QR Code, Data Matrix |
| Max. frame rate | 60 fps | 30 fps | 28 fps |
| Max. reading speed | 84 codes/sec | – | 84 codes/sec |
| Sensor type | Global shutter, mono, 1/2.7", 4 μm × 4 μm | CMOS | – |
| Resolution | 1280 × 1024 | 2560× 2048 px | 3072 × 2048 |
| Exposure time | 35 μs to 1 sec | 35 μs ~ 1 s | 48 μs ~ 1 sec |
| Gain | 0 dB to 28 dB | – | 0 ~ 40 dB |
| Data interface | Fast Ethernet (100 Mbit/s) | Fast Ethernet (100 Mbit/s) | Gigabit Ethernet (1000 Mbit/s) |
| Digital I/O | 17-pin M12 connector provides power and I/O, including non-isolated input (LineIn 0/1/2) × 3, non-isolated output (LineOut 3/4/5) × 3, RS-232 × 1. Supports device triggering via pressing button on top.;17-pin M12 connector provides power and I/O, including isolated input (LineIn 0/1/2) × 3, isolated output (LineOut 3/4/5) × 3, RS-232 × 1. Supports device triggering via pressing button on top. | 3 non-isolated inputs, 3 non-isolated outputs, 1 RS-232 | 6-pin green terminal block provides power and I/O, Includes 1 opto-isolated input (LineIn 0), 1 opto-isolated output (LineOut 3), 1 non-isolated configurable I/O (LineIn 2/Lineout 4); 3-pin green terminal block provides RS-232 serial port |
| Power supply | 24 VDC | 24 V | 24 VDC |
| Power consumption | Avg.: 9 W @ 24 VDC (light source enabled); Max.: 48 W @ 24 VDC (light source enabled) | 20 W @ 24 V | – |
| Focal length | 12 mm | – | 12 mm |
| Price | $1,979.00 | $920.00 | $719.00 |
Values as printed in each product's data sheet; open a part for its drawing and full specifications.
Can a sensor trigger and one frame per part keep up?
Yes: a global-shutter reader triggered through a relay from a photoelectric sensor needs one frame per part, and at 30 fps with 60 codes/s it re-arms well inside a one-second cycle — faster than any hand feed.
Fixed-focus optics remove the autofocus delay that worries people on moving lines; trigger-to-string is one exposure plus transfer, a few milliseconds. The exposure to enforce is the motion-blur limit:
At a hand-feed pace of 100 mm/s the limit relaxes to 0.67 ms — both easy for a strobed LED light. Take a dry contact off the relay into the reader's trigger input: the trigger modes compared: sensor, serial or free-run article sets the mode, the GPIO-pin trigger walkthrough shows the pulse, and the sensing side is standard photoelectric sensors.
Code reader or smart camera — which wins for pure tracking?
For code-only tracking the fixed reader wins, because optics, lighting, decode library, trigger input and network protocol all ship solved; a smart camera pays for itself only when the same station also judges presence, orientation, label print or assembly completeness.
When the station is dual-duty, browse the smart cameras and apply the same pixel math — the MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a global shutter on Fast Ethernet, one box then running the code read and the inspection job. The cost of that flexibility is configuration: lens selection, lighting choice and the inspection program become yours.
| Fixed code reader | Smart camera | ESP32-class build | |
|---|---|---|---|
| Optics | Fixed lens, factory-matched focus | You select and focus the lens | Board lens, weak on small codes |
| Lighting | Integrated, polarization options | Integrated on many models | Add and wire it yourself |
| Decode engine | Industrial multi-code library on device | Vision software code tools | Hobby library, bench-grade |
| Trigger | Sensor input, relay-friendly | Digital input | 3.3 V GPIO, needs level shift |
| Output | String over Ethernet or serial | String over Ethernet | Wi-Fi or USB with a DIY bridge |
| Commissioning | Device menu or one wizard | A software project | Firmware plus bridge code |
- Interface
- Fast Ethernet
- Resolution
- 5 MP
- Sensor format
- 1/1.45"
- Shutter
- Global
Is a microcontroller camera build realistic for the plant?
Not for these plants: an ESP32-class board decodes a big, slow, well-lit code on a bench, but it hands you 3.3 V GPIO where the line needs 24 V I/O, Wi-Fi where the plant standard is Ethernet, and a bench-grade decode stack for a code demanding 5 px/module.
The hidden bill is integration, not the board: level-shift and relay hardware for the trigger, a supply that survives the cabinet, a housing for acidic air, and firmware plus a bridge node at every station to push the string into MQTT. Multi-reader microcontroller setups add addressing and wiring faults of their own — these multi-reader ESP32 troubleshooting notes give the flavour. Keep the microcontroller for a bench proof-of-concept, and try a USB barcode scanner on a Linux controller's serial port in Node-RED only where part presentation is slow and repeatable. For six plants of production lines, the sealed reader removes every one of those failure points at once.
How does the code string reach Node-RED and the database?
Any Ethernet reader delivers the string in one of three patterns — raw TCP, MQTT through a small bridge, or an HTTP POST to an http-in endpoint — and all three leave Node-RED on the office VM with the readers on the plant VLAN.
Raw TCP first: aim Node-RED's TCP node at the reader's port, or let the reader connect out to a TCP-in node; the framing in barcode reader to PLC over raw TCP sockets is identical when the peer is Node-RED. For MQTT, give each plant its own broker so a dropped office link never stalls the floor, then subscribe with the standard MQTT nodes: set the broker address and topic in the node's edit dialog, wire a debug node to confirm the string, and let the official Node-RED documentation walk you through the connect flow. An HTTP POST to an http-in node fits IT rules that open only web ports. Draw the reconnect, retry and heartbeat states once before the six-plant rollout; the reader communication plan lists them.
When a line gathers three or more cameras, or its lights must switch with the read, put a vision controller at the line end. The MV-VC3301H-128G66 carries five-plus LAN ports, four built-in light channels, 8 GB of memory and an included VM6200Pro vision license, and it publishes the same topics upstream toward your database. The range is in vision controllers.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
When is batch tracking with 1D codes the better call?
When you need to know which batch ran through a line, not which panel, mark one large 1D barcode at each end and read it twice: two readers per line instead of one per machine, and placement tolerance an order looser than a Data Matrix allows.
The trade is genealogy: between the two read points you know the batch, not the panel, and on lines where parts get reworked or diverted, that gap is exactly where a traceability audit bites. Logistics barcodes are commonly Interleaved 2 of 5 or Code 128 — Industrial 2 of 5 barcode support in fixed readers confirms what to enable in the reader, and Code 128 barcode module size, reading angle and reader distance applies the same pixel math at the friendlier module sizes. A practical rollout runs both: batch readers on the legacy, unconnected machines now, and piece-level DMC on the lines where mixing risk justifies a reader per station.
What do you check before ordering the first station?
Prove the read on your worst parts before the bracket order: twenty parts swept across the full drift band at line speed should decode 20 of 20, and any miss sends you back to the light or the height first.
- Mounting height about 185 mm for the 5 px/module target with the standard lens; confirm the number against the model's printed distance before the bracket drawing goes out.
- Close mounts: the LS-CRD-0047 specifies a 60-120 mm reading distance. Direct-marking with polarization: the MV-IDB005EXI-05NRP focuses at 70 mm.
- Drift band inside the middle 80% of the field — ±60 mm on the 171 mm field.
- Exposure near 0.33 ms at 200 mm/s so blur stays under one pixel.
- Trigger through a relay, a few milliseconds of pulse, cable routed away from power.
- Hostile or washed-down lines: check the reader's housing and connectors the way the code readers for hazardous dust areas plan does, and settle NEMA 4X versus IP66 ratings before the enclosure order.
- Judge every read by its decode confidence, and run the first-connection readback checks over USB before the panel closes.
Decision by case: drift up to ±60 mm and a standard triggered read — the 5 MP, 2560-pixel reader at about 185 mm of height. Mounts under about 100 mm — the compact 12 mm reader. A station that also inspects — the 5 MP smart camera. Three or more cameras or switched lights per line — add the vision controller and let it publish. Legacy machines off the network — batch 1D at the line ends. Pilot one station against your worst part, then repeat the bracket drawing across the plants; the code reader and smart camera finder and the system configurator shortlist the exact models.
Questions
How far should the reader sit above the Data Matrix?
About 185 mm for the 5 px/module target with the standard lens: FOV = WD × sensor width ÷ focal length = 185 × 7.4 ÷ 8 ≈ 171 mm. Fix the bracket to the model's printed distance instead of guessing: compact units specify reading distances of 60-120 mm, and polarized direct-part-marking models often focus near 70 mm.
Can one reader report straight into Node-RED without a line-side PC?
Yes. Ethernet code readers deliver the decoded string as a TCP message, so Node-RED's TCP node can terminate it directly; if your IT standard is MQTT, a small bridge on any nearby box republishes each string to a broker. Triggered reads are single frames per part, so no line-side PC is needed for bandwidth reasons.
What changes when the code is laser-etched directly on the metal?
Direct part marking adds specular glare, so polarized light and a lower viewing angle matter more than raw pixel count. Keep the 5 px/module target but expect to trade field of view for angle. Polarized readers exist in the compact class, usually with short fixed focus distances around 70 mm.
How fast does the decode have to be for one part per second?
One read per part needs little: a reader rated at 30 fps and 60 codes per second re-arms many times within a one-second cycle. Spend the margin on re-reads instead of throughput — a part that misses the first trigger costs a second pass, so judge the setup on read confidence rather than raw speed.
Do the readers need PoE, or is plain Fast Ethernet enough?
A triggered read sends one image per part: a 2560 × 2048 mono frame is 2560 × 2048 bytes ≈ 5.2 MB, so Fast Ethernet carries several stations per switch without congestion. Choose PoE only when the bracket has no local outlet; PoE appears on some readers and on several vision controllers.


