Choosing a Machine Vision Toolchain: Halcon, VisionMaster, OpenCV, YOLO — Which Scenarios Each Fits
Vision projects stall less often because the algorithm library is thin, and more often because a tool was chosen before the scenario was clear. Defects you can write as rules, and defects you can only learn from samples, take two different paths. This article maps Halcon, Hikrobot VisionMaster, OpenCV and YOLO against scenarios — what each fits, which prerequisites to prepare, and the conditions outside the brand choice that decide whether the station actually works.
Fix the scenario first, then pick the tool
The first question is not "which vendor's software", but whether the defect this station must judge can be written as rules. Oversize, a missing screw, an unread barcode — geometry, contrast and template matching can encode those. Surface scratches that change shape, flaws in fabric texture, whether an assembly motion complies — those are hard to enumerate as rules and usually need sample training.
Get this split wrong and swapping tools later will not save the project. Pushing deep learning onto a rule scenario turns sample collection, labelling and model upkeep into a lasting burden. Writing rules for appearance defects that keep changing shape leads to false calls and misses that make inspectors switch the system off.
- Describable by rules: size, position, presence/absence, barcode and character reading — conventional algorithms fit
- Hard to enumerate: appearance defects that change shape, textured backgrounds, whether a motion sequence complies — needs samples and deep learning
- Mixed stations are common: the same station may measure size and look for surface flaws; run two toolchains in parallel rather than forcing one to cover everything
What each of the four toolchains fits
The comparison below follows engineering work we have actually taken on, not vendor marketing. Industrial machine vision development covers Halcon, Hikrobot VisionMaster (VM), OpenCV, YOLO deep learning and related toolchains. Per scenario we take on appearance defects, dimensional measurement, positioning guidance, OCR, assembly error-proofing and packing inspection across general manufacturing stations, and fold vision data into the traceability chain.
- Halcon: a complete algorithm library for rule scenarios such as dimensional measurement, positioning guidance, geometry and morphology; highly engineered, and it fits stations with explicit repeatability and calibration requirements
- Hikrobot VisionMaster: graphical configuration, standard inspection items are quick to stand up, and it fits line-side engineers maintaining part of the inspection flow themselves; it sits close to the Hikrobot camera and lighting ecosystem
- OpenCV: high freedom, easy to embed in an existing HMI or MES client; it fits projects that already have a software architecture and only need a vision-judgment module; both algorithms and the engineering framework have to be built in-house
- YOLO and similar deep learning: fits appearance defects and object detection that rules cannot enumerate; samples, labelling standards and compute must be in place, and someone has to keep maintaining false calls and misses after go-live
Toolchains, scenarios they fit, and prerequisites to prepare
Put "what it fits" and "do not start without these prerequisites" in the same table and selection becomes practical. Missing any one prerequisite stretches the project timeline, usually outside the software itself.
| Toolchain | Scenarios it fits | Prerequisites to prepare first |
|---|---|---|
| Halcon | Dimensional measurement, positioning guidance, geometric judgment, stations with explicit calibration requirements | Optics and calibration plan, measurement repeatability targets, engineers familiar with this algorithm library |
| VisionMaster | Standard appearance inspection items, stations that need graphical maintenance on the line | Stable imaging conditions, inspection items that split into a graphical flow, someone on site who can edit the flow |
| OpenCV | Embedding into existing software, custom judgment logic, deep integration with the HMI | An existing software architecture and development team, capacity to build algorithms and the engineering framework in-house |
| YOLO and similar deep learning | Appearance defects that change shape, object detection, judgments that rules cannot enumerate | Enough samples, labelling standards, inference compute, a mechanism to keep maintaining false calls and misses |
The same station can run two toolchains together. For example, size on Halcon, appearance on YOLO, with both judgments written into the same traceability record. Do not sacrifice the reliability of each judgment just to cover everything with one tool.
Five things outside the brand choice that decide whether it works
- Lighting and fixtures: light angle, colour, polarisation and part-location repeatability often decide whether detection stays stable more than the algorithm does; leave these unset and any toolchain is a gamble
- Write the NG standard in words: what counts as a defect, how borderline samples are handled, who may change thresholds — agree this in writing before acceptance, or quality and process will argue after go-live
- Accumulate samples from the real line: deep learning in particular depends on samples after changeovers, material swaps and shift changes; lab photos do not represent the floor
- Cycle-time constraint: time from trigger to OK/NG must be shorter than the station cycle, with margin for mechanical motion; a system that overruns will be switched off on site
- Vision results must enter the traceability chain: judgment, NG capture, station, part ID and timestamp written together, or later complaints and quality analysis cannot use them
On the assembly error-proofing line, capability has to be stated by route; a blanket claim that "AI-SOP is already mature" is not one we make. HkVisionPro multi-layer assembly, layer-by-layer feature-point inspection — automatic flow-through when the current layer is all OK, NG alarms with capture and evidence archiving — is deployed. The OrpaonVision motion-recognition standalone route is close to commercial use, but still requires scenario acceptance against workstation data, cycle time and acceptance criteria; it must not be written as already delivered at scale. The OrpaonSOP Hikrobot VM plugin route is still in R&D and joint validation, and is not offered as a standard deliverable. Accuracy must be confirmed in scenario acceptance against the specific station, samples and acceptance criteria; this article makes no numeric claims.
Summary
There is no single vision toolchain that fits every station. Rule-clear cases go to conventional algorithms; shape-changing appearance goes to deep learning; sites that already have a software architecture can embed OpenCV; line-side teams that want to maintain the flow themselves can look at VisionMaster. Listing scenarios and prerequisites first, then matching toolchains, is steadier than locking a brand and hunting for a scenario afterwards.
If the station is still unclear, start with scenario acceptance on one station: settle lighting, fixtures, NG definitions and cycle-time constraints, then decide the toolchain and the pilot scope.
Discuss scenario acceptance for a vision station
Tell us the station type, the defects to judge and the current imaging conditions, and we can propose a toolchain comparison and a pilot scope.
Contact Us