Fixed code reader setup over USB: first connection and readback checks

A fixed code reader sits on the bench with a USB cable in your hand and a production link waiting. Bring it up in this order: power and enumerate on the PC, prove the decode, prove the output lands in a blank text-editor window — all before you wire anything to a PLC, HMI or MES. The shop's fixed code readers list 112 readers with a USB interface next to 365 with Fast Ethernet, so this USB workflow covers a large share of installs, and the same checks carry over when the reader finally hangs off an HMI port instead of a PC. You finish with a proven reader and a clean decision about where USB stops and Ethernet starts.

What do you need before you connect a fixed code reader over USB?

You need four things: the reader with its USB cable, a port or powered hub that supplies the 500 mA at 5 V (2.5 W) a USB 2.0 port guarantees, the maker's setup tool, and a test part carrying the same code you will read in production.

Four things, touched in this order.

• The reader and its cable. Use the cable the reader shipped with, and keep a known-good short cable next to it — the first swap when anything behaves oddly.
• A power path. A rear motherboard port or a powered hub, never an unpowered hub shared with other loads. If the reader shipped with its own power supply, use it and take power out of the question entirely.
• The setup tool. Download it from the reader maker's own download page or its distributors — the supported source, and the place where trigger mode, exposure, output format and focus aids live.
• A test part. Same symbology, same print grade, ideally the same substrate as production. A crisp office label proves your bench, not your line.

If that hub also feeds cameras or other loads, budget it before you trust it; the same arithmetic that keeps a camera's frames flowing keeps a reader's supply up (USB hub bandwidth: budget it first).

How do you connect the reader and confirm the PC sees it?

Plug into a rear motherboard port or a powered hub, apply power, and expect a new entry in Device Manager within seconds of plug-in; an unpowered hub, a front-panel pigtail or a worn cable is the usual reason that list stays empty.

1. Support the reader over the test part at the middle of its rated distance band. If the band runs 60–120 mm, start near 90 mm and treat focus as a five-second tweak, not a hunt.
2. Connect to a rear motherboard port or a powered hub. Skip unpowered hubs, keyboard pass-through ports and monitor upstream ports.
3. Apply power and watch the status LED settle to ready. A LED that blinks forever usually means boot never finished — a power problem, not a decoder one.
4. Open Device Manager, then plug the reader in. A new entry appears at the top of the device tree within seconds.
5. Unplug and replug once. The entry should vanish and return; an entry that never moves points at the port or the cable, not the reader.

USB 2.0 high-speed tops out at 5 m per cable run. A longer bench run takes an active extension or a powered hub in the middle; a longer production run is an interface decision, and the last section below makes it.

Does the reader need a driver or setup tool before it will talk?

Many fixed readers enumerate as HID keyboards and need no driver at all — they type into any text field — while image-based readers with a vendor tool usually want that tool installed first, both for the driver and because every setting you will need lives in it.

Check which class yours belongs to before assuming either way.

• Keyboard class. Device Manager shows a USB input device, and the reader types into anything with a caret. No driver and no tool are needed to prove it — the text-editor test in the next section is the whole story.
• Vendor class. Device Manager shows the maker's name or a warning icon until the setup tool or driver from the maker's site is installed. Install before the first plug-in and enumeration stays boring, which is what you want.
• Virtual COM port. Some readers can present as a serial-over-USB port; the output then arrives in a terminal or the tool's console, not a text field, and the proof test runs against that console instead.

If the destination is an HMI's USB port rather than a PC, the same classes apply and the port has its own connection sequence (connecting a USB barcode reader to an HMI port). Wedge and focus quirks on HMI text fields are worth a read before you blame the reader (keyboard wedge readers and focus in an HMI).

How do you prove decodes reach the PC before you wire the production link?

Put the caret in a blank plain-text editor window and run the readback: present your production code and accept nothing less than ten consecutive typed strings before you call the reader proven and start planning the PLC, HMI or MES link.

1. Open a blank plain-text editor, with nothing else running that could claim the device.
2. Click inside the window so the caret blinks.
3. Let the reader free-run and present the code at your working distance — mid-band if you have not tuned it yet.
4. Watch one read land: the code's string plus its terminator, typed once.
5. Repeat ten times and count ten out of ten, then run fifty before sign-off. Ten proves the link; fifty proves the station.
6. Read one string back character by character and confirm the prefix and suffix match what the downstream link expects.

Ten identical strings prove the delivery path, not read quality. Codes that decode only when held perfectly need the confidence checks, not a longer cable (how to judge barcode read confidence). Terminators deserve equal care: the CR/LF characters arriving in an HMI text field are exactly what this test shows you (CR and LF characters in an HMI text field).

Which working distance makes decodes steady instead of occasional?

Place the code near the middle of the reader's rated distance band and keep at least 2 pixels across the smallest module — 3 or more in practice — because a 0.30 mm module at 3 px per module caps the field of view near 128 mm on a 1280-pixel sensor.

Mid-band is where focus keeps margin on both sides: a part arriving 15 mm nearer or farther than you aimed still sits inside the focused depth range. The pixel rule sets how much scene the sensor may watch. A module needs at least 2 pixels of sampling to resolve — fewer and the bars smear together — and 3 or more buys margin for print quality, motion and decode speed.

Worked example, with numbers you can rescale to your own sensor and code:

• Sensor 1280 × 960 (typical at 1.2 MP), field of view 60 mm wide.
• Pixel scale: 60 mm ÷ 1280 px = 0.047 mm/px.
• Pixels per module: a 0.30 mm module gives 0.30 ÷ 0.047 = 6.4 px — comfortable.
• Ceiling: 0.30 mm ÷ 3 px × 1280 px = 128 mm. Past that you are spending decode reliability on coverage.
• The same code in a 200 mm field: 200 ÷ 1280 = 0.156 mm/px, so the module falls to 0.30 ÷ 0.156 = 1.9 px — under the two-pixel floor. That is the reader that shows the code on the live image and still refuses to decode it.

Motion sets the exposure: keep blur under half a module. At a 100 mm/s belt speed with a 0.30 mm module, expose at most 0.15 mm ÷ 100 mm/s = 1.5 ms. If the reader cannot expose that short, add light or trigger per part.

For a printed anchor in this class: the LS-CRD-0047 specifies a 60–120 mm reading distance at 1.2 MP over USB 2.0.

Why won't the reader show up or type anything?

Check power and cabling first, because an unpowered hub or a worn cable is the most common cause; then a host program that has already claimed the device, then device-class settings, and finally focus, where a reader can enumerate correctly and still type nothing.

1. Power and cable. LED dead or blinking forever: move to a powered hub or the reader's own supply with a short known-good cable. The power and interface checks for USB adapters cover the draw questions first.
2. Another program owns the device. Close the setup tool, image viewers and wedge utilities, replug, retry. A virtual COM port opened by one program is invisible to every other.
3. Output mode mismatch. The reader streams vendor protocol or COM data while you watch for keystrokes, or the reverse. Set the output mode deliberately in the tool and test the path that mode implies.
4. Driver or class trouble. A warning icon in Device Manager means the maker's driver is missing. Get it from the maker's site; a generic driver pack helps nothing here.
5. Focus, distance, glare. Enumeration fine, decode rate zero: open the tool's live image. The code should be sharp, filling the frame and high-contrast — apply the distance numbers above.
6. Connects, then drops mid-shift. Strain-relieve the cable and stop the operating system from suspending the port. If the far end is an HMI rather than a PC, the drop usually lives on that side (a USB device that connects then drops on an HMI).

When should a code reader stay on USB, and when is Ethernet better?

Pick USB when the reader sits within the USB 2.0 cable limit of a PC that wants keystrokes or a serial stream; move to Fast Ethernet or GigE readers for longer runs or PLC links — the shop lists 365 Fast Ethernet, 126 GigE and 112 USB fixed readers.

USB earns its place for bring-up and for stations whose host is a PC within cable reach: output is keystrokes or a serial stream, with no network configuration and no switch, and the text-editor proof transfers directly. The decision flips when any of these appears:

• The reader sits beyond a cable run from the host, or several readers share one host on a network.
• A PLC or MES consumes the code over the network — plan that link as its own task (barcode reader to PLC: plan a reliable link).
• Trigger timing on a moving line needs a deliberate mode, and the Ethernet tooling exposes it well (fixed barcode reader trigger modes: sensor, serial or free-run).

Same family, Ethernet side:

The LS-CRD-0028 captures 2560 × 2048 at 30 fps and decodes up to 60 codes/s with its 8 mm lens on a Fast Ethernet drop. The LS-CRD-0052 pairs a 12 mm lens with 1.2 MP resolution in a dual aviation-plug housing on Ethernet.

From here the station is proven: distance set from the numbers above, ten out of ten reads into a text editor, output mode and terminator matched to the destination. Filter interface and resolution in the code reader finder, and reuse this bench workflow as the commissioning script for every reader that follows. More decode-side checks live on the code reading topic page.