Smart camera vs PC-based machine vision.

A smart camera puts the sensor, the processor, the I/O and often the lighting and a motorized or liquid lens into one housing. You configure it from a laptop or browser, it stores the job internally, and it talks directly to the PLC or robot over EtherNet/IP, PROFINET or Modbus TCP. Cognex In-Sight and Keyence's VS series are the familiar examples, and both now run AI tools on the camera next to conventional rule-based tools.

A PC-based system splits the job. Machine-vision cameras (often called area-scan or "dumb" cameras, though there's nothing dumb about a good sensor) stream raw images over GigE Vision, USB3 Vision or CoaXPress to an industrial PC. The PC runs a vision library, often a GPU for deep learning, and a fieldbus card or network connection to the cell. The cameras follow the GenICam standard, so the software can usually control cameras from different makers the same way.

The deeper difference is where the image goes. On a smart camera, the image is processed where it's formed and only the result travels. On a PC system, the full image travels to a central computer, which is both the cost (bandwidth, cabling, a PC to maintain) and the benefit (one place with lots of compute, every camera's image available to combine, and a natural point to archive everything).

That framing answers most of the later questions. If each view can be judged on its own and nothing needs combining, the smart camera's architecture fits. If views have to be combined, or the compute per image is heavy, the PC's architecture fits.

The four interfaces trade bandwidth against cable length and complexity. GigE Vision runs on ordinary Ethernet, reaches 100 m, and can power the camera over the same cable (PoE), which is why it's the default on most cells. Its ceiling is low: a single 5 MP camera saturates it at about 23 fps. USB3 Vision roughly triples that and is cheap and simple, but passive cables are short, a few meters, and a cabinet-mounted PC is often farther away than that.

10GigE brings ten times GigE's bandwidth over the same 100 m reach on Cat 6A, at the cost of hotter cameras and a 10G network card. CoaXPress is the high end: 12.5 Gb/s per coax link at CXP-12, links that can be bundled (two or four per camera), power over the coax, and deterministic delivery into a frame grabber. It's the choice for line-scan, high-speed web and high-resolution area cameras.

One rule we apply on every PC-based design: give each high-bandwidth camera its own port or its own grabber link. Sharing a GigE port between cameras that trigger at the same moment is a reliable way to drop packets and get partial frames.

Headroom

A smart camera's processor is sized for the jobs its maker expects. That's plenty for a pattern match, a few calipers and a code read on a 2 to 5 MP image in a few tens of milliseconds. It runs out when the job grows: higher resolution, dozens of tools, large search regions, or a deep-learning model on a big image. Then the cycle time stretches, and there's no upgrade path short of a faster camera.

A PC's headroom is something you buy. More CPU cores run more tools in parallel, a GPU runs larger models, and when next year's part adds three inspections you can usually add them without touching the camera. The flip side is that the PC is a general-purpose computer: background updates, antivirus scans and other software can take CPU time at the wrong moment. Validated vision PCs are configured to prevent that, and someone has to keep them that way.

Multi-camera synchronization

When a part needs four views (top, two sides and an end), the views usually have to be captured at the same instant, on the same part, and judged together. On a PC system this is natural: one hardware trigger line fires every camera, all images arrive at one computer, and the software combines them into one result for one part ID.

Smart cameras can be triggered together too, but each camera judges its own view, and combining four results for the same part falls to the PLC. That works well when the views are independent ("is the label present, is the cap on"). It gets awkward when the decision needs information from two views at once, such as a dimension that spans two fields of view or a 3D measurement merged with a 2D inspection. As a rule of thumb, at three or more cameras on one decision we start drawing a PC.

On the smart-camera side, Keyence's VS series runs AI segmentation, detection, classification and OCR on the camera next to rule-based tools. Cognex In-Sight cameras run edge learning and deep learning on the device, and Cognex's OneVision platform (generally available since May 2026) trains models in the cloud and deploys them to In-Sight cameras, with inspection running at the edge. AI-first makers such as Overview.ai build cameras around NVIDIA Jetson-class modules and retrain on the camera itself.

On the PC side, the GPU is the limit, and it's a much higher one. Cognex's VisionPro Deep Learning, for example, supports NVIDIA GPUs only and recommends 10 GB or more of GPU memory for training. MVTec HALCON's deep-learning and anomaly-detection tools run on PCs and on embedded platforms. A PC can run several models per part, on full-resolution images, from several cameras, and train on site without an outside connection.

For more on choosing between AI and rule-based tools in the first place, see deep learning vs rule-based vision.

Smart cameras are built for the point of use. Many are sealed to IP67 (Keyence lists its VS series as IP67), take 24 V DC, and need one or two M12 cables. Mount it, aim it, wire it. In a washdown food line, a foundry or next to a coolant-flooded machine tool, that matters more than any processing spec.

PC-based systems split the environment problem in two. The cameras can be just as tough, with IP67 housings or protective enclosures, but the PC needs a cabinet with controlled temperature and filtered air. GPUs in particular dislike heat, and an industrial PC in a 45 °C cabinet next to an oven will throttle or fail early. Every camera also needs a cable run back to that cabinet, within the interface's reach, routed through the cell's cable chain if the camera rides on a robot.

Robot-mounted cameras are a special case. Fewer, lighter, more flexible cables favor a GigE camera with PoE (one cable) or a compact smart camera. A USB3 cable on a moving arm is a reliability problem, and a CoaXPress cable is a heavy one.

A smart camera's price includes the processor, the software license and often the lighting and lens. For one view, that's usually the cheapest complete answer, and the engineering hours are low because so much is integrated. But every extra view is another full smart camera, so cost grows roughly linearly with views.

A PC system starts with a fixed block of cost: the industrial PC, often a GPU, a software license (per PC or per runtime), network cards or frame grabbers, a cabinet slot, and more engineering hours to build and validate the application. After that, each additional camera is just a camera, a lens, a light and a cable. Somewhere around three to five views on one decision, the per-view math usually tips toward the PC, though that crossover depends heavily on the specific products and the deep learning involved.

Don't forget lifecycle cost. A smart camera is replaced as a unit with a stored job file. A PC has an operating system and drivers with their own support lifecycles, and a GPU model that may not be available in five years. Budget for spares, a disk image of the validated PC, and the hours to requalify when hardware changes. The camera is rarely the expensive part of a station, as we lay out in Cognex vs Keyence.

Maintainability

The smart camera's strongest argument is that someone in the plant can own it. A controls engineer can open the job, adjust a threshold, re-teach a pattern and save, and the camera keeps its job through a power cycle. Swapping a dead unit means mounting the spare and loading the job file.

A PC application built on a library is software. It needs source control, a build, someone who can read the code, and documentation good enough that the next engineer can change it. Commercial libraries come with support; OpenCV-based stacks come with whatever your team wrote.

IT ownership

A smart camera looks like an industrial device to IT: a fixed IP address on the machine network, firmware updates when the vendor ships them, and little else. A vision PC looks like a computer, and plant IT will reasonably want to know who patches it, whether it runs antivirus, whether it's on the domain, and how it's backed up.

Settle that before the PC is ordered. Our usual answer: the vision PC lives on the cell's isolated network, is not on the corporate domain, gets updates only in planned windows followed by a revalidation run, and has a full disk image stored so a replacement can be running in an hour. If your plant can't accept a PC on those terms, that's a real point for smart cameras.

Vision sensors

Below the smart camera sits the vision sensor: a camera sold and configured more like a photoelectric sensor, built to answer one question with a few tools. Keyence's IV series and Cognex's In-Sight 2800 class are typical. They're the right answer for presence, orientation, color match and simple classification, and they're often the cheapest way to replace a human glancing at a part. They are not a smaller smart camera: the tool set is deliberately limited, and outgrowing one usually means replacing it.

Hybrid: smart cameras feeding an edge PC

Many of the cells we build combine both architectures. Smart cameras handle the deterministic jobs where they're strongest (code reading, presence, a gauge) and report directly to the PLC with low latency. They also send their images to an edge PC, which runs the deep-learning models that need a GPU, combines views where needed, archives every image with its result, and feeds MES or SPC. If the PC goes down, the fast checks keep running; if a camera fails, it's swapped like any other sensor.