Hardwarezugriffe mit GInOut

Das Modul GInOut vereinfacht und standardisiert die digitale Kommunikation mit externen Anlagensteuerungen. Durch eine eigene Treiberschicht bleibt der Datenzugriff aus Anwendungssicht immer gleich, egal ob mit einer Beckhoff-SPS, SIMATIC S7 oder simulierter Hardware über den Arbeitsspeicher kommuniziert wird. Damit wird die Simulation von Gegenstellen oder Portierung einer Anwendung auf andere Anlagensteuerungen stark vereinfacht.

Konfiguration

GInOut wird über eine XML-Datei (.xio) parametriert. Mit dem Tool GInOutHwExplorer kann die Konfiguration auch außerhalb von Viper.NET erstellt und gleichzeitig getestet werden. In Viper.NET ist der Hw Explorer in einem Sidebar Tab eingebunden.

Manche Funktionen sind nur durch eine direkte Bearbeitung der XML-Datei möglich (z.B. Entfernen von Objekten) bzw. komfortabler (Copy&Paste).

Bemerkung

Vor Änderungen in der XML-Datei sollte Viper.NET geschlossen werden, da die Datei beim Beenden u.U. gespeichert wird.

Hardware und Datablocks

Die Hardware bildet die Basis in GInOut. Jede Hardware hat andere Eigenschaften, Verbindungsparameter und Kommunikationsprotokolle (siehe auch Unterstützte Hardware). Es können beliebig viele Hardware-Objekte angelegt werden, d.h. Viper.NET kann auch mit mehreren unabhängigen Steuerungen gleichzeitig verbunden sein.

Jede Hardware hat mindestens einen DataBlock (physikalische Daten), der einen Zugriff auf einen Datenbereich in der Hardware ermöglicht. Die Parameter eines DataBlocks sind abhängig von der jeweiligen Hardware. Bei dem Zugriff auf TwinCat ADS entspricht ein DataBlock z.B. einer TwinCat ADS Variablen, während bei der Anbindung von Profibus-Hardware die verfügbaren DataBlocks fix durch die Hardware vorgegeben sind.

Polling und Performance

Die Daten werden bei fast jeder verfügbaren Hardware aktiv von der Gegenstelle abgefragt (Polling). Bei der Verwendung mehrerer Hardwareverbindungen läuft das Polling sequentiell Hardware für Hardware. Vergleichsweise langsame Gegenstellen, wie z.B. eine Simatic S7 über die S7ISOTCP, bremsen einen Pollzyklus aus und GInOut wird insgesamt träge.

Um das zu vermeiden kann für jede Hardware eingestellt werden, ob die Daten in einem eigenen Thread gepollt werden sollen.

  • Vorteile globales Polling: - Bei mehreren schnell antwortenden Gegenstellen wird die CPU entlastet

  • Vorteile eigenes Polling: - Langsame Hardware verlangsamt nicht das Gesamtsystem

Welche Einstellung richtig ist, hängt vom konkreten Anwendungsfall ab, aber als Faustregel gilt: Langsame Hardware immer mit eigenem Poll-Thread konfigurieren.

Übliche Zykluszeiten:

Hardware

Zykluszeit

Beckhoff

? ms

S7ISOTCP

3-70 ms

MemoryMappedFile

0 ms

Data, Bits und Bytes

Hardware und DataBlocks sind für die Anwendung nicht sichtbar. Stattdessen wird über logische Datenbereiche bzw. einzelne konfigurierte Bits auf die darunter liegende Hardware zugegriffen.

Ein Datenbereich wird über Offset und Länge innerhalb eines DataBlock angelegt, d.h. ein DataBlock kann in mehrere Datenbereiche unterteilt oder auch komplett von einem Datenbereich abgedeckt werden.

Da die Datenbereiche hardwareunabhängig sind, ist hier die Konfiguration immer gleich. Die gesamte weitere GInOut-Konfiguration, aber auch Zugriffe aus Viper.NET heraus, sind immer auf die Datenbereiche bezogen.

In den Datenbereichen werden die digitale Ein- und Ausgänge (Bits) definiert.

../../_images/bit-add.gif

Bits werden z.B. für den digitalen Stationshandshake verwendet, können aber auch in Visualisierungen eingebunden werden.

Siehe auch

Variablenlisten und Variablen

Die Byte-Daten, die von bzw. an Steuerungen bereitgestellt werden, müssen je nach vereinbarter Schnittstelle auf Anwendungsseite interpretiert bzw. aufbereitet werden. Eine Seriennummer kann bspw. eine 4 Byte große Ganzzahl sein oder ein 10-stelliger ASCII-Text.

Variablen bieten die Möglichkeit, der Anwendung interpretierte Daten zur Verfügung zu stellen. In jeder Variable muss angegeben werden:

  • Datenbereich

  • Byte-Offset im Datenbereich

  • Länge

  • Ein Konverter, der für die Umwandlung der Daten in einen bestimmten Zieltyp verantwortlich ist.

Variablen werden immer in Variablenlisten gruppiert.

Siehe auch

Python Skripte

In GInOut können Python-Skripte angelegt und automatisch ausgeführt werden, wenn sich der Zustand eines zugeordneten Bits oder einer Variablen ändert.

Skripte werden üblicherweise für Simulationen verwendet, können aber auch komplexere Abläufe in automatisierten Anlagen auslösen.

Viper.NET verwendet die freie .NET Python Implementierung IronPython.

Siehe auch

Achsen, Zylinder und Signalampeln

Auf Basis der bisherigen Grundobjekte enthält GInOut weitere, vorgefertigte Objekte, die in komplexeren Aufgabenstellungen Scan- oder Bestückprozessen Verwendung finden.

Achsen (Axes)

Die GInOut-Achse ist eine Schnittstelle zu einer SPS Linear oder Rotationsachse. Eine neue Achse wird im Hardware-Explorer-Popupmenu ‚Add… -> Axis‘ angelegt. Diese wird über den Gefasoft Standard-Handshake für Achsen angesprochen. Der Datenaustausch erfolgt dabei über GInOut-Variablen.

Siehe auch

Zylinder (Valves)

Der GInOut-Zylinder kann einen mono- bzw. bistabilen Zylinder mit zwei Endlagen über eine digitale Schnittstelle ansteuern. Eine neuer Zylinder wird im Hardware-Explorer-Popupmenu ‚Add… -> Valve‘ angelegt.

Siehe auch

Signalampel (Signal Lights)

Die Signalampel ist eine Reihe von Ausgangsbits, über die Signale angesteuert werden. Eine neue Signalampel wird im Hardware-Explorer-Popupmenu ‚Add… -> Signallights‘ angelegt. Jedes Ausgangssignal kann dabei auf dauerhaft ein, dauerhaft aus, oder auf blinkend gestellt werden.

Vakkumsauger (Suction Tools)

Ein Vakuumsauger kann in Scripten oder Plugins für Pick&Place Anwendungen verwendet werden.