Scanning a barcode with a web camera into a database

Your production manager walks the floor with a tablet in one hand and a scanner gun in the other, and every scan still travels scanner to PLC to database before anyone can query it. This article is for the controls and IT people who want to drop the gun and the PLC detour: point the tablet camera at the label, let a decoder inside the page turn the frame into a string, and post that string to a web service that writes the row. You get the architecture, the pixel arithmetic that decides whether a web camera can read your label at all, planning rates for deliberate scanning, and the point at which a mounted reader becomes the only honest answer.

The short answer

For deliberate, operator-aimed scanning, the web camera in a tablet or phone is good enough, and the direct-to-database path is the right architecture: the page decodes the code and posts the string to your own HTTP service, which validates and inserts the row in 10-50 ms on a plant LAN. Plan on one deliberate scan per second per operator. Three cases cover nearly every request:

• Inventory counts, goods receipt, tool crib check-out. Web camera in a browser page. No driver, no serial link, no PLC round trip.
• All-day picking, rough or glossy labels, gloved hands. Add a handheld code reader; your application still receives a string, from a better front end.
• The item moves, nobody aims, or the read must drive a gate. Fixed reader or smart camera with a hardware trigger: PLC for control, service for the history table.

The rest of this article gives you the numbers behind those three lines.

What a web-camera scan actually is

The camera never talks to the database. Three pieces sit between the lens and the table:

1. Capture. The page asks the browser for the camera stream; a current device delivers 15-30 frames per second. If the device has no camera at all, a good decoder library exposes a check for that, so the page can fall back to manual keying.
2. Decode. A JavaScript decoder scans each frame for 1D and 2D codes and hands your code a string. With the aim steady, that lands within a few frames — well under half a second on a current phone.
3. Persist. The page POSTs the string, plus user, timestamp and optionally the JPEG frame, to a small web service. The service validates, inserts and answers. Nothing else in the plant changes.

The decode side of this pipeline — which libraries read which symbologies, and how to handle glare and rotation — is covered in webcam barcode scanning in browser-based vision systems. What your program receives at the end is the same thing a USB barcode reader hands your application: a string in memory. Only the birthplace of the string differs.

One architectural caution: web-based HMI and SCADA clients can only reach the camera through the browser's own capture interface, which is why some platforms ship a native mobile app for scanning; the trade-offs are set out in this browser versus mobile app barcode scanning comparison. If your client is browser-only, run the scanner page as its own tab or small app and write to the same service.

Pixels per module: the number that decides it

A decode is a resolvable-bars problem, and one number settles it: pixels per module — per narrowest bar for 1D codes, per module for 2D. Two pixels per module is the floor below which decoders fail on real prints; three to four carries a read through the dust, skew and imperfect focus of a floor application.

Worked example, arithmetic checked. A 1080p web camera, 1920 px wide with a 70° horizontal field (tan 35° = 0.700), reading a Code 128 label with 0.25 mm narrow bars — the common 10 mil floor label:

• 400 mm stand-off: FOV = 2 × 400 × 0.700 = 560 mm, so 1920 / 560 = 3.4 px/mm, and 3.4 × 0.25 = 0.86 px per bar. No decode.
• 150 mm: FOV = 210 mm, so 9.1 px/mm and 2.3 px per bar. Marginal: clean prints read, worn ones do not.
• 115 mm: FOV = 161 mm, so 11.9 px/mm and 3.0 px per bar. Reliable.

A current 12 MP phone frame is about 4000 px wide. At 250 mm the same geometry gives 4000 / 350 = 11.4 px/mm, which is 2.9 px per bar, so the phone reads the same label at a comfortable arm's length. A 30 mm QR code carries 1.2 mm modules: at 400 mm the phone sees 7.1 px/mm × 1.2 mm = 8.6 px per module, which is why QR codes feel effortless while 10 mil barcodes do not.

The decision: keep 3 px per module and solve for stand-off. A 1080p web camera sits within 115 mm of a 10 mil code, a 12 MP phone manages from 250 mm, and anything with 1 mm or larger modules reads across a desk. Size your own case with the camera resolution calculator:

Rate and latency: what to plan for

Deliberate scanning is human-paced, and that is a feature. Budget it honestly:

• Stream and decode: 15-30 fps, so a steady aim decodes within 2-5 frames, or 70-170 ms.
• HTTP insert: 10-50 ms on a plant LAN.
• Confirm beep and re-aim: the rest of the second.

One deliberate scan per second per operator is the planning figure, and a service sized for a handful of transactions per second covers an entire crew. A scanner gun decodes within tens of milliseconds of its trigger, but in inventory work the human is still the pacemaker — which is why the camera the crew already carries is enough here. Where the rate must come from hardware instead of a thumb, read on.

Where the camera path wins, and where it fails

It wins wherever a person aims the device and the record matters more than the rate: inventory counts, goods receipt, work-order check-in, tool crib transactions — a full tool-crib workflow plan runs comfortably on this architecture. The row can carry the operator, the timestamp and the compressed frame (100-300 KB at 1080p), which a scanner-gun string cannot. QR-based traceability labels also fit; if codes will be serialized or registered, check the QR code registration requirements first.

It fails on three physical limits:

• Distance. The 3 px-per-module rule above: a 1080p camera cannot read a 10 mil code from across a rack aisle, and distance eats resolution linearly no matter how many pixels the phone has.
• Motion. Blur in mm equals speed in mm/s times exposure in s. A tote at 0.5 m/s (500 mm/s) under a phone's indoor auto exposure of 1/60 s smears 500 × (1/60) = 8.3 mm — 33 times a 0.25 mm module. Holding blur at one module needs 0.5 ms (1/2000 s), which indoor auto exposure will not deliver. Conveyor scanning is mounted-reader territory.
• Glare. Shrink wrap and glossy labels blank out auto exposure. Polarizing and image-side fixes are covered in 1D barcode preprocessing for rotation, blur and glare.

Fixed readers and smart cameras for the line

When the label moves or nobody aims, mount the decoder. A code-reading smart camera runs its decoder continuously, takes each read trigger from a photoelectric sensor, and sends the decoded string over Ethernet — to the PLC where the read drives a gate or diverter (mapping an Ethernet/IP reader into PLC I/O) and/or to your host service for the history table. Running both from one reader is the normal layout: control stays deterministic and the database gets the audit trail; the link-planning principles are in barcode reader to PLC communication.

For a bracket-mounted station, the MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a global shutter, a Fast Ethernet interface and an M12 lens mount. At 5 MP and a 4:3 frame you have about 2592 columns, so a 1 mm-module code still holds 3.2 px per module across an 800 mm field — enough to cover a full carton face at once.

Compact fixed stations for a decode-and-log post, straight from the smart camera range:

The first of these is a 1.6 MP mono vision sensor with a global shutter — the single-code, single-post station. The second is a 1.6 MP smart camera rated at 60 fps with a built-in 16 mm lens and integrated white light, so the bracket carries one part fewer. The third brings a 5 MP color sensor and a multi-color light source for colored or shiny labels.

Handheld readers for all-day scanning

When the same operator scans for a whole shift, aim-and-wait gets old and a single fixed lens fights glare. A pocket code reader with a trigger fixes both, and the software side does not change: the reader delivers a string to the same service. Pick the interface to match the host — wired USB, wired Fast Ethernet, or wireless for a tablet crew:

The first card above is a wired industrial handheld code reader with a Fast Ethernet interface, the choice where the reader should reach the host service over the plant network. The second covers the USB case. The LS-HCR-0002 is a 1.0 MP wireless handheld with a global shutter — the pocket option for a crew that works from tablets.

Store the string, not just the beep

The insert is where direct-to-database beats the PLC detour, because the service can refuse bad data before it lands:

• Validate server-side. Check the symbology check digit and a format rule before the INSERT; a misread that survives into the table is a traceability incident. Judging whether a decode is trustworthy covers the signal-quality side.
• Parse before you store. A GS1 string carries lot, expiry and part number in one payload; split it into real columns rather than one text field — parsing lot and part numbers out of a barcode string shows the split.
• Debounce. The same code twice within two seconds is one physical event; key the table so it cannot become two rows.
• Keep the pixels. Store the JPEG frame with the row so a traceability review can re-decode the label months later; why the image buffer must keep its pixels explains the resolution trap.

Three paths, three decisions

Inventory on the tablets you already carry: build the page and the service, post straight to the database, and drop the PLC from the logging path.

A shift-long picking crew: same service, same table; swap the camera for a triggered handheld code reader.

A conveyor or a gate: mount a smart camera or fixed reader, trigger it in hardware, and split the result — control to the PLC, history to the service.

If you are sizing the camera side of a fixed station, start from the camera finder, step through the system configurator, or ask us with your label samples and stand-off, and we will check the pixels-per-module arithmetic with you. The rest of the decode library lives in the code-reading guides.