Machine vision project cases
Records of real projects, written so an engineer can judge whether the approach fits their own line.
Each case describes a real addaScan project: the brief, the conditions and constraints, the line or station we built, what the camera checks, how faults are handled and how acceptance was defined. Customers are not named. Measured results are published only with the customer’s permission; where we do not have it, the case says so rather than giving an estimate.
Projects
More cases are added as projects finish and customers agree to what may be shown.
Envelope verification and sorting line
Camera check, barcode and card reading, data matching, reject and a record of every decision. Passed factory acceptance, meeting or exceeding every agreed target.
Case summary
Problem, checks, acceptance and outcome for each published case. Results are stated in words; the figures belong to the customer.
| Case | Problem | What is checked | Acceptance tests | Outcome |
|---|---|---|---|---|
| Envelope verification and sorting line | Every sealed envelope in a batch had to be checked against a data file before dispatch. By hand this was slow, and a single mistake reached the recipient. | Camera check of the envelope window, barcode position and face-up orientation; barcode read; card read; match of both against the batch data; reject with a recorded reason. | Factory acceptance: basic functions and throughput, each error type, a run of deliberately faulty envelopes, a run of correct envelopes, format changeover both ways, and an endurance run. | Passed factory acceptance in August 2026, meeting or exceeding every agreed target. One minor loading issue, closed with a written loading step. |
What a case record contains, and what it leaves out
Every case follows the same structure, so cases can be compared. The right-hand column is what we hold back, and why.
| Part of the record | What it contains | What is left out |
|---|---|---|
| The brief | The problem, and why the customer needed a solution. | The customer’s name and details that would identify the customer or its sector. |
| Conditions | What shaped the design: product variation, space, data, operators. | Details that would identify the project, such as data-file names, device models, budget and schedule. |
| The solution | A schematic of the line or station, with what each part does. | Photographs of the site unless the customer has approved them; drawings are marked as schematics. |
| Acceptance | How the station was tested at the factory and on site, and against which agreed criteria. | Any stage we hold no record for: it is left out, not assumed. |
| Results | Whether each agreed target was met, in words. | Throughput, accuracy and savings figures without the customer’s permission, and estimates in place of results. |
| Lessons | What carries over to other projects. | — |
How cases are published
Why are customers not named?
Why do the results contain no figures?
What does “passed factory acceptance” mean?
Will a case tell me what my line would achieve?
Have a line that needs checking?
Describe the product, what has to be caught or verified, and the line. We reply within two working days.