Viper.NET simplifies and accelerates the building process of industrial image processing applications. In Viper.NET the whole process, from trigger to result, is ready integrated and automated. Users can count on well-engineered interfaces that are daily utilized and optimized in both our own machines and integrative at other manufacturers. A flexible plugin-model and many liberties in the configuration of Viper.NET make a fast function extension for customized requirements possible.
Viper.NET uses Cognex VisionPro, one of the best PC-vision libraries worldwide. Additionally Viper.NET gives the opportunity to rely on the enormous functions of HALCON.
Viper.NET uses Cognex ToolGroups for the connection to Cognex VisionPro. Each ToolGroup describes an image processing task. A ToolGroup is integrated in Viper.NET using a so-called ToolGroupItem which defines (compared to the ToolGroup) some additional things:
In Viper.NET ToolGroupItems are pooled in "Jobs". The job is responsible for executing a ToolGroupItem. Per cycle only 1 ToolGroupItem can be executed. However multiple jobs can be defined and executed in parallel. A vision type consists of 1 to n jobs.
Every job is assigned to a station which makes the external interface available. The stations are not bound to types, but valid application-wide.
Because of this structure a control system with only one trigger is able to initiate multiple image processing tasks in parallel. This significantly decreases the effort to integrate automatic optical inspections e.g. for rotary table machine. The communication handshake between the control system and Viper.NET consists only of a few Bits. It is also possible to define multiple stations that communicate with different PLCs.
To process and analyse images, first of all the images have to be acquired.
Viper.NET provides comprehensive interfaces for the image acquisition:
CogAcqFifo (Cognex Standard)
More interfaces can be integrated fast and straightforward on demand.
In particular the native connection of GigE cameras gives a lot of benefit compared to generic drivers:
Example SVS Vistek: Designated cameras of SVS Vistek are equipped with PWM outputs that are activated either directly or in sequencer-mode. With this PWM outputs, designated lights can be operated directly with the camera, with the option to control the intensity of these lights very accurate through the PWM signal.
Example Baumer: During image acquisition the camera generates messages that are retrieved. A very important message is "EXPOSURE_END", that signalizes the end of the chip exposure. This is the earliest expected time to move the part again. The message is processed by the system before aquiring the image. This saves valuable milliseconds for part handling.
In Viper.NET all image sources are configured and used outside the image processing task. Not before the images from all image sources are acquired, the analysis starts. Usually the aquisition is done in parallel. The number of image sources is not limited.
Another benefit of Viper.NET is the integrated light control that enables the definition of the appropriate light situation for each acquisition situation.
It makes no difference if there is always the same or different light situation used for multiple cameras, or how many lights are used.
At this time the module for light control supports the following controllers:
Viper.NET supports numerous control systems, which are integrated and abstracted with a seperate IO-module.
This integration has multiple benefits:
The IO-module is configurated and tested using the "GInOutHwExplorer" tool within minutes. This cuts down commissioning periods.
The functionality of Viper.NET is extendable with plugins to make changes to a process or the user interface, or to integrate fully automated processes. The functionality of the image processing itself is also encapsuled in a plugin. This is the reason why the software is also capable of realizing process controls or laser applications. Almost all GEFASOFT software projects are developed this way:
In Viper.NET images acquired during the process are saved automatically. You are always able to choose which images are saved (e.g. only images of bad parts).
Viper.NET helps you to analyse the images afterwards. All saved images can be processed automatically.
The results are shown in the Viper.NET main window. Processing of single images, single folders or all images within a folder structure is possible. That way modifications to parameters or workflows can be verified very fast. Superior PLC systems are able to start the analysis function also in automatic mode (e.g. to double-check the image processing routines against the reference images).
Inspection results are displayed in so-called views, which are configured per ToolGroupItem. Each view can have any number of SubDisplays:
Each user can have his own view. This gives the option to create sophisticated views for superusers (e.g. analysis), and a standard image- / error display for the operator during normal production.
Base: Example-Job from Cognex (Detect Defect using NxM Median Filter)
Default values and results often have to be exchanged with the superior PLC system. Viper.NET also has a very effective mechanism for this.
On IO-module level variables are created which define the source- / target data area and the data conversion. These variables can be connected to a designated terminal during the ToolGroupItem configuration.
Input data are read at the trigger and written to the configured terminal before the execution of the ToolGroup. Output data are only sent to the control system if there is no Run Error (configurable).
On top of these features it is possible to set result bits on IO-level. The state of one bit (High/Low) is determinated through the validation results of DataAnalysis-Terminals.