Vision Software and Algorithms
The software layer: deep-learning defect models, rule-based judgement, recipe management and the reporting that makes results traceable.
This Category positioning
Vision software that trains and infers on the machine itself: algorithm library, sample management, result traceability and interfaces
Vision software and algorithms are the layer of the whole visual inspection system responsible for "has it understood, has it judged correctly". It has three parts: the algorithm library (presence/absence judgement, template matching, feature measurement, character recognition OCR, code reading, deep learning segmentation and classification, anomaly detection), the software functions (recipe management, sample annotation and training, result recording and traceability, permissions and logs), and external interfaces (I/O, TCP, RS485, Modbus, S7, Profinet). The equipment for this project performs training and inference locally and does not need to upload images to an external server.
Hardware determines "whether the image can be captured clearly", Software determines "whether the judgement is right and whether it stays right". A vision system on a production line is typically used for three to five years, during which product model changes, material batch changes, and natural light source degradation all occur. The software must support these changes rather than requiring new development each time.
So the core capability of this type of solution is not "how advanced the algorithm is", but three things: whether algorithms can be combined per task (the same station performs both presence/absence judgement and character recognition), Can parameters be managed per product recipe? (switching models without reprogramming), Can results be archived for traceability? (so images and judgement basis can be reviewed when problems occur).
Another thing that is often overlooked is sample workflow: From acquisition, annotation, training and validation through to deployment, and retraining after deployment. How smoothly this flow runs directly determines how long a new project takes to introduce and how much manpower later adjustments require.
This Category Solution
Existing Solution Pages and Reserved Solution Slots
This type of solution is subdivided by inspection object and material. The table below lists the solution pages already built; the remaining sub-solution slots are reserved and will go live once the materials are complete.
inspection Scope
What is typically inspected for these problems
| Capability Category | Algorithm / Function | Typical Use |
|---|---|---|
| Presence/absence and position | Template matching, feature matching, Blob analysis | Part presence/absence, position check, and orientation judgment |
| Measurement | Geometric measurement, contour extraction, sub-pixel fitting | Dimensions, spacing, angles, notches |
| Recognition | OCR character recognition, 1D / 2D code reading | Inkjet code verification, batch traceability, code reading |
| Deep learning segmentation | Defect segmentation (pixel-by-pixel localization) | Appearance defects with variable shapes |
| Deep learning classification | Defect classification and grade judgement | Defect classification and grading |
| Anomaly Detection | State modeling based on normal samples | Scenarios where defects are hard to enumerate |
| Recipe Management | Save and switch parameters by product model | Mixed-model production, quick changeover |
| Samples and Training | Acquisition, annotation, training, validation | New project introduction and later iterations |
| Results and Traceability | Result recording, image archiving, logs and permissions | Quality traceability and review |
| External Interfaces | I/O, TCP, RS485, Modbus, S7, Profinet | Interlocking with PLC and production line systems |
inspection Object
Common inspection objects and materials
Typical defect
Defects These Solutions Mainly Target
| Software-Related Stages | Frequently asked questions | Focus Points |
|---|---|---|
| Recipe Switching | Parameters not synchronized after changeover, old recipe used by mistake | Recipes are bound to product identifiers; changeovers are logged |
| Sample Management | Insufficient samples and missing borderline samples | The sample library must cover borderline cases and be maintained over the long term |
| Threshold Maintenance | Thresholds not adjusted per batch after go-live | Keep a re-judgement and retraining channel |
| Result Archiving | NG images not saved, so problems cannot be reviewed | NG images and judgement items must be archived |
| Interface Integration | Communication protocol mismatch, handshake timing problems | Confirm the PLC model and protocol at the solution stage |
| Permissions and Logs | Parameters changed by mistake with no record | Parameter changes require permission control and operation logs |
inspection Method
Combined Route of Imaging, Algorithm and Judgement
Algorithms Combined by Task
Multiple algorithms at a single station
- Rule-based algorithms handle stable, explainable measurement and matching
- Deep learning handles segmentation and classification of defects with variable shapes
- Anomaly detection covers scenarios where defects are hard to enumerate
On-Device Training and Inference
No reliance on external servers
- Sample annotation, training, and validation on the equipment
- Inference runs locally; the production line does not depend on the internet
- Training with a single sample enables fast deployment
Recipes and Changeover
Changeover without reprogramming
- One set of inspection regions / parameters / thresholds per model
- Recipes can be imported and exported for easy multi-machine synchronization
- Switching records go into the operation log
Results and Traceability
Any judgement must be explainable afterwards
- OK / NG + judgement item + position
- NG images archived, supporting re-judgement
- Results can be uploaded to MES or exported locally
inspection workflow
- 01 Sample collection (including boundary samples)
- 02 Annotation and sample library setup
- 03 Choose the algorithm route and train / tune parameters
- 04 Validation set testing and threshold tuning
- 05 Recipe setup and on-site trial run
- 06 Go-live operation and result archiving
- 07 Periodic re-judgement and retraining maintenance
Applicable Industry
Which Industry These Solutions Are Installed In
This Category Document Checklist
Confirmed items and outstanding items
| Information Item | Description | Status |
|---|---|---|
| Solution Pages in This Category | Dedicated page for the software platform / algorithm modules (currently a placeholder) | To be added |
| Software name and version | Official product name and version number | To be added |
| Supported cameras and channel count | Supported camera models and maximum count | To be added |
| Labeling and training tool documentation | Labeling method, training time, whether incremental training is supported | To be added |
| Deployment Environment Requirements | Hardware configuration, operating system, whether an external server is needed | To be added |
| Licensing and upgrade method | Licensing model, upgrade and maintenance policy | To be added |
| Custom Development Interface | Data export, interface documentation, SDK availability | To be added |
| Software interface screenshots and description | Real interface screenshots and feature descriptions | To be added |
Common Question
Common Questions About This Type of Solution
Is the Vision Software Supplied with the Equipment or Sold Separately?
This project is delivered as a complete machine: vision software and algorithms are supplied together with the equipment and include an algorithm library, recipe management, sample training, and result traceability; no third-party vision software needs to be purchased separately. The specific licensing and upgrade terms must be confirmed in the contract (to be supplied).
Does training have to be done on the equipment?
The equipment for this project supports On-Device Training and Inference, which means the production line does not depend on an external server or the internet during operation, and sample data does not have to leave the site. For complex projects that need a large number of samples, experiments can also be run in another environment first, with the final model deployed to run on the equipment.
How many samples are needed for training?
Depends on the algorithm approach and defect complexity, There Is No Single Number. Rule-based algorithms basically do not need samples, only parameter tuning; deep learning segmentation / classification usually needs a sufficient number of samples for each defect type, and must include boundary cases; anomaly detection needs only normal samples, but must cover the natural variation of the normal state. The number of samples is best confirmed gradually through trial runs rather than fixed in advance.
Can the algorithm learn new defects on its own?
Not fully automatic. New defects need Manual confirmation and labeling before they can enter the sample library and take part in training. This step cannot be skipped — otherwise the system treats what it is unsure about as a new defect, which in fact causes a large number of false calls. The sensible approach is to keep a manual re-judgement step and add items flagged as suspicious by the system to training only after they are confirmed.
Will Software Updates Affect Parameters That Are Already Tuned?
Upgrades need to be handled with care, because a change in algorithm version may affect thresholds that have already been tuned. The reasonable approach is to back up recipes and the sample library before upgrading, then re-test with the validation set after upgrading and put it into production only after confirming there is no regression; for important production lines we recommend keeping a rollback plan. The specific upgrade strategy must be confirmed with the supplier.
Can It Integrate with an Existing MES or Quality System?
Yes, integration is possible; the specific method depends on the interface capability of the target system. The common approach is for the equipment side to pass results (time, part number, judgement, defect type and image path) to the upper-level system via TCP or a database write. The interface specification of the target system must be provided and confirmed by the technical teams of both parties.
Submit sample testing
Send us the workpiece, defect samples, inspection requirements and production line cycle time, and our solution engineer will determine which category of inspection problem it is and give recommendations on the imaging method and configuration.
Submitted successfully
We have received your sample testing request. A solution engineer will contact you within 1 business day via contact you.
Need to assess imaging conditions, defect criteria and cycle time item by item? Go to the Full Requirement Assessment →
Not Sure Which Category?
Send us the workpiece, defect samples and inspection requirements, and a solution engineer will determine which category of inspection problem it is and give recommendations on the imaging method, algorithm route and equipment configuration.