Von der OOP in der IEC61131-3 profitieren

\’Polymorphie\‘ – was sich für Menschen ohne Kenntnisse der Hochsprachenprogrammierung erst einmal anhört wie eine seltene Erkrankung, ist eine nützliche Eigenschaft der objektorientierten Programmierung. Sie ermöglicht das dynamische Binden von Programmcode. Im ersten Teil der Artikelserie wurde diese Eigenschaft bereits kurz angerissen, deren Nutzen nachfolgend erläutert wird. Liefervarianten einer Maschinenreihe per Interface Ein Applikationsprogrammierer entwickelt ein SPS-Programm, das ohne große Änderungen auf verschiedenen Liefervarianten einer Maschinenserie verwendet werden soll. In allen Varianten werden Antriebe von der SPS angesteuert. Allerdings entscheidet der Endkunde z.B. aufgrund von Leistungsdaten oder Kenntnisstand seines Wartungspersonals, welche Antriebsmodelle letztlich eingesetzt werden. Trotz der Unterschiede verfügen alle Antriebe über Funktionen wie \’HomePosition\‘, \’HasError\‘ oder \’MoveAbsolute\‘. Schreibt der Applikationsprogrammierer sein Programm wie bisher funktional, so muss er für jede Variante der Maschine sämtliche Funktionsaufrufe anpassen, die auf die Antriebe zugreifen. Mit den Möglichkeiten der OOP kann er jedoch Arbeit und Fehlerquellen reduzieren. Dazu definiert er alle einheitlichen Aufruf-Funktionen für die verwendeten Antriebe als Methoden in einem Interface. Das Interface enthält für jede Methode nur dessen Aufrufschnittstelle, also Inputs und Outputs, aber keine lokalen Variablen und keinen Code. Mit spezifischem Programmcode füllen wird der Programmierer die Methoden, wenn er sie in einem Funktionsbaustein mit dem neuen Schlüsselwort Implements einbindet. Der Funktionsbaustein wird damit zur \’Klasse\‘ im Sinne der OOP. Die erforderliche Instanziierung der Funktionsbausteine nimmt der Programmierer typischerweise in einem übergeordneten Baustein vor, der diese Instanzen zentral verwaltet. Dynamisches Binden über ein Array Wie in Bild 1 können mehrere solche Instanzen (\’Objekte\‘) in einem Array zusammengefasst werden. Überraschend dabei: Der Datentyp des Arrays muss nicht mehr BOOL, INT bzw. ein Funktionsbaustein, sondern kann jetzt ein Interface sein – im Beispiel das Interface iDrive. Somit kann das Array faktisch mit ganz unterschiedlichen Inhalten gefüllt werden – je nach instanziiertem Funktionsbaustein. In Bild 1 werden die einzelnen Felder des Arrays gleich bei der Deklaration gefüllt – mit Instanzen unterschiedlicher Funktionsbausteine für die verschiedenen Antriebe. Über das Array kann der Programmierer indiziert per Schleife auf die Methoden in den FB-Instanzen zugreifen. Dabei ist es erst einmal egal, welche Methoden letztlich wirklich aufgerufen werden – die Zuordnung erfolgte über die Füllung des Array. Damit wird der eigentliche Methoden-Aufruf dynamisch gebunden. Verwendet die nächste Maschinenvariante andere Antriebe als die in Bild 1 definierten, so muss der Applikationsprogrammierer im Deklarationsteil des Hauptbausteins nur die verwendeten FB-Instanzen für die neu einzusetzenden Funktionsbausteine deklarieren. Eine Änderung der Methoden-Aufrufe ist nicht mehr erforderlich! Dynamisches Binden über einen Funktionsbaustein Statt die Methoden über ein Array dynamisch aufzurufen, kann der Programmierer auch einen weiteren Funktionsbaustein erstellen. Dieser bekommt als Eingangsparameter ein Interface übergeben. So weiß der FB CheckDriveError in Bild 3, dass er die Methode HasError aufrufen wird. Den gewünschten FB bzw. die Klasse, in der die Methode aufgerufen wird, übergibt der Programmierer als Instanz des Antriebs, z.B. wiederum bei Aufruf aus dem Hauptbaustein. Auch bei dieser Vorgehensweise kann der Programmierer die verwendeten Antriebe zentral an einer Stelle ändern, ohne dass er sämtliche Aufrufe im Projekt mühsam durchforsten muss. Wiederverwenden von Methoden – Vererbung Betrachten wir noch einmal die Funktionsbausteine für die spezifischen Funktionen der Antriebe. Je nach den Antriebseigenschaften muss der Applikationsentwickler alle erforderlichen Methoden einzeln ausprogrammieren. Oftmals haben ähnliche Antriebe vom gleichen Hersteller jedoch identische Basis-Funktionen, z.B. zur Fehlerabfrage oder Homing. Ist das der Fall, so möchte man diese identischen Funktionen auch weiterverwenden. In der OOP wird genau dieser Wunsch durch die Vererbung erfüllt. Dazu legt der Programmierer einen neuen Funktionsbaustein an, der einen bestehenden Baustein (eine \’Basisklasse\‘) mit dem neuen Schlüsselwort Extends erweitert. Dieses neue Objekt verfügt damit sofort über alle Methoden der Basisklasse, ohne dass sie noch einmal im Objektbaum als Kind angezeigt werden. Das Objekt kann seinerseits weitere Interfaces implementieren bzw. eigene Methoden zugewiesen bekommen. Typischerweise werden aber nicht alle Methoden von CANopen_DriveC identisch mit CANopen_DriveA sein. So muss z.B. die Methode \’MoveAbsolute\‘ anders ausgeführt werden. Dazu kann der Applikationsentwickler für CANopen_DriveC die Methode \’MoveAbsolute\‘ anlegen, die ursprünglich bereits durch die Vererbung definiert war, und sie entsprechend ausprogrammieren. Die ursprünglich geerbte Methode wird damit überschrieben und ist für diesen Funktionsbaustein nicht mehr gültig. Geerbten und spezifischen Programmcode kann der Programmierer elegant miteinander verknüpfen: Wie in Bild 4 legt er dazu eine neue Methode an und überschreibt damit die geerbte. Im Programmcode der neuen Methode ruft er aber mit dem Befehl Super^.MoveAbsolute(); zunächst einmal den Code der überschriebenen Methode auf. Anschließend erweitert er die Abarbeitung um den spezifischen Programmcode. Fazit Diese einfachen Beispiele machen deutlich: Die OOP ist nützlich, um Applikationssoftware modular und wiederverwendbar zu gestalten. Das gilt für die Programmierung in Hochsprachen genauso wie für die Programmierung von Steuerungen in der Automatisierungstechnik. Automatisierer können mit CoDeSys ihre SPS-Applikationen heute schon objektorientiert in IEC61131-3 programmieren – wenn sie das wollen. Es bleiben jedoch Fragen: Wie kann man Daten und Funktionen so kapseln, dass sie nicht versehentlich verändert werden? Wie kann man den Code im Rumpf eines Funktionsbausteins innerhalb einer Methode verwenden? Fortsetzung folgt.