One of the nicest parts of working independently is that I get to talk to many different manufacturers and customers about the problems they’re trying to solve. Over the last few years, three of those conversations have stuck with me.

The first was at a facility where the final product was stress-tested on a rig that repeated the same action over a million times. The problem was that when a part broke, someone had to be there to notice and switch the machine off by hand; so they were effectively paying a person to sit and watch a machine. It got so expensive that they stopped running overnight testing and tested only during the day. And then, of course, someone asked: “Can’t we just put a camera on it and use some AI to switch it off when the part breaks?” I hear that question a lot.

The second was a plastic moulding company. Every now and then, their white beads were contaminated, and the only way they caught it was by hand: someone checking more than seven thousand final products to pull out the bad ones. You can imagine the overhead.

The third wasn’t even my conversation to start with. A customer had returned a batch of filter threads because the tolerances were off, annoying for the customer, who just wanted the threads to work, and painful for the supplier, who had to sort it out.

What all three have in common is that something is still being checked by hand, and the moment you push the throughput up, either bad parts start slipping through or the people doing the checking get tired and miss things. And this is exactly where good projects and expensive mistakes both begin — with someone in a meeting saying, “Can’t we just put a camera on it?”

First, a word on why I’d ever tell you not to

Here’s something worth keeping in mind before you ask anyone about this. Nearly everyone you’ll talk to gets paid only if the answer is yes: the camera supplier sells you a camera; the integrator sells you a build. That’s not a criticism; it’s just how it works, but it’s worth knowing which way everyone’s leaning.

One of the benefits of being independent is that I don’t sell cameras. I get paid to work out whether a system will work, and quite often the most useful thing I can tell a customer is “don’t.” So, take this as a second opinion from someone who hasn’t got a box to sell you.

The real question usually isn’t which system to buy. It’s whether to buy one at all, and you can normally find that for a fraction of the final price, instead of finding out the hard way for fifty thousand pounds. If successful, the feasibility study serves as the basis for the final solution (no need to reinvent the wheel or start from scratch).

What is machine vision, really?

It’s worth being clear about this, because it shapes everything else. Machine vision is a physical system, not just clever software. It’s one or more cameras, lighting, a lens, a computer, and a decision that gets sent back to the line: a pass/fail, or a measurement. The job is to produce a controlled, repeatable image of a known part, under conditions you’ve designed on purpose, and then make a judgement about that image.

The one thing I’d ask you to remember is this: the system can only judge what made it into the image. If the lighting didn’t reveal the defect, no amount of software will put it back – garbage in, garbage out. Almost everything else in this post comes back to that one idea.

Why you can’t just buy it off the shelf

This is the bit that catches people out, and I think understanding it early makes everything else click into place. A checkweigher is a product. A barcode scanner is a product. You buy it, you bolt it on, it works. A vision system isn’t quite like that. The camera, the lens, the lighting and the software are all just components; the actual system gets built and tuned around your part, your defect, your line. And chances are nobody has built exactly yours before.

Two parts that look almost identical can need completely different setups. A matte housing and a shiny one of the same shape want totally different lighting. A defect that shows up as a colour change and one that’s a fraction of a millimetre out of tolerance need different cameras, lenses and logic. There’s no datasheet that tells you “yes, this will work on your part,” because honestly nobody knows until they’ve put your actual part in front of a camera.

That’s why there’s usually some uncertainty at the start, and that’s completely normal; it isn’t someone being evasive. (The one time I’d be a little wary is if a supplier hands you a firm fixed price before they’ve even seen your trickiest parts.) The shift that helps is to stop thinking “which product do I buy?” and start thinking “what’s the cheapest way to find out whether this is even solvable, and roughly how?” You’re commissioning a small piece of engineering, not buying a box, and once you see it that way, a feasibility study stops looking like an added cost and starts looking like the obvious place to begin.

When vision is a good fit

If the task is genuinely visual, vision is worth a serious look. Basically, if a human eye can already do the job and you just want it done faster, more cheaply, or without someone getting tired and missing things (people are notoriously bad at missing things that aren’t there; I’ve had conversations about this, too). It works well when the job is repetitive, and the volume is high enough that the numbers add up, or when it’s simply beyond what a person can do: measuring to a fraction of a millimetre, checking thousands of parts a minute, keeping objective records you can trace back later. The one thing that must be true is that the feature is reliably visible under conditions you can control, and “controllable” is doing a lot of quiet work in that sentence.

When it probably isn’t

Just as often, though, a camera is the wrong tool for the job:

The property isn’t visual. If you care about weight, internal cracks, chemistry or temperature, then a checkweigher, an X-ray or a thermal sensor will do a far better job. Don’t use a camera to weigh something.

There’s a cheaper sensor that already does it. If you just need to know whether one obvious thing is there, that’s a job for a £20 photoelectric sensor, not a vision system.

The defect isn’t visible or isn’t defined. If a person can’t see it in a good image, software won’t either. And if your own inspectors don’t agree on what counts as a defect, that’s a specification problem that no system will fix for you.

“Good” is subjective. Cosmetic judgements – does this look premium, is the finish nice enough, with lots of acceptable variation are genuinely hard to pin down and easy to get wrong.

The volume just isn’t there. For low-volume, high-mix work, a person with a simple jig and a go/no-go gauge often wins.

And while I’m on it: AI is offered as the answer to almost everything these days, but for many problems, a simpler, more traditional bit of software does the job with far less complexity.

The demo always works

Something worth knowing: vision looks brilliant in a demo. It nearly always does. The real question is whether it works on your line, on your worst parts, at your actual cycle time, for a price that pays back. The parts that catch a system out are exactly the ones nobody thinks to send for the trial, the dirty ones, the wet ones, the ones from a different batch. A “yes” based on a handful of nice clean samples will breeze through the Factory Acceptance Test (the check done at the supplier’s site, usually called the FAT) and then fall over at the Site Acceptance Test (the SAT, on your actual floor).

How to take the risk out before you spend

The cheapest thing you’ll ever buy on a vision project is a feasibility study. It’s a small fraction of the system cost; it gives you a straight go/no-go, and when the answer is no, it’s just saved you the whole budget. Suppliers are usually happy to lend cameras and lenses for a few weeks, so you can try things before committing to anything, which keeps the risk to a short trial rather than a full order.

Whether you do it yourself or bring someone in, it really comes down to five questions. They also make a handy checklist you can run on your own project right now:

1. Can a person reliably see the feature in a raw image? If not – stop. It’s a lighting and optics problem, not a software one.
2. Can you define pass and fail in a measurable way, with real examples of good and bad? If not, sort the spec out before you buy anything.
3. Would a cheaper, non-camera sensor do the job? If yes, buy that instead.
4. Do the volumes and the return stack up? If not, a person with a gauge might be the better answer.
5. Can you get a clean image of your worst parts — good, bad, marginal, dirty, across different batches? If you’re not sure, trial it before committing.

A couple of other things worth deciding up front. You’ll need to make a conscious choice between letting the odd bad part through and rejecting the odd good one — “catch 100% of defects and never reject a good part” isn’t a real thing, and nobody should promise it. When you budget, budget for the whole system, not just the camera: mounting, lighting, guarding, communications, integration, training, and someone to keep the lens clean and recalibrate it when it gets knocked. The camera is usually the cheap bit.

Back to those three examples

It’s worth running the three I opened with back through those questions, because they land in three completely different places.

The white beads are close to a textbook, yes. It’s high-volume with over seven thousand final products checked by hand, and it’s exactly the sort of repetitive, tiring job that vision is good at taking off people’s hands. The only real question is the first one: is the contamination reliably visible under lighting you can control? If it is, this is a strong candidate, and I’d want a short feasibility trial to confirm the contrast before anyone spends a penny.

The filter threads are the tricky one. It’s tempting to just point a camera at them, but thread tolerance is really a measurement problem, and a lot of it might be better handled by a thread gauge or a profile measurement than by a camera. This is question three in action: before anyone quotes you a vision system, it’s worth working out exactly what you’re measuring, and whether something simpler already does it. This one might not be a vision job at all.

The test rig is the clearest “hold on a minute.” “Put a camera on it and use AI” is the instinct, but a part breaking under load usually gives itself away in ways that are cheaper and more reliable than an image: a drop in force, a spike in motor current, a limit switch, or a change in vibration. Is a break-even best spotted visually, or would a simpler sensor catch it for a fraction of the cost? If the question is why/where the product broke, then having a recording of the moment, maybe in combination with detecting a drop in force, can provide the image data and automatically stop the system safely.

Conclusion

None of this is me trying to talk you out of vision; it’s the opposite (I love the variety it offers and the challenges which come from it). I want it to work when you do spend the money. Most of the reason vision has a patchy reputation is projects that should never have been started in the first place, and every honest “no” protects the “yes” further down the line.

Next time, I’m going to open a failed project and go through it to see where the vision went wrong and why the reason everyone writes down afterwards is almost never the real one.

If you have any questions/ideas about machine vision, drop me a line: raffaella.riccato@hypersphere-consulting.co.uk.