This website uses cookies

This website needs certain cookies to work correctly. These cookies are technically necessary. If you allow us, we will also use statistic cookies to help gather statistics about your visits to this site in order to improve our service. You can change your choices at any time on our privacy policy page.

Currently all cookies are disabled.


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.


  • "Ready-to-use" application
  • Connection to numerous PLC and bus-systems (TwinCat ADS, S7 ISO TCP, Prodel, Modbus Server/Client, Profibus, TCP/IP, ADDI-DATA, Cognex IO)
  • Unlimited number of cameras
  • Integrated light-control
  • Freely configurable Input- and Resultdata
  • Flexible result visualisation
  • Comfortable type management
  • Automated image saving and - analysis
  • Optimal use of the GEFASOFT VisionPro tool library (HalconWrapperTool, ToolBlockReferenceTool ...)

System requirements

  • Microsoft Windows 7 or better (64 Bit bevorzugt)
  • .NET 4.5.2
  • Cognex VisionPro 7.2 or 8.2 SR1
  • Optional: MVTec Halcon V11 or better




Datasheet 10/2016


Stations, Jobs and ToolGroupItems

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:

  • Image sources
  • In- / Output data of / to PLCs
  • Visualisation options

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.

Image sources

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)

  • Native connection to GigE cameras of

    • Baumer
    • SVS Vistek
    • IDS (µEye)
    • Jai
    • Basler Pylon

  • Keyence LJV (Laserscanner)
  • Framegrabber

    • Silicon Software MicroEnable

  • Images of Image-Files, AVI-Files or folders

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.

Light control

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:

  • Gefasoft LUCON series
  • Gardasoft PP6X series
  • Smartek IPSC and SC series

Connection to control systems

Viper.NET supports numerous control systems, which are integrated and abstracted with a seperate IO-module.

This integration has multiple benefits:

  • Autonomy between the image processing- and analysis algorithmics and the used hardware
  • Fast switching between different hardware platforms possible (just change the configuration)
  • A Viper.NET application can communicate with an arbitrary number of control systems

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:

  • Laser application
  • Process controls (see IRISOR)
  • Manual operation stations
  • Visualisation applications


Image saving and analyising

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).

Views and Subdisplays

Inspection results are displayed in so-called views, which are configured per ToolGroupItem. Each view can have any number of SubDisplays:

  • Image with graphics
  • Data and results values
  • Process graph
  • Script created diagrams (e.g. envelopes)

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.

Show and colorize graphics

Base: Example-Job from Cognex (Detect Defect using NxM Median Filter)



In this example a bad spot is boosted by a Medianfilter and detected by a BlobTool afterwards.
For Visualisation, Viper.NET is able to combine any images and graphics. The Image definition is made through a simple GUI, per display.

Input- / Output data

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.