+43 2757 24131
info@x-works.atADS steht für Automation Device Specification und stellt eine Zugriffsmöglichkeit für Programmiersprachen direkt auf Variablen in einer Beckhoff SPS dar. Zugegeben die ADS Schnittstelle ist clever, man kann damit die komplette SPS softwaretechnisch steuern. Auch können damit eigene Visualisierungen auf die Daten zugreifen und diese auch verändern.
Es werden dafür auch die passenden DLLs für .NET von Beckhoff kostenlos bereitgestellt. Und auch auf der SPS Seite sind keine zusätzlichen Lizenzen erforderlich. Dem Zugriff auf die SPS ist damit Tür und Tor geöffnet. Das mag verlockend klingen, um für einen externen Zugriff direkt drauf los zu programmieren.
Alle Variablen sowie auch Datenstrukturen (DUTs) können in den globalen Variablenlisten (GVLs) lesend als auch schreibend angesprochen werden. Dass beim Schreibezugriff keine Race Conditions entstehen ist in der ADS Bibliothek abgefangen. Aus .NET kann die SPS wie eine große Liste an Variablen betrachtet werden.
Genau diese Offenheit ist aus Sicht einer modernen Softwarearchitektur tendenziell ungünstig. Die Möglichkeit jederzeit beliebige Variablen in einem geschlossenen System (der SPS) zu modifizieren entspricht nicht ganz dem objektorientierten Ansatz. Technisch ist es zwar mit der ADS Anbindung möglich, die Erfahrung zeigt allerdings, dass mit steigender Anzahl an Funktionen der gesteuerten Maschine auch die Zahl der Variablen steigt. Mit einem direkten schreibenden Zugriff auf SPS Variablen werden interne Daten der SPS modifiziert. Nur allzu leicht passieren hier Fehler und es werden von außen Daten modifiziert, die nicht verändert werden dürfen.
Geringe Wiederverwendbarkeit
Ganz abgesehen von möglichen Fehlern während der Programmierung, ist die Schnittstelle zwischen SPS und externer Software praktisch nicht wiederverwendbar. Als Maschinenbauer, der mehrere Maschinentypen herstellt, will man danach trachten, Softwareteile auf allen Maschinen gleich zu halten. Am besten eine Bibliothek für die SPS- und eine Bibliothek für die Steuerungssoftware erstellen.
Besteht die Verbindung zwischen SPS und externer Software nur über die Variablenliste, wird diese mit größter Wahrscheinlichkeit je nach Maschinentyp anders sein. Damit muss die Kommunikation für jede Maschine neu implementiert und getestet werden.
Ansteuerung per JSON
Statt einer Variablenliste bietet sich die Übertragung von JSON Strukturen an. Aktuelle Programmiersprachen verfügen über die passende Libraries zur einfachen Bearbeitung von JSON Daten. Auch in der Beckhoff Programmierplattform TwinCAT, mit der jede Beckhoff SPS direkt als Visual Studio Extension programmiert werden kann, ist ein passender JSON Baustein enthalten.
Die Funktionsbausteine für die JSON Bearbeitung sind in der TwinCAT Bibliothek Tc3_JsonXml enthalten und können kostenfrei in jedes TwinCAT 3 Projekt integriert werden.
Eigene Kommunikationslibrary
Mit Hilfe der Bausteine zum Parsen der JSON Daten FB_JsonDomParser und dem Baustein zum Schreiben von JSON Daten FB_JsonSaxWriter kann eine JSON Kommunikation mit der Steuersoftware umgesetzt werden. Der Vorteil beim Einsatz von JSON ist die leichte Lesbarkeit der Kommandos und die Kommunikation über ein Protokoll bestehend aus Kommandos und entsprechenden Responses.
Die so umgesetzte Kommunikation kann in jeden Maschinentyp als Bibliothek integriert werden. Genau das gleiche gilt auf Seite der Steuerungssoftware. Auch dort kann die Umsetzung in z.B. einem C# Projekt erfolgen und in Form eines NuGet Pakets in alle Softwareprodukte integriert werden.
Mit diesem Ansatz kann jeder Maschinentyp exakt gleich angesteuert werden. Natürlich werden unterschiedliche Maschinentypen unterschiedliche Befehle in der JSON Struktur verstehen. Doch allgemeine Kommandos wie z.B. einen Start- oder Stoppbefehl, das Auslesen von Seriennummer oder Softwareversionen kann auf allen Maschinen gleich erfolgen.
Kommandobasierte Kommunikation
Weg von der unübersichtlichen Variablenliste hin zu eine klar definierten Befehlsstruktur und den passenden Parametern. Das Protokoll zwischen SPS und Steuersoftware kann zu Projektbeginn spezifiziert werden. Wie dann die Umsetzung der Funktionen zur Steuerung der Maschine auf der SPS erfolgt und welche Variablen und Funktionen dafür notwendig sind, ist für die Kommunikation nicht mehr von Bedeutung.
Egal ob Sie als Maschinenhersteller beide Softwareteile selbst entwickeln oder Teile von einem Partner entwickeln lassen, in jedem Fall vereinfacht eine Kommunikation basierend auf JSON Umsetzung und Tests der Anlage.
Der Kommunikationsteil kann bereits unabhängig von den Maschinenfunktionen getestet werden. Neue Kommandos können jederzeit ergänzt werden. Sollten Kommandos auf der Maschine noch nicht umgesetzt sein, entstehen keine Fehler. Fehlende Befehle werden einfach ignoriert und eine JSON Response mit einer Info an die Visualisierung zurückgegeben.
Beispiel für ein einfaches Maschinenprotokoll
Für die folgende Implementierung der JSON Ansteuerung wird ein Maschinenprotokoll verwendet, welches einen Befehlssatz mit 5 Befehlen umfasst. Je nach Befehl können zusätzliche Parameter als JSON Struktur mitgeschickt werden.
Um das Tracking in der SPS als auch in Steuersoftware über gesendete Befehle und empfangene Responses zu vereinfachen, wird mit jedem Befehl eine genierte GUID mitübertragen.
Im gezeigten Beispiel ist nur die Kommunikation in eine Richtung, von der Steuersoftware auf die SPS, umgesetzt Die Gegenrichtung wird in der Praxis mit dem gleichen Konzept implementiert. Die SPS schreibt in eine Variable einen Befehl im JSON Format. Die Steuersoftware registriert diese Variable per ADS als Event und wird damit bei neuen Daten informiert. So kann in beide Richtungen mit Kommandos kommuniziert werden.
Zu jedem Befehl gibt es einen Status über die Abarbeitung: ob der Befehl erfolgreich ausgeführt werden konnte, oder ob ein Fehler aufgetreten ist. Je nach Befehl werden zusätzlich zum Status Responseparameter übertragen.
Implementierung in TwinCAT 3
Im folgenden Abschnitt ist eine Referenzimplementierung in TwinCAT 3 gezeigt. Die SPS wird mit 5 Befehlen über die JSON Struktur angesteuert:
- Start
- Stop
- Alive
- MachineSerial
- SoftwareVersion
Die Befehle initiieren in der SPS einen Vorgang oder fragen nur Daten ab. Nicht unterstützte Befehle werden ignoriert.
Die von der Steuersoftware generierten JSON Daten werden per ADS Zugriff in eine Variable in die SPS geschrieben. Die Variable ist als DUT angelegt und enthält neben den eigentlichen JSON Daten eine GUID zur einfachen Feststellung, ob ein neues Kommando erhalten wurde:
Der Funktionsblock CommandReceier wertet die GUID aus und startet bei Erhalt einer neuen GUID die Methoden zum Parsen der JSON Daten. Das Parsen erfolgt wie oben beschrieben mit den TwinCAT Bibliotheken. Es wird aus der JSON Struktur das Kommando extrahiert. Falls ein unterstütztes Kommando gefunden wurde, wird die passenden Methode zum Verarbeiten des Kommandos aufgerufen:
In der Methode zum Verarbeiten des Start-Befehls wird noch ermittelt, ob auch die notwendigen Parameter in der JSON Struktur vorhanden sind. Werden sie gefunden, wird der Startvorgang noch mit den entsprechenden Details versorgt, z.B. ob in unserem Beispiel die Maschine im „Fastmode“ gestartet werden soll.
Konnte alles korrekt ausgewertet, werden die entsprechenden Variablen gesetzt oder Methoden aufgerufen und lösen auf der Maschine die gewünschten Abläufe aus.
Fazit
Die Verbindung einer Steuersoftware per ADS Direktzugriff auf Variablen ist der Standardweg für eine Beckhoff Ansteuerung. Bei Projekten mit einer umfangreichen Variablenliste oder für eine verbesserte Wiederverwendung können Sie mit der beschriebenen Vorgehensweise auf eine kommandobasierte JSON Kommunikation wechseln.
PS: Das passende TwinCAT Gegenstück in unserem Beispiel Source Code ist ein .NET / C# Projekt. Darin werden die 5 Befehle mitsamt den notwendigen Parametern als JSON erzeugt und per ADS in die SPS geschrieben.
