Smart Camera vs PC-Based Vision Systems

Motionwell Automation specifies both machine vision architectures on production machines in Singapore, and the smart camera vs pc based vision question usually gets asked one camera at a time when it should be asked one machine at a time. Our delivered inspection references sit on the self-contained and controller-based side of that line: Keyence IV3 vision on a 12-station rotary medical assembly machine running a 15-second cycle, with contour recognition, OK/NG auto-sorting and SCARA pick-off to reject bins, and Keyence CV-X420F vision controllers paired with CA-H200M 2-megapixel cameras at each station of a sensor panel assembly line, where the inspection routine completes in under 50 ms per station and more than 15 panel variants share one recipe layer. Both assembly builds run dome lighting, white LED arrays behind diffuser panels at 6500 K. Machines are designed, assembled and tested at our Woodlands Link facility, and the company has delivered more than 150 special purpose machines since 2014 under ISO 9001:2015 and bizSAFE Level 3.

The short version before the detail. The camera is not the unit of comparison. Compare the finished station, because a self-contained smart camera carries a processor per camera, so a job needing three views buys three processors, three device configurations and three recipe sets, and that can lose to one controller or one PC driving three heads from a single trigger and a single calibration. Then compare the decade after handover rather than the week of commissioning, because the two architectures ask very different things of the owner over that decade: a swapped body and a reloaded recipe against a drive image, a licence and a software version somebody kept current.

Where we stand, said plainly. We do not manufacture cameras, lenses, lighting or vision processors, and we do not write vision algorithms from scratch. We buy the platform and build the machine around it: the fixture, the lighting, the trigger, the PLC handshake, the reject device and the record. So we have no product to defend on either side of this page, and our delivered references are Keyence and Cognex rather than a general-purpose imaging stack. Camera and lighting selection, the optics arithmetic and the false-reject trade-off are on our machine vision inspection capability page and are not repeated below. If you have parts and a defect list, skip ahead and talk to an engineer.

What Are You Actually Choosing Between?

Three things, not two, and the middle option is often left off a shortlist framed as a binary. A self-contained smart camera puts the sensor, the optics, often the illumination and the processor in one body at the station. Keyence IV3 is the delivered example: built-in lighting, fast setup, self-contained, specified for presence and absence, orientation and simple pass or fail at a single point. It is a sensor with a verdict on its output.

A dedicated vision controller puts the processing in the cabinet and the camera heads at the stations. Keyence CV-X is the delivered example: multi-camera on one controller, high-speed processing and a large tool library, for multi-point inspection, high-speed lines and pattern matching. It is where many real machines land.

A general-purpose PC-based system runs vendor or third-party software on an industrial PC against standard cameras. Where an application needs non-standard optics or an existing in-house image-processing stack, a generic GigE Vision camera with third-party software is that alternative architecture. It buys flexibility and costs the integrated toolchain, the vendor support path, and usually several weeks of development.

Read the last two rows together: the bounded toolchain makes a smart camera maintainable by a plant technician, and the same property stops it doing what the vendor did not anticipate.

Why Does the Cost Comparison Only Mean Anything at System Level?

Because the camera is the cheap part, and what ends up on the invoice is a station rather than a body. Our published cost drivers are camera count and resolution, lighting complexity, whether the parts can be presented repeatably, and the scope of PLC and MES integration, with a single smart camera checking presence and orientation at the entry level and a multi-camera measurement station with custom optics and full line integration costing several times more. Every one of those is architecture-neutral: the light does not get cheaper because the processor moved into the camera body, and the fixture still has to be designed and machined either way. What the architecture changes is which items multiply when the station needs a second and third view.

The second row decides more of these projects than people expect. Three devices each holding their own copy of a recipe is three things that can be edited independently, and on a line running more than 15 variants that version control problem is real work. On our sensor panel assembly line the recipe layer covers robot paths, vacuum grip profiles and vision inspection parameters together, and changeover runs under 3 minutes with no mechanical adjustment, which holds because one recipe change touches one project. The build is in the vision-guided SCARA panel assembly case study. The counterweight is the bottom row: a controller or a PC concentrates the failure, so three stations go down together, while three independent smart cameras degrade one at a time.

How Much Processing Headroom Do You Need?

Enough for the algorithm you will have in year three, and the way to estimate it is not to guess at CPU load. Two constraints set the ceiling, and only one is processing. The first is optical, settled before any processor is chosen: resolution at the part is field of view width divided by sensor width in pixels, and you need roughly three pixels across the smallest feature for reliable detection and five or more to measure it. On our own published sizing table, a 20-megapixel sensor across a 400 mm field gives 0.073 mm per pixel, about 1.4 pixels across a 0.1 mm feature, and no processor recovers that. The answers are splitting the field between cameras, indexing the part in several positions, or line scan and motion. The arithmetic is in our vision inspection guide for electronics.

The second constraint is the tool budget inside the cycle. On the sensor panel line the vision routine completes in under 50 ms per station against a placement cycle under 0.5 seconds, so inspection never becomes the bottleneck. That headroom is what pays for the algorithm growing later, and it belongs in the specification as a number: measured routine time, cycle time available, difference stated.

Growth after commissioning is not hypothetical, and only some of it is solved by a faster processor. A new defect class appears because a supplier changed a surface finish, costing processing time and, on a validated line, a change control. A defect starts to resist description, so rule-based tools give way to a trained classifier, and that is a step change in processing demand rather than an increment. Somebody asks the camera that checks presence to also report a dimension, which needs more pixels and often a different lens, so it is an optical change rather than a software one, as set out on our inline dimensional measurement page. Or archiving gets added, which is a storage question belonging at design stage, covered on our surface defect inspection page. Ask which of those four is plausible in three years. If none is, headroom you paid for is money spent on a future that did not arrive.

What Changes When Several Cameras Have to See One Part?

Two things a per-camera comparison never shows: when the images were taken relative to each other, and what coordinate frame they are reported in.

Synchronisation. One trigger firing several heads means the views are of the same instant, which matters whenever the part is moving, whenever light from one station can reach another, and whenever the verdict combines views rather than collecting independent ones. Three self-contained cameras triggered separately from the PLC can be made to work, but everything downstream inherits the trigger’s jitter, and there are three trigger paths instead of one.

Shared calibration. Two cameras reporting positions in their own frames give two numbers that cannot be combined until something relates the frames. Inside one controller or one software project that relationship is part of the project. Across independent devices it has to be built elsewhere, normally in the PLC or the robot program, and maintained by whoever owns that code. That is not an argument that the distributed version fails, only that the work exists and belongs to somebody. Interfaces where two suppliers each assumed the other owned it are a common failure point on these stations.

Calibration discipline matters more when the vision result drives motion rather than a verdict. Camera-to-robot calibration is done as a multi-point calibration with verification runs, so accuracy holds across the whole working envelope rather than at the calibration point alone. Put that in the specification, because a single-point calibration passes a demonstration and fails an envelope.

A shared frame also ages badly, because a bracket holding a camera can drift and several cameras sharing a frame go subtly wrong everywhere rather than one station visibly out. The defence is a re-verification routine an operator can run on shift against a known artefact.

Where Is the Reject Decision Made, and How Long Does It Take?

In the same place under every architecture, which surprises people: the PLC owns sequencing, safety interlocks and reject control, and the vision system owns image processing. Keeping that split clean is what makes the machine debuggable two years later, and the chain does not change either. A sensor, encoder pulse or PLC output triggers the camera, a light fires, software runs its tools, and the pass or fail bit goes to the PLC over EtherNet/IP, PROFINET or digital I/O.

Delivered numbers give a sense of the budget. Keyence IV3 smart sensors carry a trigger time under 20 ms, CV-X routines on the sensor panel line complete in under 50 ms per station, the 12-station rotary assembly machine runs a 15-second cycle per part, and code print-and-verify on the GMP filling platform runs at up to 150 units per minute. Fifteen seconds of cycle is not a latency problem whatever architecture you choose. A station running at 150 units per minute, which is 400 ms per unit, with several tools to run is a different conversation, and it should be had with a measured routine time rather than a datasheet.

What follows the verdict causes failures that processing time never touches, and none of it depends on where the processor sits: carrying each result along with its part to the reject point, and proving the part actually left the line. Both are covered on our machine vision inspection capability page.

What Happens When It Fails, and Who Puts It Back?

This is where the two architectures differ in a way that shows up on a night shift, and it is a part often left out of the costing. When a Keyence or Cognex unit dies at 2 a.m., a technician swaps the body and reloads a stored recipe. When a PC-based system dies, someone needs the drive image, the licence and the right software version, and each of those has to exist, be current and be findable by whoever is on shift. Each also rots quietly: an image taken at commissioning does not contain the recipe changes made since, a licence bound to hardware may not activate on a replacement, and a software version two releases behind may no longer be downloadable.

Backup and restore of the program and the data, and power-loss recovery testing that pulls the supply mid-cycle to prove the machine restarts in a defined, safe state without corrupting the record, are both operational qualification items on the regulated machines we deliver, and both are worth running against the vision architecture rather than the PLC alone. Four questions settle it at design stage: who holds the image, how often it is refreshed after a recipe change, where the licence lives, and how the restored station is proven correct.

A smart camera is not immune to any of this. Its recipe still has to be stored somewhere that is not the device, its firmware version recorded, and a replacement body re-verified before it is trusted. The difference is one of degree and of who can do it, and the degree is large enough to decide projects.

What Does a General-Purpose Operating System Cost in a Validated Plant?

A qualification burden that has nothing to do with inspecting your part, which is why architecture is a regulatory decision on a validated line before it is a technical one. GAMP 5 sorts software by how much of it was written for you, because that is what decides how much you have to test.

The consequence is direct. A configured vendor toolset is Category 4, and supplier documentation can carry a good share of that burden where the supplier’s quality system has been assessed. Bespoke inspection scripts are Category 5, and nothing carries that burden except your own testing. On top of it, a PC brings a Category 1 operating system with an account lifecycle, a patching policy and an end-of-support date attached.

Patching turns that into a running cost. The mechanism that works is impact-scoped change control: for each patch, record what it modifies, whether anything it modifies is covered by a qualification test, and what verification closes the gap. Operating system and driver patches on an HMI PC usually touch no qualified function and need documented verification only, while changes to control logic, recipe handling or electronic records require the affected tests re-executed. That process is manageable, and it exists only because there is a general-purpose operating system in the machine at all.

Where the result is part of a regulated record, 21 CFR Part 11 applies regardless of architecture, and clause 11.10(h) asks for device checks on the validity of the data source: the record should carry which device produced the reading and whether it was in calibration at the time. What that asks of a PLC and an HMI is on our 21 CFR Part 11 for production equipment page, and the qualification route is on the computer system validation page. A vision PC is also another general-purpose device on the machine network, which puts it inside the zone and conduit design rather than beside it, as our note on IEC 62443 for machine builders explains.

What Do the Two Architectures Do to the Cabinet?

They put the heat in different places, and one of those places is easier to cool. Distributed smart cameras are low power and low heat, and what heat there is sits out at the stations. A PC adds the PC, its storage, a UPS if the record has to survive a power dip, and the thermal load of all three, so enclosure cooling has to be sized for it, and every cooling method is itself a maintenance item: a filtered fan is a filter to change, an enclosure cooler is a unit that fails quietly while the machine keeps running. Have that conversation at cabinet layout, not at installation.

Ingress is the mirror image. Processing hardware inside an enclosure inherits the enclosure’s rating, while a smart camera sits in the process environment and carries its own. Be precise about what a rating covers: electrical enclosures on our food-grade builds are rated IP65, which covers dust ingress and low-pressure water jets, so hose-down sanitation between shifts is fine. IP65 is not a high-pressure or steam-cleaning rating, and a sanitation procedure using high-pressure jets or caustic foam belongs on the specification before the station is drawn. Ask the same question of the camera, the window, the light and the cable glands separately, because a housing rated for the wash does not help if the cable entry is not.

Which One Ages Better?

Neither, and they fail differently, which is the useful part. A smart camera or a controller is a vendor product on a vendor lifecycle: the body gets superseded, the replacement is not the same part number, and a recipe exported five years ago may need a software version you no longer have. The mitigation is boring and effective. Store the recipe outside the device, record the firmware version in the handover pack, and buy the spare body while the model is current rather than when it has stopped.

A PC ages on two clocks, the hardware and the operating system, and the second usually runs out first. Ask for the end-of-support date in writing, because that is the number that determines your real patching horizon and the number that turns into a project three years later. We see the far end of this cycle constantly: control-system retrofit is our largest project line in 2026, replacing obsolete PLCs, drives and VFDs on legacy machines, and much of that work has a compliance driver rather than a mechanical one. The machine still runs fine; its controller cannot hold a user account. The same two clocks run on a vision PC, and the operating system clock is the one to ask about in writing.

When Is a PC-Based System Over-Engineering for the Job?

Often, and this section decides whether the rest of the page is worth trusting. These are the cases where a self-contained device is the right answer, not a compromise.

One view, one decision, one cycle. Presence and absence, orientation, a code read, a label check, a measurement at a single point. A self-contained unit with built-in lighting does this and a second processor buys nothing. Our delivered defect inspection on the 12-station rotary assembly machine is rule-based contour recognition with OK/NG sorting to reject bins, on IV3, inside a 15-second cycle.

Nobody has named who reads the archived images. Full-resolution archiving is a real requirement in some plants and a reflex in others. Three questions need answers before it drives the architecture: who reviews the images, how long they are retained, and what a stored image would prove. Without them the archive is storage cost and a backup obligation with no evidential value.

The plant has no software person, and will not have one. A trained technician can adjust a vendor GUI. A PC-based system needs somebody who writes software, and if that person is not on your site, the station’s response time is somebody else’s travel schedule.

The defect is describable. Rule-based tools are auditable: a threshold on a blob area or a contrast score can be read off, explained to your customer and re-tested on demand. Buying a general-purpose platform for a classifier you do not need trades a supported toolchain for unused flexibility.

You want AI, and assume that means a PC. It does not. Cognex In-Sight is where we point when a classifier is genuinely the right answer, because AI-based defect classification is what it is built for, and it is a smart-camera-class device.

The line is validated and the inspection is not a critical record. A general-purpose operating system brings Category 1 infrastructure, an account lifecycle and a patching policy into the qualification scope. Carrying that for a presence check is cost with no matching benefit.

The cabinet is full, or the environment is wet. A PC needs enclosure volume, cooling and a power strategy, and where none exists, distributing the processing to the stations is the smaller change.

When Is a Smart Camera Not Enough?

The same honesty in the other direction.

Resolution outruns the sensor. If the defect size and the field of view do not leave three pixels across the feature, the station cannot work, and the fix is more cameras, indexed positions or line scan rather than a better algorithm.

Several cameras must see one part in the same instant. One trigger, one calibration, one project, and building that across independent devices is work somebody has to own.

An archived image of every part is genuinely required. Onboard storage on a self-contained device is limited by design; full-resolution images to disk or a server is PC work.

The task cannot be expressed in the vendor toolset. A classification problem the toolset cannot describe, an unusual optical arrangement, or an in-house image-processing stack the plant already owns and validates. That is the case for a generic GigE Vision camera with third-party software, bought knowing what it costs. The same goes for growth you can already name, because headroom you can point at is worth buying and headroom nobody can describe usually is not.

One standing exclusion while we are being direct. We are not a vision algorithm house and we do not write image-processing software from scratch, so where the deliverable is an algorithm rather than a machine we are the wrong supplier and will say so at concept review.

Who Has to Maintain It After Handover?

This decides more than people expect, and it often gets asked last when it belongs in the first meeting. The question has three parts and only the first appears on a datasheet: who adjusts a threshold when the reject rate climbs on a night shift, who restores the station after a hardware failure, and who owns the change when the product changes. On a smart camera or a controller those can be the same trained technician in a vendor GUI. On a PC-based system the first might be, the second usually is not, and the third almost never is.

The handover pack has to match whichever answer you chose. Alongside the drawings, schematics and PLC program documentation that ship with every machine, a vision station needs the exported recipe stored outside the device, the firmware and software versions, the licence location if there is one, the calibration artefact and the routine for using it, and a written restore procedure somebody has executed once. Our own integrator selection checklist sets the bar for support at critical spare parts stocked locally or available within 3 to 5 business days, and the wider list of questions worth asking any vendor, including us, is in our guide to choosing an automation system integrator.

Which Should You Specify?

Run these in order. The first that gives a hard answer usually settles it, and where two disagree, the dedicated vision controller is normally the honest middle.

1. How many views does one part need, and must they be simultaneous? One view is a smart camera question. Several simultaneous views with a shared frame is a controller or PC question.
2. What is the smallest feature, across what field of view? Work the pixels first. Work the pixels first. An optical shortfall is not recoverable by any processor, whatever the architecture.
3. What is the measured routine time against the cycle you have? State the headroom as a number in the specification.
4. Does an image of every part have to be kept, and who reads it? If the second half has no answer, the first half is not a requirement yet.
5. Can you describe the defect, or only show examples of it? Only-show-examples points at a classifier, which does not by itself mean a PC.
6. Is the line validated, and is the result a regulated record? A general-purpose operating system carries a qualification and patching burden a configured toolset does not.
7. Who is in front of it at 2 a.m., and what are they allowed to do? If the answer is a plant technician with a vendor GUI, design for that person.

A mixed answer usually means one station needs an architecture the rest of the machine does not. Mixing them is allowed, provided somebody owns the boundary: which device holds which recipe, and which frame the numbers are reported in.

Frequently Asked Questions

Is a smart camera cheaper than a PC-based vision system?

Per camera, usually. Per station, not reliably, and the station is what you are buying. A self-contained unit carries its own processor, so a job needing three views buys three processors, three sets of vendor software, three network drops and three recipe sets to keep in step. One vision controller with three camera heads, or one PC with three cameras, buys the processing once and shares it. Our own published cost drivers are camera count and resolution, lighting complexity, whether the parts present repeatably, and the scope of PLC and MES integration. None of those four changes because the processor moved into the camera body.

What happens to a PC-based vision system when it fails at two in the morning?

That depends entirely on what you prepared before it failed, which is the honest argument for the smart camera. When a Keyence or Cognex unit dies, a technician swaps the body and reloads a stored recipe. When a PC-based system dies, someone needs the drive image, the licence and the right software version, and each of those has to exist, be current and be findable by whoever is on shift. Settle three questions at design stage: who holds the image, how often it is refreshed after a recipe change, and how the restored machine is proven correct before it runs product.

Do I need a PC to run AI or deep learning inspection?

Not necessarily, and that assumption drives a lot of unnecessary architecture. Cognex In-Sight is the platform we point at where a trained classifier is genuinely the right answer, because AI-based defect classification is what it is built for, and Cognex In-Sight is where we point when a classifier is genuinely the right answer, because AI-based defect classification is what it is built for, and choosing a classifier is a separate decision from choosing a PC. The prior question is whether you need a classifier at all: rule-based tools work when you can describe the defect, and a classifier earns its place when you can only show examples of it. On a validated line, a trained model also brings a defect image library you have to own and a revalidation story each time it is retrained.