OCR label parsing to PLC: folder watch, database lookup, Modbus TCP

A raw-material label photographed at goods-in has to become an internal RM code in the PLC without anyone typing. This plan covers the chain on one machine: the camera's FTP client drops each label image into a watched folder, an OCR agent on a vision controller reads the manufacturer, supplier RM code, lot, length, width and weight, a local database converts the supplier code to your internal code, and a Modbus TCP register block carries the result to the PLC. You get the 32-register map, the ASCII packing arithmetic, a latency budget, a controller tier for a single camera, and a write design that keeps working once the cell sits behind a data diode.

How the chain runs, end to end

Seven steps, one owner each:

1. The operator button fires the camera's hardware trigger input.
2. The camera exposes and its FTP client uploads the JPEG to a folder on the controller.
3. A folder watcher on the controller picks up the completed file.
4. The OCR engine reads the six fields from per-field crops.
5. The agent looks the supplier RM code up in the local cross-reference database.
6. The agent packs a 32-register block and writes it with Modbus function code 16.
7. The PLC checks the sequence counter and checksum, then books the internal RM code.

Two networks, one crossing point. The camera talks FTP to the controller only; the controller is the only device that speaks to the PLC, so the firewall rule — and later the data diode — belongs exactly there. The write side follows the same register-handshake pattern as sending vision results to a PLC, and the vision controller Modbus guide covers the connection set-up in depth.

Trigger, capture and the label pixels you need

Wire the button into the camera's trigger input, not into the agent. If the agent hangs, the camera still photographs every label and keeps uploading, so nothing is lost during a restart — the same argument that favors GPIO triggering over free-run on code readers. Pick a sensor whose communication list includes an FTP upload client; the smart cameras category is built around this fixed, triggered, one-image-per-press job.

Size the sensor from the smallest character, not from the label:

Give every character at least 20 px of height: 300 DPI, the input resolution OCR engines are tuned for, is 11.8 px/mm. Example: a 120 mm field on a 2,592-pixel sensor gives 2,592 / 120 = 21.6 px/mm, so a 2 mm character is 2 × 21.6 = 43 px tall and the smallest readable text works out at 20 / 21.6 = 0.9 mm. At a 300 mm field the same sensor drops to 8.6 px/mm, and the same math points you to the area scan cameras category at a higher pixel count.

A 120 mm label field on a 2,592-pixel sensor lands right at the 20 px/mm threshold, so that is the working example here. The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a global shutter and an M12 mount — the right shape for this job. Mount it square to the label and let the label fill at least 70% of the frame width: margin you leave empty is pixels you threw away.

Sizing the controller that runs the agent

The workload is light — one image per press, six crops, one indexed query, one Modbus write — so most vision controllers clear it. Three things actually sort the list:

• Two or more Ethernet interfaces, so camera FTP and PLC Modbus sit on separate ports.
• Archive storage: the database is a few megabytes, but every parsed label should keep its photograph, and images add up.
• CPU headroom for a second camera or an AI check later; the CPU vision loop sizing guide works that math.

For a single camera behind a diode, the MV-VC2140-128G40-1T is the fit: an Intel N-series CPU, 8 GB of memory, a 128 GB SSD plus a 1 TB HDD for the archive, and 3-4 LAN ports to keep the two networks apart. The MV-VC3301H-128G66 moves up to an Intel Core i3 CPU, 5+ LAN ports and a PCIe slot, and includes a VM6200Pro license if you want a commercial runtime under the agent. The MV-VC5525-256G70-NN is the multi-camera tier, with PoE camera ports so cameras power over the link.

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The OCR agent: folder watch, fields, fail-closed

Watch for file-close or rename events — inotify on Linux delivers them directly — never for file existence. An FTP server writes a JPEG over tens to hundreds of milliseconds, and a watcher that fires on creation reads a half-written file. Poll with a size-stable check at 200 ms where file events are not available.

Run the OCR per field, not on the whole label: six crops, each with its own character whitelist — digits plus a few letters for the codes, digits only for length, width and weight. A modern LSTM-based OCR engine reads printed label text well at the pixel density above. Whitelisting buys more accuracy than any threshold tuning.

Commit to thresholds and fail closed: reject a field under 80% confidence and the supplier RM code under 90%, tuned on 20 sample labels per supplier. On a fail, write the status word with the match bit clear and leave the internal-code registers at zero — the PLC blocks goods-in rather than booking a wrong code. Move the failed image to a failed/ folder with the status in the name so the operator can re-press; archiving images outward is the same pattern as pushing NG images to an HMI over FTP.

The local RM database that updates without a line stop

Keep the cross-reference as one SQLite file on the controller: a supplier_rm table keyed on the supplier code, so the lookup is a single indexed read under 5 ms. No shared drive, no live-edited text file, and no update that ever takes the lookup offline.

Update by shadow swap. The master system exports a timestamped snapshot; the agent imports it into a shadow table inside one transaction and swaps the table names. Readers never see a half-loaded set, and the previous snapshot stays on disk as a rollback point — keep the last three. Archive with the data: every parsed label stores its image, raw OCR strings and matched internal code under the lot number, which answers "which label produced this booking" without touching the PLC. The parameters-in-PLC-versus-PC-database trade-off is worked through in the barcode parameter lookup guide, and the PLC lookup-table verification pattern is its PLC-side mirror.

The Modbus TCP register block

Roles first: the controller is the Modbus client and writes; the PLC is the server and holds the block in its holding-register map. Holding registers are 16 bits each; the application protocol specification defines function code 03 for reads, 06 for single writes and 16 for multiple writes. Strings travel as ASCII, two characters per register, high byte first.

Two for sequence and status, four strings of eight to sixteen characters, three numeric fields, one checksum, six reserved. The map:

The 0.1 kg step reaches 6,553.5 kg in one register; length and width reach 65,535 mm. A longer field takes two registers — decide now, because the PLC programmer scales against this map once.

Worked example. The label reads: manufacturer SUPPLIER-0214, supplier RM code S-48213, internal RM code RM-10244, lot L240517A, 1,250 × 640 mm, 18.5 kg. Match succeeded, so register 0 = 47 and register 1 = 1 + 2 + 4 = 7.

The internal code packs as: 'R' is 82 and 'M' is 77 in ASCII, so register 2 = 82 × 256 + 77 = 21,069; then '-1' = 45 × 256 + 49 = 11,569, '02' = 48 × 256 + 50 = 12,338, '44' = 52 × 256 + 52 = 13,364. S-48213 is seven characters, so pad it with a space to eight before packing. Length goes straight in at register 22 = 1,250; weight scales as 18.5 / 0.1 = 185. One FC16 write carries all 32 registers — 64 bytes of data — in under 10 ms on a plant LAN.

Budget the button-to-PLC path:

Air gap and the data diode

A data diode passes traffic one way, and Modbus TCP is request-response: no return path means no acknowledgement, no retry, no handshake. Design the write to survive being deaf:

• Repeat the block. The agent writes all 32 registers once a second and advances the sequence counter only when a new result arrives. A fresh counter with a good checksum means current data; a frozen counter means nothing new.
• Watchdog on the PLC. If the checksum fails or the counter freezes past a timeout, the station faults on the PLC side, where the operator sees it.

Put the diode between the cell and the plant network, not between controller and PLC, unless the plant is the untrusted side. If the goal is office-to-cell hygiene instead, a firewall rule permitting only controller-to-PLC Modbus gets most of the benefit — the controller-to-PLC ports and firewall guide lists the rules to write.

Checks before you build

• Trigger wired to the camera input, not the agent — images still upload during an agent restart.
• Folder watch on file-close events, 200 ms size-stable poll as fallback — half-written JPEGs are the top OCR failure source.
• Character whitelist per field — a bigger accuracy gain than threshold tuning.
• Fail-closed status word — the PLC never books an unmatched code.
• Shadow-swap database import — updates never take the lookup offline.
• Sequence counter and checksum in the block — a diode write has no acknowledgement to rely on.
• PLC watchdog on both — stale data must stop the station, not pass silently.
• Register map agreed with the PLC programmer, weight scaling included — the map is a contract, and changing it later is a PLC project.
• Twenty labels per supplier through the full chain before go-live — thresholds and whitelists get tuned on real print, not on paper specs.

Parts in this build and the next step

One vision sensor with trigger input and FTP client, one vision controller with separated LAN ports and archive storage, the SQLite cross-reference file, the OCR agent and a Modbus client library. The camera and controller in this guide do the job as specified: walk the system configurator from camera to controller, browse more register-level patterns on the systems topic page, and if the register map or the diode design wants a second pair of eyes, the contact page reaches the applications team.