Handling von Daten und Aufrufsinformationen

Wie bereits erläutert, beinhalten Interfaces nur Methoden – Funktionsblöcke aber haben ebenso Daten. Somit stellt sich die Frage: Wie bekommt man über ein Interface den Zugriff auf diese Daten? Einfache Antwort: Man schreibt eine Methode, die das gewünschte Datum zurückliefert, wie etwa \’GetName\‘ oder \’IsReady\‘. Konsequent angewendet erzeugt der Applikationsprogrammierer ziemlich schnell Pärchen von Funktionen der immer gleichen Art, wie z.B. \’GetName\‘ / \’SetName\‘ oder \’IsReady\‘ / \’SetReady\‘. Solche Methodenpaare, die im Wesentlichen nur den Zugriff auf ein Datum freigeben, kann man zusammenfassen zu einem Property. Datenhandling mit Properties Nehmen wir als Beispiel das Interface IDrive vom vorangehenden Artikel der Serie und erstellen wir ein erweitertes Interface ­INamedDrive. Ein Property ist dabei eine Kombination aus zwei Methoden, die den Schreibzugriff bzw. Lesezugriff auf ein Datum kapseln. Für den Benutzer des Properties stellt sich dieses dabei wie eine Variable dar. Der Compiler sorgt automatisch für den Aufruf der richtigen Zugriffsmethode bzw. meldet einen Fehler, wenn diese nicht implementiert ist. So wird man vermutlich INamedDrive im obigen Beispiel nur mit einem lesenden Zugriff auf den Namen ausstatten und damit das Schreiben unterbinden. Im Hauptbaustein PLC_PRG (aus dem vorangegangen Artikel) deklarieren wir einen Funktionsblock CANopen_DriveB_Named, der das neue Interface implementiert. Im Rumpf des Bausteins in Bild 2 kann jetzt auf das Property wie auf eine Variable zugegriffen werden. Will man nun den Zugriff auf komplexe Datentypen wie z.B. eine Struktur erlauben, dann kann ein Property jedoch problematisch sein. Meist will der Applikationsprogrammierer ja nur auf ein einziges Strukturelement zugreifen. Eine Methode, die dahintersteckt, liefert allerdings immer die gesamte Struktur zurück. Das bedeutet: Übergibt man einem Property direkt den Datentyp Struktur, dann werden zu viele Daten kopiert – und das wirkt sich auf die Laufzeit des Programms aus. Wie kann man dieses Problem umgehen? Die Antwort liefert der Datentyp \’REFERENCE TO\‘. Referenzen Eine Referenz ist eine Variable, die immer auf eine andere Variable verweist. Manipuliert man die Referenz, dann manipuliert man eigentlich die referenzierte Variable. Vom Pointer unterscheidet sich die Referenz dadurch, dass man die Referenz nicht explizit de-referenziert, sondern jeder Zugriff direkt auf die referenzierte Variable erfolgt. Ein Beispiel: Natürlich ist das Beispiel in Bild 3 erst einmal nicht sinnvoll, es soll jedoch die Verwendung von Referenzen in sinnvollen Anwendungen erläutern. Eine davon ist die Rückgabe von Daten bei Properties. Für unser Beispielprojekt nehmen wir eine Struktur DriverInfo an, mit den Elementen Name und Version. Statt zwei Properties für den Namen und die Version könnte man auch die gesamte Info als Struktur zurückliefern. Den Funktionsblock Canopen_DriveB_Named geben wir noch eine zusätzliche Methode. Diese liefert nicht einen einfachen Datentyp, sondern eine ganze Struktur zurück. Properties bieten somit die Möglichkeit, einen funktionalen Zugriff auf Daten zu veröffentlichen. Diese Zugriffsform entspricht den Forderungen der OOP nach Datenkapselung und ermöglicht gleichzeitig dem Programmierer den Komfort eines einfachen Datenzugriffs. Wie im Beispiel erläutert, kann der Applikationsprogrammierer solche Properties auch in einem Interface definieren und dadurch indirekt eine Vorschrift über die Daten in einem Funktionsblock formulieren. Eine weitere Verwendungsmöglichkeit von Properties ist die Rückgabe von skalierten Werten: So könnte ein Funktionsblock einen Wert in der Einheit Zentimeter speichern. Mit einem eigenen Property wird der Wert aber in der Einheit Zoll zurückgeliefert. Datentyp-Abfragen auf Interfaces: Casts Das Beispiel führt uns direkt zum nächsten Thema, der Typ-Konvertierung und Typ-Abfragen (Casts). Wir haben in Bild 2 im PLC_PRG ein Array von Elementen vom Typ IDrive definiert. Nur ein Element des Arrays definiert zusätzlich das spezialisierte Interface INamedDrive. Ob der Antrieb jedoch einen Namen hat oder nicht, sprich, ob er das Interface INamedDrive implementiert, kann an der Verwendungsstelle von Bedeutung sein. Dafür muss man zur Laufzeit Typinformation eines Objekts erfragen können. Für diese Aufgabe gibt es in CoDeSys den Operator __QUERYINTERFACE. Er erwartet zwei Operanden: zum einen das Interface-Objekt, von dem man ein anderes Interface erfragen will, zum anderen eine Interface-Variable mit dem Typ, auf den man prüfen will. Der Operator selbst liefert als Ergebnis TRUE, wenn der Cast, sprich die Typabfrage erfolgreich war. Zur Erläuterung verwenden wir den Funktionsblock CheckDriveError (siehe zweiten Teil der Artikelserie) und erweitern ihn um die Ausgabe eines Fehlertexts über die Variable stError. Der Code-Teil in Bild 5 lässt sich leicht nachvollziehen: __QUERYINTERFACE fragt den per Interface IDrive übergebenen Antrieb, ob er zusätzlich auch das Interface INamedDrive implementiert. Ist das der Fall, so gibt stError eine Fehlermeldung mit dem Antriebsnamen, statt einem allgemeinen Text zurück. Ein weiterer Anwendungsfall der Casts ist zwar seltener, aber dennoch möglich: von einer Interface-Referenz wird die Instanz benötigt, auf die sie verweist. In Codesys ist der geeignete Operator dafür __QUERYPOINTER. __QUERYPOINTER erwartet ebenfalls zwei Operanden: eine Interface-Referenz sowie einen Pointer auf einen Funktionsblock. Allerdings muss der Programmierer in diesem Fall selbst dafür sorgen, dass der Typ des POINTERs nach dem Cast auch richtig ist. Das Code-Stück in Bild 6 erläutert eine Verwendungsmöglichkeit des Operators: Von einer Interface-Referenz wird eine Kennung abgefragt, die in diesem Fall dem Typnamen entspricht. Somit weiß der Programmierer, welchen Typ die Instanz hat, auf die die Referenz verweist und er kann gefahrlos mit dem Pointer weiterarbeiten. Fazit Geht man den Weg zur objektorientierten Applikationsprogrammierung innerhalb der IEC61131-3 konsequent weiter, dann helfen Properties bei der Kapselung von Daten. Zusätzliche, auf der OOP basierende Operatoren, bewahren auch in komplexen Applikationen den Überblick. Der Nutzen: einfach wiederverwendbare Steuerungsprogramme. Der Sprachumfang des marktführenden IEC61131-3 Programmiersystems CoDeDys erfüllt die diesbezüglichen Erwartungen von erfahrenen Applikationsprogrammierern.