Major-Release CoDeSys V3: Was sind die Vorteile?

Dass die IEC6113-3 als Automatisierungsnorm zumindest in Europa etabliert ist, stellt heute niemand in Abrede. Und dass die Firma 3S-Smart Software Solutions GmbH mit ihrem SPS-Programmiersystem CoDeSys daran ihren Anteil hat, ist auch unstrittig. Jetzt haben viele Hersteller die Umstellung auf die neue Version 3 der Software angekündigt. Damit vollzieht CoDeSys V3 nicht weniger als die Umstellung auf die objektorientierte Programmierung, wie sie in der IT-Welt bereits seit langem üblich ist. Es handelt sich also um ein echtes Major-Release, das für das Laufzeitsystem zwingend neue Geräte erfordert. Daher fragen sich viele Anwender, ob sich ein Umstieg für sie lohnt. Welche Produkt-Eigenschaften machen einen Umstieg sinnvoll oder sogar notwendig? Was die neue Version bringt und was Anwender davon haben, zeigt der folgende Beitrag. Veränderungen der Architektur Um die zahlreichen Anforderungen vom Markt an ein neues CoDeSys abdecken zu können, ist die gesamte Programmiersoftware jetzt komponenten-orientiert aufgebaut. Das Rückgrat des Gesamtsystems sind System-Komponenten, die alles bieten, was eine Automatisierungsplattform ausmacht. Sie sind nicht nur Rahmen zum Einhängen von Fenstern und Menüs, hier kann z.B. ein Editor auch Variablen zum Online-Monitoring anmelden, ein Stück Code als Strukturierten Text an die ­Codegeneratoren übergeben oder eine IEC-Adresse auf Gültigkeit überprüfen lassen. Auf Basis dieser System-Komponenten sind jetzt alle bekannten Programmier-Eigenschaften des IEC-Tools als Plug-Ins realisiert. Sämtliche Programmier-Editoren (AWL/KOP/FUP, ST, CFC, AS), die Compiler zur Generierung von ausführbarem Code für die Steuerung, sowie Konfiguratoren und zahlreiche weitere Module stehen als Plug-Ins zur Verfügung. Aber eine neue System-Architektur bringt dem Anwender erst einmal herzlich wenig. Bei CoDeSys V3 ergeben sich jedoch gerade aufgrund der neuen Architektur einige entscheidende Vorteile. Jedem Servicetechniker in der Automatisierung ist folgendes Szenario bekannt: Bei einem Serviceeinsatz stellt sich heraus, dass eine kleine Änderung im Steuerungsprogramm nötig ist. Das zugehörige Steuerungsprojekt ist hinterlegt, aber der Techniker muss genau diejenige Version des Programmiertools verwenden, mit der das Steuerungsprogramm zuletzt bearbeitet und übersetzt wurde. Dazu hat er auf seinem Rechner mehrere Versionen des Tools installiert. Bleibt zu hoffen, dass die richtige Version dabei ist und er bei der Auswahl der Version keinen Fehler macht. Dieses Problem ist mit CoDeSys V3 gelöst. Jede Plug-In-Komponente erhält eine eigene Versionierung. Zukünftige Versionen können einfach \’dazu-installiert\‘ werden. Ein Komponentenmanager kümmert sich dabei um die korrekte Ablage der einzelnen Komponenten-Versionen. Zu jeder Installation gibt ein \’Versionsprofil\‘ (z.B. \’CoDeSys V3.3\‘) an, welche Komponenten zu dieser Version gehören. Nach dem Start des Programmiersystems wird dann per Default das zuletzt installierte Versionsprofil angeboten, es können aber auch beliebige andere installierte Profile ausgewählt werden. In jedem Projekt wiederum wird das Versionsprofil hinterlegt, mit dem das Projekt zuletzt bearbeitet wurde. Zurück zu unserem Servicetechniker: Öffnet er ein ihm unbekanntes Projekt, so erhält er die Abfrage, ob er das Projekt mit dem Profil öffnen möchte, mit dem es erstellt wurde. Ein weiterer großer Vorteil der komponenten-orientierten Architektur: Geräte-Hersteller können nun eigene Plug-In-Komponenten auf Basis der System-Komponenten selbst entwickeln und einbinden. Damit ist CoDeSys V3 eine echte Automatisierungs-Plattform. Das heißt für den Anwender, dass er jetzt von seinem Geräte-Hersteller neben dem IEC 61131-3-Programmiersystem keine weiteren Tools für die Konfiguration oder Inbetriebnahme einzelner Geräte benötigt, sondern alle diese Aufgaben in derselben Oberfläche erledigen kann. Apropos Vereinfachung: Aufgrund der komponenten-basierten Struktur ist es jetzt deutlich einfacher, neue Plug-In-Komponenten zur Feldbus-Konfiguration zu integrieren. Tatsächlich unterstützt das Tool jetzt mit Profibus, CANopen, Device Net und Modbus die wichtigsten klassischen Feldbusse. Natürlich kann der Anwender auch die neuen Ethernet-basierten Feldbusse mit integrierten Tools konfigurieren, wie z.B. Ethercat, Profinet, Sercos III oder Ethernet IP. Damit ist die Vereinfachung wiederum bei den Anwendern angekommen: Sie können alle diese Bussysteme in einer Applikation verwenden und benötigten dazu nur ein einziges SPS-Programmiersystem. Bei CANopen, Ethercat und Sercos III deckt CoDeSys neben der Konfiguration auch den Protokoll-Stack auf Basis von in ST geschriebenen Bibliotheken ab. Objektorientierte Programmierung Bereits in der derzeit gültigen Form der IEC61131-3 sind objektorientierte Ansätze enthalten. Derzeit arbeiten die IEC (\’International Electrotechnical Commission\‘) sowie die DKE (\’Deutsche Kommission Elektrotechnik Elektronik Informationstechnik im DIN und VDE\‘) an einer Erweiterung der Norm, die dann auch die objektorientierte Programmierung von Steuerungen berücksichtigen wird. Hat man dies den Steuerungsprogrammierern bislang nicht zugemutet, so hat sich doch gezeigt, dass mehr und mehr Anwender heutzutage mit der Hochsprachen-Programmierung vertraut sind. Das ist auch der Grund, warum in CoDeSys V3 die Möglichkeit der objekt-orientierten SPS-Programmierung in den Sprachen der IEC61131-3 von Anfang an implementiert wurde. Heute werden 90% aller größeren Softwareprojekte für PCs in objektorientierten Sprachen realisiert. Der Nutzen in Punkto kürzere Entwicklungszeiten und bessere Wiederverwendbarkeit von Softwaremodulen ist trotz anfänglicher Skepsis längst bewiesen. Warum sollte dieser Nutzen den Entwicklern großer Steuerungsprogramme vorenthalten werden? Dafür wurden, ähnlich wie bei der Erweiterung von C auf C++, einige neue Schlüsselworte eingeführt. Mit deren Hilfe stehen alle wichtigen Eigenschaften der Objektorientierung, wie Klassen, Methoden, Vererbung und Polymorphie, zur Verfügung. Natürlich sind dazu auch die Codegeneratoren (Stichwort \’dynamisches Linken\‘) erweitert worden. Erleichtert hat diese Erweiterung die Tatsache, dass mit dem Funktionsbaustein bereits eine \’quasi\‘-Klassendefinition in der IEC 61131-3 zur Verfügung steht. Funktionsbausteine bilden deshalb die Grundlage dieser Erweiterung. Die Schlüsselworte wurden der objektorientierten Programmiersprache Java entlehnt. Programmierern mit objektorientierter Vorbildung wird ein Einstieg in die Welt der OOP mit CoDeSys deshalb leicht fallen. Bei der Implementierung von OOP wurde darauf Wert gelegt, dass die Objektorientierung für Anwender optional bleibt. Das heißt, Anwender können wie bisher in CoDeSys V3 auch \’klassische\‘ SPS-Programme in AWL, FUP oder KOP erstellen, ohne sich mit der Objektorientierung auseinandergesetzt zu haben. Doch auch diese Anwender können von der Objektorientierung profitieren, ohne dass sie sich darüber im Klaren sind: Bibliotheken, die er funktional verwendet, können sehr wohl objekt-orientiert erstellt worden sein. Der Vorteil: Durch die bessere Wiederverwendbarkeit werden die verwendeten Bibliotheksbausteine effektiver realisiert und sind vor allem wesentlich weniger fehleranfällig. Verbesserungen in den Editoren Was den meisten Anwendern zuallererst auffällt, ist die Weiterentwicklung der IEC61131-3-Editoren. So sind beispielsweise die Programmier-Editoren Anweisungsliste (AWL), Kontaktplan (KOP) und Funktionsplan-Diagramm (FUP) in einem einzigen Editor zusammengefasst worden. Mit diesem neuen Editor kann man jetzt während der Programmierung die Ansicht des Programmcodes beliebig umschalten. Der Vorteil für den Anwender: Er kann bei der Applikationserstellung immer mit der Programmier-Sprache arbeiten, die ihm gerade am geeignetsten erscheint. Und das ohne Konvertierungen oder die Notwendigkeit, den Programmteil in verschiedene einzelne Programmbausteine zu zerlegen. Auch die \’Usability\‘, das heißt die Bedienbarkeit jedes Editors, ist noch einmal deutlich verbessert worden: Der AWL-Editor ist jetzt tabellen-orientiert, was Vorteile bei der Programmierung bringt. Bei der Programmierung mit KOP oder FUP kann der SPS-Programmierer zusätzlich zur Programmierung mit der Tastatur auch Operatoren und Netzwerke direkt aus einer Werkzeug-Leiste per Drag&Drop einfügen. Darüber hinaus stehen ihm kleine, aber nützliche Zusatz-Funktionen zur Verfügung. So kann z.B. eine Flankenerkennung schneller als durch einen Operator-Aufruf erfolgen: wie beim Einfügen einer Negation im FUP-Editor, kann man jetzt auch eine Flankenerkennung einfach per Mausklick vor einen Eingang setzen. Der Editor für die Ablaufsprache bietet in V3 wie auch bisher die Möglichkeit, gemischt echte IEC61131-3-Schritte mit Qualifier und Aktionsaufruf und vereinfachte Schritte einzufügen. Letztere entsprechen einem IEC-Schritt mit Qualifier \’N\‘ und werden somit nur solange abgearbeitet, wie der jeweilige Schritt aktiv ist. Die Bearbeitung der Schritt-Eigenschaften ist für den Anwender ebenfalls vereinfacht worden: In einem beliebig positionierbaren Eigenschaftsfenster kann der Anwender sofort alle Schritt-Eigenschaften sehen und editieren. Neu ist auch die Möglichkeit, mehrere Schritt-Transitions-Kombinationen in Makros zusammenzufassen, um die Übersichtlichkeit des Programmcodes zu erhöhen. Mit einer Vielzahl von Vereinfachungen setzt der neue Editor für den Strukturierten Text die Messlatte wieder ein Stück höher. Wenn SPS-Programmierer z.B. ST-Konstrukte zur bedingten Programmierung oder für die Erstellung von Schleifen erstellen, so übernimmt das System für den Programmierer eine Reihe kleiner Routine-Aufgaben: Laut IEC61131-3 muss z.B. eine bedingte Programmierung mit IF oder CASE immer mit einem entsprechenden END-Kommando beendet werden. CoDeSys fügt dieses Kommando automatisch ein und rückt den Code automatisch auf die richtige logische Ebene. Dadurch bleibt der Code übersichtlich. Bei verschachtelten Schleifen oder Bedingungen zeigt CoDeSys beim Klick auf eines dieser Kommandos sofort das zugehörige Kommando an, z.B. IF END_IF. Selbiges gilt auch für die Verwendung von Klammern. Zusätzlich werden zusammengehörige Programmzeilen neben dem Code gekennzeichnet. Im ST-Editor kann die Übersichtlichkeit des Codes erhöht werden, in dem man z.B. größere Programm-Konstrukte einfach zusammenfaltet, so dass nur noch die Anfangs- und Endezeile zu sehen sind. Damit können Anwender die Ansicht einer beispielsweise komplexen geschachtelten IF-Abfrage auf zwei Zeilen reduzieren. Neu sind auch einzeilige Kommentare, die man nur mit dem Kommentar-Anfang \’//\‘ starten muss. Durch diese Vereinfachung kann der Anwender leichter als bisher seine SPS-Applikation im Quellcode dokumentieren. Compiler und Debugging Ein zentraler Bestandteil bereits in CoDeSys V2.3 waren seine Compiler- und Debugging-Eigenschaften. Auch hier findet der Anwender Veränderungen, die seine tägliche Arbeit erleichtern. Neu ist die Möglichkeit, den Programmcode der Applikation durch Pragma-Anweisungen bedingt zu kompilieren. Gerade in Maschinen-Familien, die ausgehend von einem Basisaufbau mit verschiedenen Optionen und Modulen ausgestattet sind, kommt diese Eigenschaft versierten SPS-Programmierern zugute. Sie können jetzt für alle Maschinen-Mitglieder eine komplette SPS-Applikation mit sämtlichen Maschinen-Optionen erstellen. Den Umfang der Applikation passt man lediglich durch einen oder mehrere Parameter an die gewünschte Maschinen-Konfiguration an. Dazu muss keine Zeile im SPS-Programm geändert werden. Natürlich kann man auch in CoDeSys V3 wieder Programmcode in Bibliotheken kapseln und ihn für den Aufruf in verschiedenen Applikationen bereitstellen. Neu ist, dass man solche Bibliotheksfunktionen auch im Rahmen der Applikation debuggen kann. Das heißt, bei der zeilenweisen Ausführung des Applikationscodes werden solchen Bibliotheksroutinen nicht mehr als eine einzige Zeile in Echtzeit abgearbeitet, sondern können ebenfalls zeilenweise durchgearbeitet werden. Dazu muss dem Anwender selbstverständlich der Quellcode der Bibliothek vorliegen. Bei der Fehlersuche steht dem Anwender jetzt auch eine verfeinerte Fehlersuche mit Breakpoints zur Verfügung. So kann man die Breakpoints jetzt im Projekt abspeichern, um sie später wieder zu verwenden. Insgesamt ist das Handling für das Anlegen, Aktivieren und die Verwendung von Breakpoints flexibler geworden: Sie können auf einzelne Tasks beschränkt oder mit Bedingungen versehen werden. Dadurch kann die Fehlersuche sehr viel feingranularer erfolgen. Oberfläche Neu im Vergleich zur Version 2.3 sind die Anpassungsmöglichkeiten der Arbeitsoberfläche. Zwar bewegt sich der Anwender in CoDeSys V3 komplett in einer einzigen Windows-Applikation und muss sich auch weiterhin nicht mit mehreren Fenstern herumschlagen. Aber dieses eine Fenster kann er nach seinen Vorlieben gestalten, indem er z.B. die Fenster für den Programm-Baum, für die Eigenschaften, die Werkzeugleiste usw. positioniert. Auch mehrere Editor-Fenster können über- oder nebeneinander positioniert werden. Gleiches gilt für Anzeige-Fenster, z.B. für die Meldungen oder die Querverweisliste. Jedes Fenster hat eine Standard-Position, die per Mausklick wiederhergestellt werden kann. Neu ist auch die Möglichkeit, die Menüstruktur und die Hotkey-Belegung an die eigenen Vorlieben anzupassen. Fazit Auch wenn hier nur ein Teil der Eigenschaften vorgestellt werden konnte, mit denen CoDeSys V3 gegenüber der weit verbreiteten Version 2.3 ausgestattet ist, merkt man sofort, dass der Umstieg mehr als ein Update darstellt. Die Einführung der Objektorientierung ist das deutlichste Zeichen dafür. Bei der Neuentwicklung konnten viele Anregungen und Forderungen von SPS-Programmierern gehört und berücksichtigt werden. Auf der kommenden SPS/IPC/Drives gehört V3 auf jeden Fall für alle SPS-Programmierer zum Pflichtprogramm. SPS/IPC/Drives: