At a glance
| Item | Detail |
|---|---|
| Customer | A secure-document fulfilment operation. Name and sector details withheld at our discretion. |
| Product handled | Sealed envelopes in several sizes, each with a printed barcode and a contactless card inside. |
| Checks per envelope | Camera check of the envelope and its window, barcode read, card read, match against the batch data file. |
| Outcome per envelope | Accepted to the collection hopper, or diverted to the reject bin; every decision written to the batch result files. |
| Vision platform | HIKROBOT machine vision image recognition, configured by our team. |
| Delivery | addanode led the project: requirement, specification, design review, factory acceptance and operating documentation. The line was built with a manufacturing partner. |
| Status | Factory acceptance test passed in August 2026, meeting or exceeding every agreed target. |
The brief
Each envelope in a batch carries a printed barcode and contains one contactless card. Before a batch leaves, every envelope has to be checked: is it the right card for the right record, is the envelope in a fit state to send, and is anything missing, doubled or mismatched? Checking this by hand, envelope by envelope against a data file, is slow, and a single mistake reaches the person who receives the envelope.
The customer asked for a line that takes a loaded stack of envelopes, checks each one automatically, sends good envelopes to a collection hopper and faulty ones to a reject bin, and writes a record of every decision.
Conditions and constraints
- Batch operation. An operator loads the reference data file for the batch from the site network, places the stack in the feeder and starts the run. The line signals with light and sound when it starts and when the feeder is empty.
- Variation between batches. Envelopes come in several sizes. The barcode position on the envelope and the card position inside it are fixed within a batch but can change from one batch to the next, so the line must be adjustable, manually or automatically.
- Limited floor space. The overall length of the line was fixed by the space available and confirmed in writing.
- Records the team can use. The result file is saved next to the source data with the processing time in its name, and results update on a display during the run. The customer preferred a Windows-based display for their workflow.
- Open points closed in writing. A clarification record listed each item as confirmed or still to be decided, such as where in the card's response the identifier sits and the exact rules for a valid camera match, with sample envelopes and cards requested before design was finalised.
The line
Hopper feeder, guided conveyor, camera station, barcode and card readers, a controller with Windows software that decides and records, a reject flap and two outlets.
Swipe sideways to see the whole drawing →
What the camera checks
The camera station compares each envelope with a template for the batch. It does not read identity; it checks that the envelope is fit to be read and sent. The checks were built with HIKROBOT machine vision image recognition. This website does not claim any official HIKROBOT partnership or distributor status.
Images are captured on the move: the line's I/O triggers the camera as each envelope passes, and the trigger delay was fixed on sample envelopes rather than calculated on paper. Operators work in a Windows vision application that loads the batch data file, shows live counts, keeps the images of rejected envelopes and saves the correct and rejected results as separate files for each batch. See code inspection for how code reading and verification differ.
Any change to exposure, trigger, regions or decision limits is validated on sample envelopes and recorded before use. This rule is written into the operating guide handed over with the line.
| Check | What fails it | Why it matters |
|---|---|---|
| Envelope window located | A window-recognition template finds the address window on each image | Every later check is made relative to the window |
| Barcode found in the window | Searched first in a local region of interest, then across the whole window | A shifted barcode is still found; a missing one is rejected |
| Barcode not blocked | A barcode covered by the insert or folded paper cannot be read | Tested at FAT with deliberately blocked barcodes |
| Envelope face up | Front or reverse side judged from the amount of dark barcode and character detail in the window | A reversed envelope is rejected before its data is matched |
Error handling
Every fault ends in a defined action and a recorded reason, so the result file explains each rejected envelope.
| Fault | Action |
|---|---|
| Barcode missing or unreadable | Reject; reason recorded |
| Card missing or unreadable | Reject; reason recorded |
| More than one card read in one envelope | Reject; reason recorded |
| Two envelopes matching the same record | Reject the repeat; flagged as a duplicate |
| Barcode and card belong to different records | Reject; both values recorded |
| Envelope reversed or barcode blocked (camera check) | Reject; image kept for review |
How acceptance was defined and tested
Acceptance was written into the project before the build, as a factory test and a site test with agreed pass criteria. The stages are the same as in how we deliver a project. The factory acceptance test (FAT) covered:
- Basic functions and throughput. Feeding, conveying, collection and reject mechanisms; barcode reading in both symbologies; card reading; data matching; the Windows operation, statistics, alarms and export; and average throughput against the agreed target.
- Error types. Envelopes with the barcode on the reverse side, a blocked barcode, a missing card, more than one card, and barcode–card mismatches or duplicate records.
- Error-sample and correct-sample runs. A run of deliberately faulty envelopes, where the pass criterion allowed almost no wrong acceptance, and a run of correct envelopes to record how many good envelopes the line lets through.
- Format changeover. Standard to small envelopes and back, with the parameters recorded for each format.
- Endurance. A continuous run of several hours with no major mechanical, electrical or software fault allowed.
Each test records summary results, with the raw result files, screenshots and the operating guides attached. Anything that did not pass goes into an issue list with an owner and a closure action. The PLC and reject integration guide explains tracking and confirmation in more detail.
Results
The FAT passed, and the line met or exceeded every agreed target. Every deliberately faulty envelope in the error run was rejected, with none wrongly accepted; every correct envelope in the correct-sample run was accepted; each error type was rejected; throughput met its target; both format changeovers returned to stable running; and the endurance run finished without a major fault.
The only issue logged was minor: envelopes loaded unevenly could slide in the hopper. It was closed with a loading procedure: square the stack with the barcode in the window, work it back and forth so it slides freely, and set the counterweight the right way round. That step is now in the operating instructions.
The measured figures belong to the customer and are not published without permission. We do not replace them with estimates.
What carries over to other projects
- Combine identity and condition. Code and card readers prove which item it is; the camera proves the item is fit to send. One decision needs both.
- Design for batch-to-batch change. If formats change between batches, per-batch settings and adjustable guides matter more than raw speed.
- Treat data errors as defects. Duplicates and mismatches in the reference data are rejected and recorded like physical faults.
- Test the failure cases on purpose. A run of deliberately faulty samples, one per error type, tells you more than a long run of good product.
- Write the operator's part down. The one issue found at FAT was about how envelopes are loaded, not about the software; the fix was a written loading step.
- Close open points in writing. A short clarification record, with samples requested early, prevents most late changes.