GEFASOFT Viper.NET

Viper.NET vereinfacht und beschleunigt das Erstellen von Industrietauglichen Bildverarbeitungsanwendungen. In Viper.NET ist der gesamte Verarbeitungsprozess vom Trigger bis zur Ergebnisrückgabe fertig integriert und automatisiert. Benutzer können sich auf ausgereifte Schnittstellen verlassen, die sowohl in unseren eigenen Anlagen als auch integrativ bei anderen Herstellern täglich eingesetzt und optimiert werden. Ein flexibles Plugin-Modell und große Freiheiten bei der Konfiguration von Viper.NET ermöglichen eine schnelle Funktionserweiterung für kundenspezifische Anforderungen.

Viper.NET setzt auf Cognex VisionPro, eine der besten PC-Vision Bibliotheken weltweit. Zusätzlich bietet Viper.NET die Möglichkeit, auf die umfangreichen Funktionen von HALCON zurückzugreifen.

Vorteile

  • Fertige „Ready-To-Use“ Anwendung
  • Anbindung an diverse SPS-Steuerungen und Bussysteme (TwinCat ADS, S7 ISO TCP, Prodel, Modbus Server/Client, Profibus, TCP/IP, ADDI-DATA, Cognex IO)
  • Keine Beschränkung der Kameraanzahl
  • Integrierte Beleuchtungsansteuerung
  • Eingabe- und Ergebnisdaten frei konfigurierbar
  • Flexible Ergebnisvisualisierung
  • Komfortable Typverwaltung
  • Automatische Bildspeicherung und -analyse
  • Unterstützt optimal die Gefasoft VisionPro Tool Bibliothek (HalconWrapperTool, ToolBlockReferenceTool…)

Systemvoraussetzungen

  •  Microsoft Windows 7 oder höher (64 Bit bevorzugt)
  • .NET 4.5.2
  • Cognex VisionPro 7.2 bzw. 8.2 SR1
  • Optional: MVTec Halcon ab V11

 

 

Downloads

Datenblatt 10/2016

Aufbau

Stationen, Jobs und ToolGroupItems

Viper.NET verwendet Cognex ToolGroups als Schnittstelle zu Cognex VisionPro. Jede ToolGroup beschreibt eine Bildverarbeitungsaufgabe. Eine ToolGroup wird in Viper.NET über ein so genanntes ToolGroupItem eingebunden. Dieses definiert zusätzlich zur ToolGroup:

  • Bildquellen
  • Ein- und Ausgabedaten von/an Steuerungssystemen
  • Visualisierungsoptionen

ToolGroupItems werden in Viper.NET in Jobs zusammengefasst. Der Job ist für die Ausführung eines ToolGroupItem zuständig. Es kann immer nur ein ToolGroupItem pro Durchlauf ausgeführt werden. Allerdings können mehrere Jobs definiert werden, die parallel ausgeführt werden. Ein Bildverarbeitungstyp besteht aus 1 bis n Jobs.

Jeder Job ist einer Station zugeordnet, die die Schnittstelle nach außen bereitstellt. Die Stationen sind nicht typabhängig, sondern anwendungsweit gültig.

Durch diesen Aufbau kann eine Steuerung mit nur einem Trigger mehrere Bildverarbeitungsaufgaben parallel anstoßen, was den Aufwand zur Integration von automatischen optischen Inspektionen z.B. in Rundtaktanlagen deutlich reduziert. Der Handshake zur Kommunikation zwischen Steuerung und Viper.NET besteht nur aus wenigen Bits. Es können auch mehrere Stationen definiert werden, die mit verschiedenen Steuerungen kommunizieren.

Bildquellen

Wenn Bilder verarbeitet und analysiert werden sollen, müssen diese zunächst einmal eingelesen werden. Viper.NET stellt umfangreiche Schnittstellen für die Bildaufnahme bereit:

  • CogAcqFifo (Cognex Standard)
  • Native Anbindung  von GigE Cameras von

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

  • Keyence LJV (Laserscanner)
  • Framegrabber

    • Silicon Software MicroEnable

  • Bilder aus Bild-Dateien, AVI-Dateien oder Ordnern

Weitere Schnittstellen können bei Bedarf schnell und unkompliziert eingebunden werden.

Insbesondere die native Anbindung der GigE Kameras bietet viele Vorteile verglichen mit den generischen Treibern:

  • Beispiel SVS Vistek: Bestimmte Kameras von SVS Vistek verfügen über PWM Ausgänge, die entweder direkt oder im Sequencer-Modus angesprochen werden können. Mit diesen PWM Ausgängen können bestimmte Beleuchtungen direkt von der Kamera betrieben werden, mit der Möglichkeit, die Intensität über das PWM-Signal feingranular zu steuern.
  • Beispiel Baumer: Hier werden Nachrichten abgefragt, die während der Bildaufnahme von der Kamera generiert werden. Eine wichtige Nachricht ist „EXPOSURE_END“, die das Ende der Chip-Belichtung signalisiert. Zu diesem Zeitpunkt darf ein Bauteil frühestens wieder bewegt werden. Die Nachricht wird vor der Übertragung des Bildes an den Rechner abgesetzt, was wertvolle Millisekunden beim Teilehandling sparen kann.

In Viper.NET werden die Bildquellen außerhalb des Bildverarbeitungsablaufs konfiguriert und verwendet. Erst wenn die Bilder von allen Bildquellen eingezogen worden sind wird die Auswertung gestartet, wobei der Einzug standardmäßig parallel erfolgt. Es können beliebig viele Bildquellen verwendet werden.

Beleuchtungssteuerung

Ein weiterer Vorteil von Viper.NET ist die integrierte Beleuchtungssteuerung, mit der pro Aufnahmesituation eine passende Beleuchtungssituation definiert werden kann.

Dabei spielt es keine Rolle, ob bei mehreren Kameras immer dieselbe oder verschiedene Beleuchtungssituationen verwendet werden, bzw. wie viele Beleuchtungen verwendet werden.

Das Modul zur Beleuchtungssteuerung unterstützt derzeit diese Controller:

  • Gefasoft LUCON
  • Gardasoft PP6X Serie
  • Smartek IPSC und SC Serie

Anbindung an Steuerungssysteme

Viper.NET unterstützt eine große Bandbreite von Steuerungen, die über ein eigenes IO-Modul eingebunden und abstrahiert werden.

Diese Einbindung hat diverse Vorteile:

  • Unabhängigkeit der Bildverarbeitungs- und Auswertealgorithmik von der verwendeten Hardware
  • Einfache Simulationsmöglichkeiten (z.B. über Hardware "MemoryMappedFile")
  • Schneller Wechsel zwischen verschiedenen Hardwareplattformen möglich (nur Konfiguration ändern)
  • Eine Viper.NET Anwendungen kann mit beliebig vielen Steuerungen kommunizieren.

Das IO-Modul wird über ein eigenes Tool "GInOutHwExplorer" in wenigen Minuten konfiguriert und getestet, was Inbetriebnahmezeiten deutlich reduziert.

Plugins

Die Funktionalität von Viper.NET kann über Plugins erweitert werden, um projektspezifische Anpassungen an Ablauf oder Oberfläche vorzunehmen, oder um komplette automatische Abläufe zu integrieren. Da die Bildverarbeitungsfunktionalität selbst in einem Plugin gekapselt ist, kann die Software auch verwendet werden, um Prozesssteuerungen oder Laseranwendungen zu realisieren. Fast alle Softwareprojekte von Gefasoft werden auf diese Weise umgesetzt:

  • Laseranwendungen
  • Prozesssteuerungen (siehe IRISOR)
  • Handarbeitsplätze
  • Visualisierungsanwendungen

Funktionsbeispiele

Bilder speichern und analysieren

Bilder, die bei der Verarbeitung aufgenommen werden, werden in Viper.NET automatisch gespeichert. Sie können dabei selbst bestimmen, ob z.B. nur Bilder von Fehlerteilen abgespeichert werden sollen.

Viper.NET unterstützt Sie bei der nachträglichen Analyse von Bildern. Gespeicherte Bilder können automatisch durchlaufen werden.

Die Ergebnisse werden im Viper.NET Hauptfenster visualisiert. Es können einzelne Bilder, einzelne Ordner oder alle Bilder in der Verzeichnisstruktur ausgeführt werden. Auf diese Weise kann sehr schnell überprüft werden, wie sich Veränderungen an Parametern oder Abläufen auswirken. Übergeordnete Steuerungen können die Analysefunktion auch während des Automatikablaufs starten, z.B. um regelmäßig die Bildverarbeitungsroutinen gegen Referenzbilder zu prüfen.

Views und Subdisplays

Die Darstellung der Ergebnisse wird pro ToolGroupItem in Views definiert. Für eine View können beliebig viele SubDisplays angelegt werden:

  • Bild mit Grafiken
  • Werte und Ergebnisse
  • Verlaufskurven
  • Diagramme, die über Skripte erstellt worden sind (beispielsweise Hüllkurven)

Für jeden Benutzer kann eine eigene View definiert werden. Damit können für Einrichtpersonal komplexere Ansichten zur Analyse erstellt werden, während bei der normalen Produktion eine einfache Bild-/Fehleranzeige ausreichend ist.

Grafiken anzeigen und einfärben

Grundlage: Beispiel-Job von Cognex (Detect Defect using NxM Median Filter)

 

 

Im Beispiel wird eine Fehlstelle mittels Medianfilter verstärkt und anschließend per BlobTool detektiert. Die Grafik für die Fehlstelle wird nur im Blob-Bild visualisiert, eine Anzeige im Eingabebild ist nur über Skripte möglich.
Mit Viper.NET können Bilder und Grafiken für die Visualisierung beliebig kombiniert werden. Über eine einfache grafische Oberfläche wird für jedes Display das Anzeigebild definiert. Die Grafiken können aus der Liste der verfügbaren CogRecords ausgewählt werden.
Dabei kann für jede Grafik entweder eine Formatierung angegeben werden, mit der Farbe, Strichstärke und Strichlierung überschrieben werden. Das ist hilfreich, wenn Blobs als Fehler klassifiziert werden und rot dargestellt werden sollen. Die Formatierung kann entweder fest angegeben oder auf Basis eines DataAnalysis-Ergebnisses bestimmt werden (bspw. nicht sichtbar bei Accept, gelb bei Warn, rot bei Reject).

Ein- und Ausgabedaten

Vorgabewerte und Ergebnisse müssen häufig mit der übergeordneten Steuerung ausgetauscht werden. Viper.NET bietet auch hier einen sehr effektiven Mechanismus an.

Auf Ebene des IO-Moduls werden Variablen definiert, die den Quell- bzw. Zieldatenbereich sowie die Konvertierung der Daten definieren. Diese Variable können dann bei der Konfiguration eines ToolGroupItems einfach mit bestimmten Terminals verknüpft werden.

Eingabedaten werden beim Trigger eingelesen und vor der Ausführung der ToolGroup in das konfigurierte Terminal geschrieben. Ausgabedaten werden nur dann an die Steuerung gesendet wenn kein Ablauffehler (RunError) aufgetreten ist.

Zusätzlich zu Daten können auch Ergebnisbits auf IO-Ebene gesetzt werden. Der Zustand der Bits (High/Low) wird über das Überprüfungsergebnis von DataAnalysis-Terminals bestimmt.

Produkt-PDF