How a VisionMaster solution is built
HIKROBOT VisionMaster (written as HIKROBOT Vision Master software in some vendor material) builds an inspection as a graphical solution: tools are linked in a flow, from acquiring the image through locating the product, inspecting it and combining the results, to sending one result to the PLC. HIKROBOT describes tool groups for locating and measuring, identification, defect detection and registration learning, alongside deep-learning modules, and lists TCP/IP, Modbus, serial, UDP and EtherNet/IP among its communication protocols (HIKROBOT catalogue 2025 Q4). addaScan builds stations on VisionMaster for plants in South Africa as an independent integrator; this website does not claim any official HIKROBOT partnership or distributor status.
Tool groups and where each applies
These are the machine vision algorithms VisionMaster provides, in HIKROBOT’s groups. The tools in the second column are named as HIKROBOT lists them (HIKROBOT catalogue 2025 Q4). Where each applies, and its limits, is our engineering view.
| Tool group | Tools (HIKROBOT naming) | Applies to | Limit |
|---|---|---|---|
| Locating | Template and feature matching (pattern matching), mark locating, position fixture, blob analysis, circle, line, edge and rectangle search, caliper | Find the product or a feature so that every other tool follows it when the product shifts or rotates | Needs a stable, distinctive feature to lock on to |
| Measurement | Point, line and circle distance measurements, edge distance, intensity, pixel count, histogram | Dimensions, gaps and positions; fill level from an edge; cap height; label position | Accuracy depends on optics, calibration and presentation |
| Identification | 1D and 2D code reading, including deep-learning code reading; OCR, including deep-learning character recognition | Barcodes, DataMatrix and QR codes, date and batch codes, printed and marked text | Reading is not grading print quality |
| Defect detection | Deep-learning surface defect detection, contour defect detection, comparison with a standard part | Scratches, spots, dirt, broken edges, incomplete contours and character defects | Needs labelled defect images and a validation set |
| Registration learning | Register-classify, register-category and register-detect: online learning from a few registered images, on CPU or GPU | Variant and wrong-SKU checks, simple classification and detection without offline training | Suits clear differences; verify on unseen samples |
| Deep-learning modules | Classification, object detection, image segmentation and related modules in the deep-learning package | Variable defects on natural or textured surfaces, counting irregular objects, defect area measurement | More images, training and retraining effort |
Typical inspections and the tools behind them
Most packaging and parts inspections combine two or three tool groups. These are the combinations we use most often; the final choice is made on your samples.
| Inspection | Tools | Application page |
|---|---|---|
| Label present, straight, right SKU | Locating + measurement for position; registration classification or code reading for the SKU | Label inspection |
| Date and batch code correct and legible | Locating + OCR (deep-learning OCR on difficult print) + character comparison with the expected string | OCR/OCV inspection |
| Fill level and cap height | Edge search and measurement against a backlight | Fill level and cap inspection |
| Missing parts and counts | Blob analysis, pattern existence and counting; object detection for irregular items | Presence and counting |
| Scratches and marks on moulded or metal parts | Deep-learning defect detection, with locating first | Surface defect detection |
| Hole positions, diameters, gaps | Circle and line search, caliper, point-to-line and circle-to-circle measurement | Dimensional inspection |
| DataMatrix marked on parts | Deep-learning code reading with lighting for the mark | DPM code reading |
Which tools run on which HIKROBOT device
Not every device runs every tool. HIKROBOT’s capability table for its smart cameras shows the step-up by series (HIKROBOT catalogue 2025 Q4). VisionMaster on a PC or vision controller has the full tool set, including the VisionMaster deep learning package.
| Capability | SC1000 | SC2000E | SC3000X | SC5000X / SC6000 |
|---|---|---|---|---|
| Existence, count, basic measurement, logic | Yes | Yes | Yes | Yes |
| Pattern existence and count | No | Yes | Yes | Yes |
| OCR and character comparison | No | Yes | Yes | Yes |
| Code recognition, match location | No | No | Yes | Yes |
| DL classification and object detection | No | No | Yes | Yes |
| DL image segmentation | No | No | No | Yes |
| Module limit per solution | 20 | 40 | 40 | 1024 |
Rules, deep learning or registration learning
- Rule-based tools (locating, measurement, code reading, blob analysis) for faults that can be written as a measurement or rule. They are quick to validate and stable.
- Registration learning for clear differences learned from a few images, such as product variants, when there is no time or data for full training.
- Deep learning for defects that vary in shape and appearance on a variable surface, with labelled images and a retraining plan.
Most solutions mix them: locate with rules, read codes with rules, and use deep learning only on the region where fixed rules fail. See rule-based or deep learning and the commissioning procedure.
Build a tool chain that can fail safely
Start with the observable defect and the decision it needs. Locating is a separate decision from inspecting: when the locator fails, downstream regions must not keep using the previous product position. Set a valid-image flag, a valid-location flag and a completed-inspection flag, and require all of them before publishing a pass. A missing result is an unresolved inspection, not evidence of a good product. This is an engineering configuration pattern; the exact tool names and supported modules follow the installed VisionMaster version.
For a printed batch code, a useful chain is acquisition, package location, transformed text region, OCR, format validation, comparison with the authorised batch string, then result transmission. OCR confidence alone does not establish correctness. A clearly printed code from yesterday can have high recognition confidence and still be wrong. GS1 General Specifications section 3 gives the meaning and format of Application Identifier data when a GS1 code is involved; plain human-readable production text needs its own approved specification. (GS1 General Specifications, Release 26.0)
| Stage | Configuration record | Fault to inject |
|---|---|---|
| Acquisition | Trigger source, exposure, gain, light setting | Disconnect trigger or cover the lens |
| Location | Reference feature and allowed translation/rotation | Present a displaced or reversed product |
| Inspection | Region coordinates tied to location; expected data version | Use a valid-looking but incorrect batch |
| Decision | Explicit missing-result and timeout states | Disable one required tool |
| Transmission | Product identity and result acknowledgement | Delay or disconnect communication |
In a hypothetical recipe, the expected text is LOT-A while a challenge pack carries LOT-B. Both are readable; the comparison must reject LOT-B even when OCR succeeds. A blank pack tests a different path: failed recognition must not reuse LOT-A from the previous cycle. Save the original image, recognised text, expected text, location status and final result so a commissioning engineer can identify which step failed. The example defines logic only and makes no claim about attainable recognition performance.
Keep training images separate from acceptance evidence
When segmentation or classification is required, label defect boundaries and acceptable variation before training. Oil streaks, permitted mould texture and printing artwork can otherwise become accidental defect labels. Group images by physical product, production batch and capture session before dividing the dataset. Near-identical frames of the same damaged part must not appear in both training and acceptance sets: that tests recognition of a familiar image rather than generalisation to new production. Google’s dataset guidance distinguishes training, validation and test data and warns against overlap. (Google Machine Learning Crash Course: dividing datasets)
Use validation images to select thresholds, then freeze the model and inspect the reserved test set once. Report results by defect family and presentation condition. A pooled accuracy number can hide complete failure on a rare but important missing-component fault. Record both defective products accepted and acceptable products rejected, with separate denominators. If test images are used to tune the model, they become development data and another independent test set is needed. NIST’s proportion guidance explains why a finite test also carries uncertainty. (NIST e-Handbook, 7.2.4.1 Confidence intervals for a proportion)
Check the deployed runtime after training. A PC development environment and an embedded camera can have different supported operators, licences and processing resources. Archive the camera model, firmware, VisionMaster build, model file, solution file and a known test image together. GenICam standardises camera access, but does not guarantee that a proprietary algorithm solution or trained network is portable between vendors. (EMVA: GenICam)
| Observed problem | First evidence to examine | Correction to validate |
|---|---|---|
| Defects missed only after product rotation | Located pose and transformed region overlay | Correct the coordinate link, then retest rotated samples |
| Very good training result, weak line result | Batch/session split and duplicate images | Rebuild independent evaluation data |
| Unexpected pass after a tool error | Tool status and default output values | Require all mandatory checks to complete |
| Slow result on complex defects | Per-tool timing with image saving enabled | Reduce unnecessary regions or change architecture |
Check the tool chain against the real deadline
For a hypothetical line at 300 products per minute, each product interval is 200 ms. Measure the configured tool chain, communication and tracking under load against that interval and the available travel time to the reject. A catalogue frame rate is an acquisition limit, not an algorithm timing result. The following model rows illustrate why resolution and acquisition rate must be considered separately from solution runtime. (HIKROBOT Smart Product Catalog, 2025 Q4)
| Catalogue model | Resolution / maximum frame rate | What the algorithm trial must establish |
|---|---|---|
| MV-SC5050XM | 2432 × 2048 / 60 fps | Location, OCR and decision complete within the real deadline |
| MV-SC6050M | 2432 × 2048 / 80 fps | The same image size does not prove the same solution latency |