Run OCR standalone on an edge camera and publish results over HTTP

You want the date code or lot text read at the station, the result pushed straight to your MES over HTTP, and no host PC bolted next to every camera. That is a standalone OCR architecture: the decode runs on the camera's own processor, and the camera itself makes the network call. It works, but only when three things hold at once. The decode must run inside the camera's on-device inspection environment, the model and its buffers must fit the device's free memory, and that environment must be able to open an outbound connection. This guide gives you the feasibility test, the memory arithmetic that decides the model choice, an HTTP result contract that survives a network drop, and the bench test to pass before anything goes on the line.

The three checks that decide it

Work through them in order, because any one can stop the project.

1. Decode on the device. Smart cameras are built to run inspection on the device with no PC attached — that is the whole category, from compact vision sensors to x86 units. Confirm that the app or script environment for your exact unit can call text recognition and a network client from the same program, and read the free-memory printout its runtime or boot log gives you before anything else.

2. Memory. Model weights plus workspace plus frame buffers, against the reported free heap. The arithmetic is in the next section; it is the gate that kills more standalone OCR projects than optics ever do.

3. Outbound transport. If the device environment offers an HTTP client, the camera POSTs results itself and the architecture is done. If it only exposes TCP or OPC UA, the camera still works standalone — you change the transport at the receiving end, as in reading smart camera results over OPC UA into your control system or wiring the PLC as the client of a TCP-serving device, not by adding a PC per station.

If checks one and three pass, memory is the only real decision, and it is arithmetic you can run before you order anything.

Size the image before you pick the model

On-device recognition cost scales with the pixels you process, so the region of interest decides the budget. Text recognition stays reliable from about 20 pixels of character height and becomes comfortably accurate near 25-30. Below 20 px, confusable glyph pairs — 8/B, 5/S, 0/D — start eating accuracy, so treat 20 px as the floor and 25 px as the design target.

Worked example: a carton carries 2 mm tall lot text and the print zone is 40 mm wide and 10 mm tall. At 25 px per character the pixel size is 2 mm / 25 = 0.08 mm, so the field needs 40 mm / 0.08 mm = 500 px across and 10 mm / 0.08 mm = 125 px tall. Crop the ROI to 512 × 128 px around the print: 512 × 128 = 65,536 px, one byte per mono pixel, about 64 KB per frame.

Raw resolution is not the constraint — a 1.6 MP sensor spans roughly 1440 px, nearly three times the 500 px the field needs. The real work is setting the lens to deliver 0.08 mm per pixel at the part; every extra sensor pixel is only margin. The camera resolution calculator runs this same math:

For text on moving or glossy packaging, start from a global-shutter smart camera — the SC6000 unit below pairs one with an integrated multi-color light source:

Budget the memory before you commit

Model size is bytes per parameter times parameters. FP16 needs 2 bytes per parameter, so the transformer models built to read full pages — 1 billion parameters and up — want about 2 GB before any activation memory. Camera-class devices expose a user heap of tens to a few hundred MB, so full-page models are out, and the design target is a small, int8-quantized, line-level recognizer: int8 stores 1 byte per parameter, and a model with around 8 million parameters holds about 8 MB of weights.

Here is the budget, with declared example values — substitute your device's real free-heap report and your model's real parameter count:

• model weights, int8, 8 M parameters: 8 MB
• activation workspace, budget 2× the weights: 16 MB
• ROI frame buffers, 2 × 64 KB: 0.13 MB
• HTTP client stack: 2 MB
• total: 26.13 MB

On a device reporting 128 MB free, 26.13 / 128 ≈ 20 percent, leaving roughly 102 MB of headroom. The same stack on a 64 MB heap takes 41 percent and still fits; on 32 MB it does not, and the fix is a smaller model or a tighter ROI, not a bigger camera. Keep one headroom rule: stay at or under about 70 percent of the reported heap, because fragmentation and peak frames consume the rest. Load the model on the bench and read the allocation the runtime prints — that number, not a paper figure, goes into the budget.

When you would rather run a full desktop OCR stack than a stripped-down recognizer, the x86 route exists: the LS-SMC-0017 is an X86-platform smart camera with a 1-inch sensor, global shutter and C-mount, so the software build you already run on a PC is the build the camera runs:

Publish each result with an HTTP POST

This is the push side of camera networking — the reverse of grabbing frames over an HTTP snapshot URL, where you pull images from a camera; here the camera pushes text out and keeps decoding while it does.

1. Agree the contract. JSON over POST with a fixed field set. The example below is an illustrative contract, not a vendor API — agree the real field names with the receiving system before anyone writes code.

2. Use POST, not GET, for results. A result is data with a body: device ID, sequence number, timestamp, text, confidence, verdict. Text in a query string breaks on long strings and makes retries ambiguous. Keep GET only for a dashboard polling the last stored result.

3. Set timeout and retry. A 2-5 s timeout and three retries with 1, 2, 4 s backoff absorb a restart of the receiving service. The receiver deduplicates on device ID plus sequence number, so a retried POST can never double-count a part.

4. Queue when the link is down. Cap the queue at a size the device holds comfortably — 1,000 results at roughly 200 bytes of JSON is about 200 KB — and forward with the original sequence numbers after reconnect. A camera that runs for days will hit this; the smart camera network failure recovery guide shows what a long-run network fault looks like in practice.

5. Archive evidence on a separate path. The text result goes by POST; images are bulky and belong elsewhere — on-board flash first, as in storing camera images on embedded flash, or straight to remote storage, as in barcode inspection image archiving to cloud storage.

6. Log the last acknowledged sequence number, so a power cycle knows where it stopped.

The example contract, request line and body only:

POST /api/v1/ocr-results HTTP/1.1
Host: mes.example.local
Content-Type: application/json

{"device_id": "OCR-L3-04", "seq": 18423,
 "ts": "2026-01-15T10:22:31Z",
 "text": "LOT 24115B", "confidence": 0.94, "verdict": "OK"}

Prove it on the bench before the line

Three passes, then a failure pass.

• Good parts. 100 known-good parts, three times over: expect 300 decodes with confidence above your threshold and 300 accepted POSTs.
• Bad parts. 100 blank or garbled parts: expect zero OK verdicts leaving the camera.
• Latency. Add the stages: exposure 0.27 ms, on-device inference, LAN POST 1-5 ms. Start from 20-60 ms for a small int8 line recognizer on camera-class silicon, measure it on your unit, and use the measured number. With a 40 ms measurement and a 3 ms POST the worst case is about 44 ms; even at 70 ms the camera supports a line running about 14 parts per second (1 / 0.070 s).

Then pull the network cable for five minutes mid-run: the camera should keep decoding, queue every result, and on reconnect deliver the full sequence range with no gaps.

If good parts decode all afternoon and then drift, lock exposure and gain by hand — the runtime camera parameter control guide shows the settings — and set every recognition parameter explicitly rather than trusting defaults; the OCR trains-but-fails guide walks through which ones matter.

When standalone OCR is the wrong tool

If the marking is a DataMatrix or a barcode rather than plain text, do not OCR it. A fixed code reader decodes codes outright and hands you the string over the same network paths:

Second, a hard PLC interlock with deterministic timing is a controls problem, not an HTTP problem. A standalone camera can push to an OPC UA server or a TCP listener, but if the machine cycle needs a guaranteed verdict within a few milliseconds, carry the verdict on fieldbus at the receiving end instead of stretching HTTP to do it.

Third, when you want a self-contained text check at every station on a long line, a vision sensor keeps each point independent — decode and POST from one small box per station:

The order and go-live checklist

Before ordering:

• Get the free-heap report for your exact unit and firmware; the budget only counts when the heap number is real.
• Quantize the model to int8 and measure loaded size plus workspace on the bench, not on paper.
• Check the shutter against the part motion: global for anything moving.
• Match the interface to your network — Fast Ethernet and GigE both appear across the smart camera range, so pick one switch standard.

Before go-live:

• Crop the ROI to the print zone; every cropped pixel is buffer and inference time saved.
• Lock exposure and gain manually; auto modes drift between light and dark labels.
• Agree the JSON contract and the dedupe key with the MES side.
• Set timeout, three-strike backoff, queue cap, and last-acked-sequence logging.
• Run the bench set: 300 good reads, 100 bad, the latency budget, and the five-minute cable pull.
• Stage a spare unit with the same firmware and model, so a line restore is a swap, not a rebuild.

Where to start

Open the camera finder and filter by shutter, interface and resolution — the ROI math above almost never needs more pixels than the smallest unit offers. Then walk the configurator from the camera step:

If you want the memory budget and the POST contract checked against a specific unit before you commit, the contact page is the fastest route. More push-side patterns — OPC UA, TCP, FTP and archiving — sit on the cameras topic page.