Adding Cameras to a Semiconductor/PCB Inspection Line: The Interface Rewrites the Optical Design

When adding cameras to a semiconductor wafer or PCB inspection line, I look at the cable path before I look at the lens. GigE has fixed bandwidth and transmission distance, so frame drops appear as camera count grows; USB3 has short cable length, making layout difficult; CXP scales cost proportionally with camera count. Leave this unaddressed, and you end up lowering fps or resolution, opening up a risk that 10–30 µm-class defects leak straight through the line. SerDes-based interfaces have recently been proposed as an alternative, but this doesn’t substitute for optical-setup design. Surface reflectivity and securing WD come first.

The fps-versus-resolution trade-off that bandwidth creates

When camera count grows, the problem is the transmission path itself. GigE splits switch bandwidth among cameras, dropping per-camera fps; SerDes structurally supports long-distance, low-latency transmission by carrying multiple channels over a single cable, easing this bottleneck. That said, even with more bandwidth, fps and resolution can’t both be raised without limit. Raise pixel count relative to FOV, and per-frame data volume grows, so bandwidth sets the ceiling on fps — which is why interface margin matters more on a line needing high resolution, such as detecting 10 µm-class PCB defects.

Surface reflectivity first, interface second

Whichever interface is used, lighting and lens design still have to start from the target surface’s material and reflectivity. A semiconductor wafer is a specular surface, so low-angle coaxial illumination makes it easy to secure contrast, but a PCB mixes solder mask and copper pattern, where diffuse reflection varies by position, making it harder to handle. In practice, a PCB’s matte resin region has shown heavy diffuse-reflection variation, burying a defect in the background under the same lighting angle at one point — so a material like this has to be left as territory that cannot be confirmed before sample testing, with lighting angle and polarizer combinations pre-verified. Even if the interface opens up bandwidth, if the optical setup can’t create contrast, the algorithm never receives the signal to begin with.

Item	Spec
① Minimum detectable defect size	10–30 µm (PCB fine-pattern defect and wafer edge-defect baseline)
② Optical setup	Lighting: low-angle coaxial illumination + ring illumination in parallel, consider adding a polarizer for regions with heavy diffuse reflection (cannot be confirmed before sample testing) Lens: telecentric or high-resolution line-scan lens, 25–50 mm focal length WD: 80–150 mm secured (including space for lighting placement)
③ Algorithm parameters	Defect-candidate minimum blob size around 3–5 px, contrast-vs-background threshold 15% or higher, per-line processing-delay setting matched to target fps

As the table shows, defect size, optical setup, and algorithm parameters are all constrained in a chain, with interface bandwidth setting the fps ceiling. Swapping the interface isn’t a one-line change to the camera spec — it’s a job that redraws the entire matching table.

Field Checkpoints

That said, if there are three or four cameras or fewer, cable runs are short, and budget is limited, GigE or USB3 alone is often enough, and CXP still makes sense for ultra-high-speed line-scan with a small number of cameras. This judgment, too, cannot be confirmed until defect contrast and fps requirements are checked on actual samples.

Has the target surface’s reflectivity characteristics been checked first (whether specular and diffuse reflection are mixed)?
When deciding the lens spec, has WD (working distance) been secured including space for lighting placement?
When adding cameras, is the target fps within the interface’s bandwidth ceiling?
For regions with heavy diffuse-reflection variation, has the lighting-angle/polarizer combination been pre-verified on actual samples?