Continuous barcode detection with a live preview window

An operator taps a scan button, the tablet's camera opens, and the label gets captured. That works for single scans. It fails the moment the requirement becomes continuous: decode whatever enters the field of view, all shift, with a live preview the operator can watch. Two things break at once — the tablet camera is not built for continuous duty, and an HMI's scan component opens the camera on demand and closes it after each capture. The fix is architectural. Put a fixed code reader at the station, run it free-run, deliver its strings to the app like any other sensor value, and show the reader's own image in a small HMI window. What follows: the set-up steps, the working-distance arithmetic, and the checks to run before it goes on the line.

Can a tablet camera do continuous barcode detection?

No — a tablet or phone camera is built for short capture bursts, and continuous preview decoding will drive it into thermal throttling or a camera shutdown within minutes, nowhere near a full shift.

A tablet's camera stack is thermally budgeted for a photo, a scan, a short clip. Hold the sensor, the image processor and the decoder running frame after frame and the device heats until the operating system throttles the camera or closes it. On battery the shutdown arrives sooner.

A software wall sits behind the thermal one. An HMI scan component exposes an on-demand model — open the camera, decode, close — and a persistent decode-plus-preview loop is not something it offers. The loop can be built from the raw camera APIs of the device or browser, and the acquisition pattern it needs is the one in Continuous camera acquisition mode for live image loops. But you would then be writing and maintaining custom camera code inside an HMI client never designed to host it. Decoding every frame is computationally heavy enough to eat the CPU the rest of the app needs. Wrong place for the duty, not wrong settings.

Where should continuous decoding live instead?

Put the decoding on a fixed code reader mounted over the scan point and running free-run, and leave the tablet for occasional exceptions; a reader such as the LS-CRD-0028 re-decodes a code sitting in view at up to 60 codes/s.

A fixed code reader is an industrial device built for exactly this job: a housing made to bolt over a line, a global shutter, a decode engine rated for years of duty, and on many models the illumination built in. Continuous detection is its free-run mode — decode whatever is in view, latch the last result for the PLC, and raise an event when a new string appears.

One reader watches one zone, which maps cleanly onto one station. The fixed code readers range runs from compact M12-lens models to 20 MP logistics readers, so matching your zone is a lens-and-stand-off choice rather than a compromise. The tablet keeps one job: the exception scan of a damaged or oddly placed label. The sections below set the reader up — trigger, ROI, image out, string out, and the stand-off arithmetic that decides where it mounts.

Which reader do you pick for continuous duty?

Match the reader to the label rather than the other way round: module width sets the pixel budget, stand-off and zone width pick the lens, and station lighting picks the variant — a reader with its own light for a dark frame, diffuse or polarized light for a glossy label.

Four dedicated readers cover the everyday station cases; the smart camera gets its own section below.

For a station buried in a dark machine frame, the MV-ID813M-05S-WBN-SR carries its own white light, so no separate lamp and no extra wiring are needed at set-up.

How do you set the reader up for always-on decoding?

Set the trigger to free-run, confine the ROI to the label zone, switch on the duplicate filter, and wire the string out over TCP or serial — five configuration steps turn a triggered scanner into a decode-always-on presence detector.

1. Bench it first. Connect the reader to a PC with its configuration tool and decode real labels before it goes near the line; the first-connection and readback checks in Fixed code reader setup over USB apply to this bring-up.
2. Trigger: free-run. Decoding never waits for a hardware event, which is what continuous presence detection requires; the trade-offs against sensor and serial triggers are in Fixed barcode reader trigger modes. If reads must be part-synced, keep the photoelectric sensor as the trigger and reserve free-run for the stations that only monitor.
3. ROI tight. Draw it around the label zone only — smaller frames decode faster and stop neighbouring labels from producing phantom strings; the measured gains are in Setting an ROI for inline code reading.
4. Mount and lock focus. Set the working distance from the next section, then re-check focus after the bracket has taken a day of line vibration.
5. Duplicate filter on. One label parked in view must produce one event, not a read every frame.
6. Fixed exposure. Auto exposure that hunts between frames makes the preview pump and can drop marginal decodes; set exposure once for the station's real lighting.
7. String out. Reader as TCP server with the PLC as client, or a serial link into a PLC port — the wiring plans are in Barcode reader as TCP server and Barcode reader PLC communication.
8. HMI side. Add the live-image element (next section) and a subscription to the string tag, then test with a good label and a deliberately unreadable one.

How do you show the live image in the HMI window?

Show the reader's own live stream in an image element inside the HMI window, sized like any other operator view; the tablet never appears in the loop, because the machine-mounted reader is the camera.

Two paths are proven. Where the reader or vision sensor serves a live image on the network, an image or browser element in the HMI client renders it directly — the set-up is walked through in Vision sensor browser display for local operator viewing.

The PLC-side path routes the image through the controller into the HMI, which is what Smart camera image in a PLC HMI covers; expect a periodically refreshed image rather than true video on some routes, and label the window accordingly instead of promising a feed the pipe does not carry. Either way, keep the preview a corner tile a few hundred pixels wide: big enough to confirm the code is in view and in focus, small enough to ignore between checks. Window size and screen placement are handled in Control vision display window size and screen position.

How does the decoded string reach the app?

Send the decoded string from the reader to the PLC over TCP or a serial link, and let the HMI read it from a tag — the app subscribes to the string, it never talks to the camera directly.

Treat the reader as a sensor. Over TCP, the reader listens as the server and the PLC opens the client connection; every decode arrives as a framed message. Over serial, the reader lands on a PLC port and the same framing rules apply.

Either way, agree the terminator — CR, LF or both — and strip it before the string reaches an HMI text field; a stray control character at the end of a string is the classic cause of failed recipe lookups and duplicate database rows. The app then reads the string from a tag and does what it already did: compare, log, look up a recipe, acknowledge. Nothing about the app's logic changes — only the device feeding it, from a camera that opens on tap to a reader that never stops.

How far away can the reader sit?

Size the stand-off from pixels per module: hold at least 3 pixels across the narrowest bar, and for a 0.25 mm module Code 128 that means a field of view no wider than about 210 mm and a working distance near 150 mm.

The decoder needs a minimum number of pixels across the narrowest bar or module; under that floor it guesses, and a guess that passes once fails the next label.

The thin-lens estimate is good to a few percent at these distances. The LS-CRD-0028 pairs a 2560 x 2048 sensor in the 1/1.7-inch format with an 8 mm lens. A 1/1.7-inch sensor is about 7.4 mm wide by 5.6 mm tall.

Worked example — a Code 128 label with 0.25 mm narrow modules, reader at a 150 mm working distance:

• FOV = 7.4 × (150 / 8 - 1) = 7.4 × 17.75 ≈ 131 mm wide, and 5.6 × 17.75 ≈ 99 mm tall
• pixels per module = 0.25 × (2560 / 131) = 0.25 × 19.5 ≈ 4.9

Decision: mount the lens 140-180 mm from the label. The field stays 122-159 mm wide, a 0.25 mm module keeps 4.0-5.2 pixels, and labels up to roughly 120-150 mm wide fit with margin. Push out to 240 mm and the same code sits at the 3-pixel floor with nothing in hand — that is the mount distance to refuse.

Run your own label's numbers through the same calculator — it solves the lens from sensor width, working distance and field of view:

When is a smart camera the better choice?

Choose a smart camera when the same station also owes you presence checks, OCR or simple defect logic, and a dedicated code reader when raw decode rate is the whole job.

A smart camera decodes, inspects and serves the live image from one device, and one commissioning covers all three duties: presence-in-fixture, a lot code read beside the barcode (OCR, including several strings in one frame, is exactly what OCR on a fixed code reader sets up), and a go/no-go on a feature.

The trade is specialization. A dedicated reader puts all its processing into code families and reports richer per-read diagnostics — grade, orientation, read confidence — while a camera runs decode as one tool among several. Mind the shutter when codes move: a rolling shutter suits a code that sits still while the operator works, and fast lines want a global shutter. The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with an 8 mm lens, a 1/2.4-inch sensor and a rolling shutter on GigE — the right shape for the still-code station.

What do you check before going live?

Run four checks before you wire it into production: pixels per module on a real label, ambient glare under shop lighting, the duplicate filter's behaviour, and the PLC message frame end to end.

• Pixels on a real label. Zoom into a captured frame and count pixels across a narrow bar: 3 or more reads today, 4-5 stays readable all shift.
• Glare under real light. Run the station with shop lights and neighbouring lamps as they will actually burn; if the read rate dips, move the light off-axis or add a polarizer. Glossy laminated labels are the usual offender.
• Duplicates. Park one label in view for ten seconds and confirm the PLC receives one event, not a stream.
• Framing end to end. Scan a known string and check it arrives complete, terminator stripped, in the PLC buffer and the HMI field.
• Confidence, not just a match. Log the reader's per-read confidence or grade so marginal decodes surface before they become misses; how to judge those numbers is in Barcode read confidence.

Once those pass, the tablet goes back to being a terminal, the reader owns the decode duty, and the preview earns its corner of the screen. More decode recipes — trigger wiring, serial links, verification — sit on the code reading topic page. Pick the reader from the range above or start at the camera finder; free expert support with every order covers station layout and lens choice. To take mount, light and cabling through in one pass, start the configurator at the camera step: