Vision Standard-Station

Der Großteil der Viper.NET Bildverarbeitungsapplikationen verwendet die Vision Standard-Station für die Kommunikation mit einer SPS.

Digitaler Handshake

Der Viper.NET Standard-Handshake wurde um spezifische Bits für die Bildverarbeitung erweitert. Je nachdem ob die Kameras über Software- oder Hardwaretrigger angesteuert werden, ist ein minimal anderer Handshake notwendig.

Software-Trigger

• ACQ: Ist während der Bildaufnahme HIGH. Nach dem Wechsel auf LOW kann ein Bauteil z.B. der zur nächsten Bearbeitungsstation transportiert und dort auf das BV Ergebnis gewartet werden.

• CRIT: Siehe Kriterien-Bits und User-Bits

• USER: Siehe Kriterien-Bits und User-Bits

Hardware-Trigger

Wenn Kameras extern getriggert werden, muss zunächst der Parametersatz geladen und die Kamera gestartet werden. Erst danach ist die Kamera bereit für die Bildaufnahme. Das Bit AQU_START signalisiert der SPS, das alle Kameras bereit für einen externen Trigger sind. ACQ sowie die CRIT- und USER-Bits werden wie beim Software-Trigger verwendet.

Hinweis

Der Hardware-Trigger wird z.B. bei Zeilenkameras mit Scan-Achsen verwendet.

Konfiguration

<!-- ************************** -->
<!-- ***** Vision Station ***** -->
<!-- ************************** -->
<station id="1" name="BV 1"  type="VisionStation2">
  <param name="selectTgItemByTypeId" value="false"/>
  <param name="setBusyWithData" value="Auto"/>
  <handshake>
    <param name="wait4NegEdgeTriggerTO" value="-1"/>
    <in>
      <bit bitRef="1001" id="trigger"/>
    </in>
    <out>
      <bit bitRef="1001" id="ready"/>
      <bit bitRef="1002" id="busy"/>
      <bit bitRef="1003" id="error"/>
      <bit bitRef="1004" id="io"/>
      <bit bitRef="1005" id="nio"/>
      <bit bitRef="1006" id="acq"/>
      <bit bitRef="1007" id="acqStart"/>
      <bit bitRef="1101" id="crit"/>
      <bit bitRef="1102" id="crit"/>
    </out>
  </handshake>

  <commandInterface>
    <in>
      <data dataRef="07" offset="0" length="128" id="DATA"/>
      <data dataRef="07" offset="2" length="2" id="cmd" converter="System.Int16" converterParams="twistBytes=true"/>
      <data dataRef="07" offset="4" length="2" id="errCode" converter="System.Int16" converterParams="twistBytes=true"/>
      <data dataRef="07" offset="6" length="2" id="resCode" converter="System.Int16" converterParams="twistBytes=true"/>
      <data varRef="VarsVisionStation1.Type" id="type"/>
      <data varRef="VarsVisionStation1.ResetResultHistory" id="resetResultHistory"/>
    </in>
    <out>
      <data dataRef="08" offset="2" length="2" id="cmd" converter="System.Int16" converterParams="twistBytes=true"/>
      <data dataRef="08" offset="4" length="2" id="errCode" converter="System.Int16" converterParams="twistBytes=true"/>
      <data dataRef="08" offset="6" length="2" id="resCode" converter="System.Int16" converterParams="twistBytes=true"/>
      <!--data dataRef="08" offset="8" length="2" id="type" converter="System.Int16" converterParams="twistBytes=true"/-->
    </out>
  </commandInterface>
</station>

Die Konfiguration ist aufgeteilt in Parameter, Handshake und CommandInterface.

Parameter

• selectTgItemByTypeId: Mit value="true" wird die Auswahl des ToolGroupItems über commandInteface->type aktiviert.

• setBusyWithData: Laut Handshake sind die Ergebnisdaten und -bits gültig, sobald BUSY zurückgesetzt wird. Damit müssten eigentlich zuerst die anderen GInOut-Daten und erst im Anschluss BUSY->LOW gesetzt werden. Wenn aber sichergestellt ist, dass BUSY und die restlichen Daten konsistent geschrieben werden können, kann zur Taktzeitoptimierung ein Schreibzyklus eingespart und alle Ausgangsdaten auf einmal geschrieben werden.

  • False: Separater Schreibzyklus für BUSY->LOW (nicht konsistent schreibbare Daten).

  • True: BUSY->LOW wird zusammen mit den restlichen Daten gesetzt (konsistent schreibbare Daten).

  • Auto [Standard]: Viper.NET versucht, über die GInOut-Hardware herauszufinden, ob die Daten konsistent geschrieben werden können, und verwendet dann intern je nachdem True oder False.

• setAcquisitionFinishedOnExposureEnd:

  • False [Standard]: ACQ wird zurückgesetzt, wenn die Bilder von allen Kameras fertig eingezogen sind.

  • True: ACQ wird zurückgesetzt, sobald alle Kameras mit der Belichtung fertig sind (wird nicht von allen Bildquellen) unterstützt.

Bemerkung

setBusyWithData bezieht sich nur auf die in der Station definierten Ausgangsdaten und -bits. Die Ergebnisdaten von ToolGroup Items werden immer direkt aktualisiert.

Handshake

Hier werden die einzelnen Bits des Handshakes parametriert. Die Bits müssen in GInOut angelegt sein. Mit dem Attribut bitRef werden die Bits über ihre ID referenziert. Das Attribut id definiert, wie das Bit im Handshake verwendet wird.

Im Handshake können weitere optionale Bits definiert werden:

<handshake>
    ...
    <in>
      ...
      <bit bitRef="1002" id="reset"/>
    </in>
    <out>
      ...
      <bit bitRef="1008" id="warn"/>
    </out>
  </handshake>

• in/reset: Kann von der SPS gesetzt werden, um einen Reset der Station auszuführen.

• out/warn: Wird zusätzlich zu IO gesetzt falls die Bildauswertung ein Warn-Ergebnis liefert.

Zusätzlich werden im Handshake weitere Parameter definiert:

• wait4NegEdgeTriggerTO: Max. Wartezeit auf TRIGGER->LOW in Millisekunden. Nach Ablauf der Wartezeit ohne TRIGGER->LOW wird ein Fehler generiert. Vor dem nächsten Trigger ist ein Reset der Station erforderlich.

CommandInterface

Im CommandInterface-Abschnitt werden GInOut-Daten bzw. GInOut-Variablen referenziert, die für den Betrieb der Station notwendig sind.

Hinweis

Die Daten sollten immer über GInOut-Variablen mit varRef` referenziert werden.

In dieser Station werden folgende Daten-IDs unterstützt (siehe auch Eingangs- und Ausgangsdaten):

• in

  • DATA: Referenz auf den gesamten Datenbereich, der das Trigger-Bit enthält (derzeit notwendig, wird zukünftig entfallen).

  • type: Int16-Wert für die Auswahl des ToolGroup Items

  • resetResultHistory: Int16-Wert zum Zurücksetzen bestimmter historischer Daten

    • 1: Elemente in den Bilderleisten der ToolgroupItem Ansichten zurücksetzen/löschen.

• out

  • errCode: Enthält einen Fehlercode wenn die Station einen ERROR statt IO oder NIO liefert.

  • type: Spiegelung des type aus den Inputs.

Mögliche Fehlercodes in errCode:

• 4 - StartError: Z.b. wenn kein ToolGroupItem für den angeforderten type gefunden wurde.

• 5 - AcquisitionError: Fehler beim Bildeinzug.

• 6 - RunError: Ablauffehler, z.B. wenn eine Muster- oder Kantensuche fehlschlägt und nachfolgende Auswertungen nicht durchgeführt werden können.

• 7 - CalibrationInvalid: Kalibrierung ungültig (siehe Kalibrier TG Item).

• 9 - InvalidLicense: Keine Viper.NET Automatik-Lizenz.

• 10 - Cancelled: Job wurde abgebrochen.

Auswahl des ToolGroup Items

Eine Steuerung kann beim Trigger entscheiden, welches Toolgroup Item bzw. welche Prüfaufgabe ausgeführt werden soll. Dafür stehen zwei Möglichkeiten zur Verfügung.

Option 1: ToolGroup Item ID

In der station.xml kann für jede Station die Option selectTgItemByTypeId aktiviert und das Tag type unter commandInterface/in/data mit einer GInOut-Variable verknüpft werden. Die SPS kann nun beim Trigger die ID des ToolGroup Items als type setzen.

Mit dieser Methode können nur ToolgroupItems mit einem ID-Präfix ausgewählt werden (siehe auch Name und ID).

1. selectTgItemByTypeId: ‚True‘ -> Option aktiviert. ‚False‘ -> Option deaktiviert.

2. in/type: Name der GInOut-Variable mit der Vorgabe Type-ID.

3. out/type: Name der GInOut-Variable, in die die verwendete Type-ID zurückgeschrieben werden soll.

4. Liste der ToolGroupItems: Siehe auch ToolGroup Items.

5. In/Out Type: Konfiguration der Type-Variable GInOutVariablen im HW-Explorer.

6. In/Out Type Data converter: Die Stations Daten müssen in einen Int16 (16-Integer Wert mit Vorzeichen) gewandelt werden.

Option 2: ToolGroup Item Selektor

Für jeden Job kann im Job-Editor ein Selektor aktiviert und parametrisiert werden. Der Selektor wird von der Vision-Station beim Trigger ausgeführt und wählt das auszuführende ToolGroupItem aufgrund des Wertes von GInOutVariablen aus.

Hinweis

Falls VPP-Selektoren verwendet werden sollen, so muß in der Station selectTgItemByTypeId deaktiviert werden.

Kriterien-Bits und User-Bits

Für eine Station können optional Kriterien-Bits konfiguriert werden, die im ToolGroup Item Editor zu einem oder mehreren DataAnalysis-Terminals zugeordnet werden. Bei NIO Bauteilen kann die SPS damit den Fehler kategorisieren. Die CRIT Bits werden beim BUSY-HIGH zurück- und bei BUSY-LOW gesetzt.

Des Weiteren können USER-Bits definiert werden, die ebenfalls beim Trigger bzw. beim Reset der Station zurückgesetzt werden. Sie können beispielsweise im Ablauf über Python-Skripte oder das CommandInterfaceTool gesetzt werden. Für den Handshake haben sie keine weitere Bedeutung.

Beispiel einer Konfiguration mit CRIT- und USER-Bits:

<!-- ************************** -->
<!-- ***** Vision Station ***** -->
<!-- ************************** -->
<station id="1" name="BV 1"  type="VisionStation2">
  <param name="selectTgItemByTypeId" value="false"/>
  <param name="setBusyWithData" value="Auto"/>
  <handshake>
    <param name="wait4NegEdgeTriggerTO" value="-1"/>
    <in>
      <bit bitRef="1001" id="trigger"/>
    </in>
    <out>
      <bit bitRef="1001" id="ready"/>
      <bit bitRef="1002" id="busy"/>
      <bit bitRef="1003" id="error"/>
      <bit bitRef="1004" id="io"/>
      <bit bitRef="1005" id="nio"/>
      <bit bitRef="1006" id="acq"/>
      <bit bitRef="1007" id="acqStart"/>
      <bit bitRef="1101" id="crit"/>
      <bit bitRef="1102" id="crit"/>
      <bit bitRef="1103" id="user"/>
      <bit bitRef="1104" id="user"/>
    </out>
  </handshake>
  ...

Siehe auch

GInOut