Choosing machine vision software for part recognition: a buyer's map

Choosing machine vision software for part recognition has a concrete threshold: at three or fewer part programs on one camera, buy a vision sensor or smart camera such as an MV-SC3050XC-16M-ATN-H and use the on-board pattern matching. From the fourth program, a second camera, an audit trail or acceptance rules of your own, move to a GigE or USB3 camera plus a vision controller running software you program.

The package is rarely what decides the outcome: part count, number of cameras, rotation tolerance and who maintains the line set the environment, and every serious environment then recognizes the part. This comparison maps the three real choices — a vision sensor with fixed optics and on-board matching, a smart camera with its own tools, and an industrial camera plus a vision controller running software you pick. You get the decision threshold, a comparison table, the pixel arithmetic that shows when resolution stops mattering, and a worked station with every number run through.

The decision, up front

For one part at one station, buy a vision sensor or smart camera and use the pattern matching that ships on the device; you will have a running station within a day. Write your own software on a camera-plus-controller path when any of these is true: four or more part programs on the line, a second camera feeding the same decision, images or verdicts that must be logged for audits, or acceptance rules you have to implement yourself. Between the two sit x86-platform smart cameras — your code, no separate computer.

The trade behind that threshold never moves. On-device software wins deployment time and wiring simplicity; a PC-based system wins headroom and the freedom to run third-party software, and it hands you a computer to patch, back up and keep alive for the life of the line. One fork comes even earlier: whether rules or a trained classifier should make the call at all. AI vs rule-based smart camera inspection settles that on the part's appearance, not on software preference.

What actually differs between the environments

On the PC path, the camera side is standardized: GigE Vision and USB3 Vision cameras expose their controls through GenICam, so a vision suite, a LabVIEW program or an open-source library can all drive the same sensor, and you can exchange them later without touching the optics. That portability is the quiet advantage of the open path. On-device tools are the opposite: they belong to the family you buy into, and the real switching cost of a smart camera is re-engineering the station around a new ecosystem, not the price of a license.

The time figures are planning numbers, not promises: they assume the lighting and mechanics are already right, which is where the first week usually goes.

The part requirements that move the choice

Rotation and symmetry. A part with near-180° symmetry produces the classic false match: the program locks onto the mirror pose. Tolerance settings fix it — pattern match flips 180 degrees: fix false hits and tolerance settings shows which knob. Set the angle tolerance to the smallest range that still separates your variants, and no wider.

Lighting stability. Normalized gray correlation drifts with illumination; edge-based matching does not. When ambient light reaches the station, control it first — ambient light variation in pick and place vision — and if it cannot be fully controlled, switch the matcher: edge based pattern matching for stable results when lighting changes.

Presentation scale. A matcher scores scale as well as shape, so teach the pattern with the part at its final height — teach pattern matching at final part height to keep scale right. Fixed-focus vision sensors depend on this most.

Appearance variability. Castings, textiles, food, anything grown: rule-based matching written against one appearance breaks on the next batch. A trained classifier is the right tool, and it can run on cameras you already own — adding AI surface defect inspection to existing cameras.

Color as the discriminator. When two variants differ only by color, gray-scale matching works the wrong axis; color pattern matching for reliable part localization covers the settings.

Irregular outlines. Parts with no stable silhouette shift the work from matching to segmentation before any matcher runs. Machine vision for irregular part identification and inspection works that case in depth.

The arithmetic that settles the sensor question

Before comparing environments, check whether resolution is a decision at all. Two formulas and one rule settle it.

Sampling theory puts the floor at two pixels across the smallest feature; a matcher holds its score under rotation and shading when you plan on four to five. Run your own numbers through the camera resolution calculator before paying for megapixels. When the margin is large — and on a single part it usually is — the sensor is settled, and the software environment is the only real choice left.

Worked example: a 60 mm cover at one station

Inputs, each with its source:

• Part: a 60 mm × 45 mm stamped cover with a 1.5 mm orientation notch — an example part sized like a typical first recognition project.
• Field of view: 80 mm × 60 mm, which leaves 10 mm of placement scatter per side on width and 7.5 mm on height.
• Sensor: the 5 MP class on a 1/1.45-inch format — a nominal image of about 8.8 mm × 6.6 mm, commonly laid out as 2,448 × 2,048 pixels.
• Working distance: 160 mm, set by the fixture.

The arithmetic:

1. Sampling: 2,448 px / 80 mm = 30.6 px/mm, so one pixel covers 1 / 30.6 = 0.033 mm of the part.
2. Notch coverage: 1.5 mm × 30.6 px/mm = 45.9, call it 46 pixels. Against the five-pixel planning floor that is 46 / 5 ≈ 9× margin.
3. Magnification: m = 8.8 mm / 80 mm = 0.11.
4. Lens: f = 160 mm × 0.11 / (1 + 0.11) = 17.6 / 1.11 = 15.9 mm, so order a 16 mm lens. Height check: 6.6 mm / 0.11 = 60 mm — the field of view height comes out exact.

Resolution passed by a factor of nine, so the sensor is not the decision. One part, fixed presentation, one pass/fail verdict: the on-device path wins, and your engineering time goes into teaching the pattern at final height and setting the angle tolerance. The day a fourth program, a second camera or an audit trail appears, the same station re-plans onto a camera plus a vision controller, and the lens, the light and the fixture all carry over.

The three environments, with real parts

Software on the device

Vision sensors keep the optics, the light and the matcher in one fixed-focus package and put a verdict on the wire — the shortest route from box to running station. Smart cameras add choice where it pays: lens mount, illumination, network. In our smart camera range, M12 dominates with 216 of 350 models, and 42 carry C-mount for standard machine-vision lenses.

A single-part station is the vision sensor's home ground:

The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a global shutter and an M12 mount on Fast Ethernet. One step up, the smart camera keeps the software on the device but opens the optics and the light source:

The MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with an 8 mm M12 lens on GigE; the MV-SC6050C-08M-XBN is a 5 MP global-shutter color model with a multi-color light source. The LS-SMC-0017 is an 8.8 MP global-shutter smart camera on an x86 platform with a C-mount — the open-platform class that hosts processing you write yourself.

Software on the controller

Here the camera is a sensor decision, not a software decision. Pick any sensor that fits from the camera finder; the software can change later because any GigE Vision or USB3 Vision camera speaks GenICam. Camera acquisition software compatibility: integration options maps the combinations, and how to migrate a legacy camera SDK to GenICam acquisition is the template when older code is already in the plant.

Two area-scan cameras show the range the open path accepts:

The first is a 6 MP mono GigE camera on a C-mount; the second is a 12 MP global-shutter USB3 model. The software bill lands on the controller, and some bundles settle it at order time:

The MV-VC3301H-128G66 is an Intel Core i3 vision controller with 8 GB of memory and a VM6200Pro license included; the MV-VC4712-256G10-2TH is listed without a VM license key, so the software is bought separately. Where several cameras meet one decision, the MV-SVC2506-16G60-128G gives you 4 camera GigE ports plus separate configuration and communication ports.

How to choose, case by case

• One part, static presentation, pass/fail verdict: vision sensor.
• Up to three programs on one camera, re-taught by a technician: smart camera.
• From the fourth program, a second camera, an audit trail or acceptance rules of your own: camera plus vision controller.
• Your plant already standardizes on LabVIEW: keep the code there, and read even smart-camera verdicts into it — smart camera LabVIEW integration: use inspection results as data.
• Policy or budget pushes open source: weigh the integration work first — open source machine vision software: integration tradeoffs — and check the license terms for a commercial line: open source vision software licenses for commercial use.
• The recognition feeds a robot grip: plan the pose output with the station, not after it — 2D vision pick and place: selecting a planar guidance system.

When the usual answer is wrong

The smart camera is the wrong default when the parts vary naturally — castings, forgings, wood, food. Rules written against one appearance break on the next batch; AI defect inspection for products with natural appearance variability is the fix, and it belongs on the open path or an AI-capable device.

The PC path is the wrong default for a single verdict with no programmer on site. You inherit patching, backups and an OS lifecycle, and use none of the headroom you paid for.

The vision sensor is the wrong default when presentation height varies — fixed focus means scale drift — or when the part needs a lens or a light the housing cannot take.

And any environment is wrong until the lighting is stable: no matcher out-tunes a flickering field.

Before you order

1. Count part programs and cameras three years out. On-device wins only at three or fewer programs on one camera.
2. Read the controller's license line — included or without key — and price hardware and software as one decision.
3. Confirm every camera on the open path is GigE Vision or USB3 Vision compliant, so the software can be exchanged later.
4. Plan hardware triggering, not software polling: hardware trigger source not detected: check GenICam line settings is the wiring map.
5. Name who re-teaches patterns on the floor, and match the environment to that person's tools.
6. Run the pixel arithmetic for your smallest feature; below about a 4× margin over the five-pixel floor, change the field of view or the lens, not the matcher.
7. Budget a day of lighting work before any matcher tuning.

When the counts point one way and the constraints another, start a system configuration or write to us through the contact page and we will size the station with you.