A 100 units/minute inspection line requires the complete capture-to-reject cycle to stay below 100 milliseconds, making end-to-end latency the primary compute-sizing criterion [S3].
Camera count alone does not determine requirements: resolution, model complexity, frame rate, buffering, PLC I/O, lighting, and line speed determine whether one industrial PC, multiple accelerators, or dedicated smart-camera processing is appropriate [S1][S2][S4].
Frame rate sets the first compute floor
A camera delivering 300+ frames per second must transfer and process images fast enough for real-time inference, which makes interface bandwidth, memory throughput, and accelerator latency first-order design constraints [S2].
For fast-moving parts, short exposure suppresses motion blur but raises the required light level. That demand pushes system design toward controlled illumination and, where appropriate, global-shutter sensors [S2]. A vision light source that is poorly positioned can force a longer exposure, so shutter time cannot be specified independently of the optical setup.
Compute planning should begin with two measurements: required inspection rate and maximum acceptable latency. The first sets the minimum number of camera captures per second, while the second determines whether processing can be pipelined. KEYENCE describes high-speed cameras and image processors as capable of acquiring multiple images under different lighting conditions fast enough for 100% inline inspection [S1].
Resolution and model type drive processor demand
Inspection runs through four stages: image acquisition, pre-processing, inference, and decision logging, with the result, image, and timestamp sent to a MES, PLC, or QMS [S3]. Pre-processing may include morphology, segmentation, and edge detection before object detection, anomaly detection, or defect classification runs on the image [S3].
A useful comparison is by inspection method rather than camera count. Rule-based vision is suitable for deterministic measurement and code reading; deep learning handles appearance defects; anomaly detection can be trained on good parts alone and flags deviations from the learned normal population [S4]. A classification task that labels one frame as good or defective generally creates less output work than pixel-level segmentation, while multi-camera cell ownership increases synchronization, buffering, and fault-tolerance requirements [S4][S5].
Resolution should be derived from the smallest defect that must be detected, not from a preference for 4K. A high-resolution frame increases both transferred bytes and arithmetic performed per inference. Conversely, software-first systems can use a phone camera and cost less than 1,000 euros in hardware, while legacy high-precision and high-speed stations typically cost 15,000–60,000 euros [S3].
Compare smart cameras with PC-based edge systems
A smart camera is the economical option for one fixed, well-defined check, while a custom system becomes attractive when the inspection product is the core capability, multiple lines or products must be supported, or the manufacturer requires ownership of the model and data [S4].
The method decision must also account for deployment speed and the total system cost, not only accelerator performance. Every inspection system, including a 3,000-dollar smart camera and a custom multi-camera cell, follows the same basic pipeline, although the compute architecture and ownership differ [S4].
Latency failures show up as delayed decisions
A slow inference pipeline produces a visible symptom: the PLC receives a valid result after the part has passed the reject point. The root cause is usually insufficient end-to-end budgeting across image acquisition, preprocessing, inference, decision logging, and actuator response, not merely an undersized GPU [S3].
Corrective action starts by measuring each stage separately and recording frame timestamps. If acquisition alone misses the required cadence, reduce exposure, improve lighting, change the trigger arrangement, or select a faster camera. If acquisition is fast but inference is late, reduce input resolution, simplify preprocessing, select a smaller model, or move eligible work to dedicated accelerators [S2][S3].
Do not repair a repeated-result or out-of-sequence-result condition by increasing compute alone. First verify camera clocking, trigger wiring, image-buffer ownership, and application sequence handling. Dedicated GPU systems using x16 PCIe Gen3 links are one established industrial-PC architecture for real-time inference, but interface capacity does not remove the need for correct synchronization [S8].
Acceptance testing must use production conditions
Vendor accuracy figures of 97–99% represent favorable-condition ceilings rather than guaranteed production performance, and the operating result depends on the balance between defective parts escaping and good parts being rejected [S4]. Acceptance testing should therefore use representative parts, installed optics, production lighting, actual line speed, and both known-good and known-defective samples [S4].
Three acceptance measures should be recorded: the percentage of units inspected, end-to-end latency from trigger to PLC decision, and escape and false-reject rates. For a 100 units/minute line, the cited latency target is below 100 milliseconds [S3]. For continuous video, the camera-selection requirement is 300+ fps when the application truly needs those frames for real-time inference, not as a generic camera preference [S2].
Laboratory results do not establish production acceptance. Industrial systems must tolerate vibration, dust, temperature swings, and shift changes, so lighting consistency and software drift require monitoring over the operating campaign [S3]. If a defect cannot be resolved in the captured image, stronger compute will not recover it; optics and illumination must be corrected [S4].
Code readers and controllers need deterministic I/O
Industrial inspection often includes barcode or 2D matrix reading, OCR, presence checks, assembly verification, and dimensional inspection [S3]. These tasks add decoding, character recognition, or geometric measurement to the inference stage, while the result must still reach a PLC or MES within the control cycle [S3].
A code reader with integrated decoding may fit a defined identification task. A vision controller is relevant where trigger sequencing and pass/fail outputs must be coordinated with reject hardware. The compute design must preserve timestamped order from acquisition through the output command, especially when the inspection counter meter and PLC count must remain aligned [S3].
Rule-based code reading, deep-learning defect classification, and anomaly detection should not be treated as interchangeable model classes. Rule-based systems measure and read codes deterministically, deep learning judges visible cosmetic defects, and anomaly detection flags departures from trained-good examples [S4]. The first two require clear defect definitions, while the last needs representative normal data and a defensible acceptance threshold.
Compute procurement follows the production duty cycle
A defensible sizing package should list camera resolution, frame rate, trigger rate, sensor format, model type, preprocessing operations, target latency, retained images, and simultaneous camera count. GPU memory alone is not a complete specification because sustained image throughput, preprocessing cost, synchronization, and I/O can become the binding constraint [S2][S8].
Start with one representative camera and one production workload, then measure the full pipeline. If a 100 units/minute line cannot complete the capture-to-decision cycle within 100 milliseconds, the acceptance test has failed regardless of nominal GPU performance [S3]. Expansion to several cameras should proceed only after the single-camera baseline demonstrates stable timing, repeatable accuracy, and correct PLC sequencing.