Stationen

Stationen bilden in Viper.NET einen (bitbasierten) Kommunikationskanal zu einem externen System (SPS, Roboter, …) ab. Häufig entsprechen Stationen dabei auch einer physikalischen Bearbeitungs- oder Prüfstation.

Der verwendete Handshake hängt von der Station ab. Eine Standard BV-Station benötigt eine andere Schnittstelle als z.B. die RunFromDir Station zur automatischen Referenzbildprüfung.

Alle Stationen werden in der Konfigurationsdatei stations.xml angelegt und beim Start von Viper.NET initialisiert. Alternativ können Stationen über die Benutzeroberfläche im Stationseditor konfiguriert werden. Der Stations-Tab zeigt den Zustand der Handshake-Bits der Stationen.

Digitaler Standard-Handshake

Digitale Handshakes in Viper.NET funktionieren in der Regel nach dem Prinzip des Three-Way-Handshakes mit zwei Signalen TRIGGER und BUSY:

Timing-Diagramm

Zunächst signalisiert Viper.NET über READY->HIGH, dass die Station zum Empfang von Triggern bereit ist. Die SPS kann dann per TRIGGER->HIGH die Prozessierung in Viper.NET starten.

Bemerkung

Der TRIGGER darf von der SPS nur gesetzt werden wenn die Bedingung READY AND NOT BUSY erfüllt ist. Andernfalls wird der Trigger von Viper.NET ignoriert.

Die Station bestätigt den TRIGGER->HIGH mit einem BUSY->HIGH und beginnt mit der Prozessierung. Die SPS quittiert das Signal BUSY->HIGH durch ein TRIGGER->LOW.

Hinweis

Das Signal BUSY->LOW wird von Viper.NET nur gesetzt wenn TRIGGER->LOW erkannt wurde.

Mit dem Signal BUSY->LOW wird auch eines der drei Ergebnis-Bits gesetzt:

• IO: Prozessierung wurde mit Gut abgeschlossen.

• NIO: Prozessierung wurde mit Schlecht abgeschlossen.

• ERROR: Während der Prozessierung trat ein Fehler auf, wodurch kein Ergebnis ermittelt werden konnte.

Dieser Handshake bildet die Basis für die meisten Viper.NET Stationen wie die Vision Station, die RunFromDir Station oder auch die Reinspect Station.

Siehe auch

Data, Bits und Bytes

Eingangs- und Ausgangsdaten

Zusätzlich zu den Bits für den Handshake werden für jede Station Eingangs- und Ausgangsdaten definiert. Die Eingangsdaten werden beim Trigger eingelesen und bei der Prozessierung verwendet. Da der Zeitpunkt, zu dem die Daten eingelesen werden, nicht exakt ermittelt werden kann, und auf manche Daten auch während der Prozessierung zugegriffen wird, dürfen die Eingangsdaten während des Ablaufs nicht verändert werden.

Die Datenbereiche für eine Station sind im Normalfall wie folgt in Header und Nutzdaten aufgeteilt:

Datenbereich Station

• BITS: Die Bits des Handshakes.

• CMD: Kann verwendet werden, um ein bestimmtes Kommando zu triggern.

• ERRCODE: Optionaler Fehlercode.

• RESCODE: Optionaler Ergebniscode.

• TYPE: Kann verwendet werden, um eine Typinformation zu übergeben. Bei BV Stationen wird damit z.B. zwischen ToolGroup Items umgeschaltet.

Bemerkung

In der Dokumentation einzelner Stationen wird die Bedeutung der einzelnen Felder für diese Station näher erläutert.

Konfiguration von Stationen

Stationen können über die Konfigurationsdatei stations.xml oder über die Benutzeroberfläche im Stationseditor konfiguriert werden.

Bemerkung

Es wird empfohlen, zur Konfiguration von Stationen den Stationseditor in der Benutzeroberfläche zu verwenden.

stations.xml

Alle Stationen werden in der Konfigurationsdatei stations.xml angelegt. Zusätzlich zur Konfiguration der Handshake-Bits und der Eingangs- und Ausgangsdaten werden hier auch spezifische Parameter angegeben. Die genaue Beschreibung der Konfiguration ist in der Dokumentation der jeweiligen Station angegeben.

Bemerkung

Nach Änderungen an Konfigurationsdatei stations.xml muss Viper.NET neu gestartet werden.

Stationseditor

Bemerkung

In Aufsetzen von Stationen wird exemplarisch Schritt für Schritt durch die Einrichtung einer Station mit dem Stationseditor geführt.

Der Stationseditor befindet sich unter MainMenu Functions (1) GlobalSettings (2) im Tab Stations (3).

Der Stationseditor enthält folgende Tabs mit verschiedenen Einstellungsmöglichkeiten:

1. Stations: Stationsliste, in der sich neue Stationen anlegen und konfigurieren lassen.

2. Resetbits: Hier werden Eingangssignale definiert, über die sich alle Stationen zurücksetzen lassen.

3. Livebits toggler: Hier lassen sich verschiedene Outputsignale hinzufügen, die dann im eingestellten Pollzyklus pollen.

4. Trigger servers: Hier lassen sich Ports definieren, auf denen man TRIGGER->HIGH und TRIGGER->LOW Signale an Viper.NET schicken kann (siehe Station Trigger Server).

5. Trigger server description: Übersicht der konfigurierten Trigger-Server.

Außerdem enthält der Stationseditor folgende Tab-übergreifende Buttons:

6. Reload stations xml: Aktualisiert die stations.xml Datei des Viper.NET Projekts mit den aktuellen Einstellungen des Stationseditors.

7. Edit stations xml: Öffnet die stations.xml Datei des Viper.NET Projekts in einem Texteditor.

8. Open GIO-HW-Explorer: Öffnet den HW Explorer.

Im Station-Tab des Stationseditors lassen sich mittels der Konfigurationsbuttons neue Stationen erzeugen:

Mit Shift und Doppelklick lassen sich einzelne Felder der erstellten Station direkt editieren. Mit einfachem Doppelklick öffnet sich ein Editor-Dialog für die jeweilige Station, wo sich detaillierte Einstellungen vornehmen lassen:

Im Tab Handshake (1) lässt sich beispielsweise der digitale Handshake der Station konfigurieren. Im unteren Bereich des Dialogs lassen sich einzelne Bits des Handshakes manuell konfigurieren. Mittels des Buttons Create GIO Bits (2) lassen sich Input- und Output-Bits auch automatisiert anlegen. In dem sich öffnenden Dialog lassen sich Input- und Output-Bits basierend auf der ID der konfigurierten Station erzeugen:

Mittels des Buttons Create missing bit IDs (2) lassen sich Input- und Output-Bits gemäß dem oben definierten ID-Schemas erzeugen (1). Mittels des Buttons Create missing GIO bits/data (3) lassen sich die zugehörigen GIO-Bits erzeugen. Um die dazu notwendige Hardware zu konfigurieren, lässt sich mittels des Open GIO-HW-Explorer (4) der HW Explorer öffnen.

Stations-Typen

In Viper.NET existieren, je nach Plugin-Konfiguration, folgende Stationen:

• Viper.NET

  • Log Station

• Vision Plugin

  • Vision Standard-Station

  • Image-Trigger Station

  • TypeLoadStation

  • RunFromDir Station

• ProcessPositions Plugin

  • ProcessPositions Station

• Reinspect Plugin

  • Reinspect Station

Projektspezifische Plugins können weitere Stationen bereitstellen.

Station Trigger Server

Über den Station Trigger Server können die Stationen alternativ zum TRIGGER-bit auch durch ein TCP/IP oder UDP Telegram getriggert werden. Das hat den Vorteil, dass das TRIGGER-bit nicht gepollt werden muss. Das zyklische Datenlesen in GInOut kann dann langsamer erfolgen, oder auch ganz deaktiviert werden. Der Handshake entspricht nach wie vor dem Viper.NET-Standard. Ersetzt wird nur der Flankenwechsel des TRIGGER-Bit.

Zum Einrichten muss die Konfigurationsdatei stations.xml angepasst werden.

<triggerSvrs stationsExclusiveTriggerdBySvr="-1">
  <triggerSvr localIp="" port="4567" udp="False" maxTcpClients="100" timeoutWaitForTriggerBitHigh="-1" />
</triggerSvrs>

• stationsExclusiveTriggerdBySvr : Kommaseparierte Liste von IDs der Stationen (-1 := alle Stationen), die ausschließlich über den Trigger-Server gestartet werden sollen.

• localIp : Um den Server Port an einen bestimmten Netzwerkadapter zu binden, kann eine lokale IP-Adresse angegeben werden.

• port : Lokaler TCP/IP bzw. UDP Port.

• udp: False|0 = TCP/IP-Verbindung, True|1* = UDP-Verbindung

• maxTcpClients : Maximale Anzahl an TCP/IP Verbindungen (falls udp=False).

• timeoutWaitForTriggerBitHigh : Maximale Zeit in [ms] die auf das digitale Triggersignal gewartet wird. Die Daten werden dabei zyklisch gelesen.

  • < 0 : Es wird nicht auf das digitale Triggersignal gewartet.

  • 0: Das digitale Triggersignal muss nach dem aktualisieren der Eingangsdaten gesetzt sein.

  • > 0 : Das digitale Triggersignal muss nach spätestens dieser Zeit in [ms] gesetzt sein.

Anfrage und Antwort sind Pipe-Separierte NULL-Terminierte ASCII Strings:

Anfrage SPS -> PC: telegramId|stationId or dataId|mode[0x00]

Antwort PC -> SPS: telegramId|stationId or dataId|acknowledge[0x00]

• telegramId : Kann frei vergeben werden.

• stationId : id der Station in der stations.xml.

• dataId : id der GInOut-Daten, die eingelesen werden sollen (mode=UpdateData).

• mode : Optionaler Parameter, default Wert : „Slope“.

  • Slope : Positive und Negative Trigger-Flanke

  • High : Positive Trigger-Flanke

  • Low : Negative Trigger-Flanke

  • Reset : Setzt die Station mit der ID stationId zurück. Falls stationId <= 0 ist, werden alle Stationen zurückgesetzt.

  • UpdateData : Die Daten mit der angegebenen ID dataId werden von der Hardware eingelesen.

• acknowledge:

  • Positive Antwort : „ACK“

  • Negative Antwort : „NAK:ErrorText“

Beispiel Trigger an Station ID 1:

Anfrage SPS -> PC: 99|1[0x00]

Positive Antwort PC -> SPS: 99|1|ACK[0x00]

Negative Antwort PC -> SPS: 99|1|NAK:Set starting outputs failed.[0x00]

Viper.NET Stationen

• Log Station