Mit der Einführung der Version V3.5 von Codesys im Jahr 2012 hat 3S-Smart Software Solutions die SPS-Programmierung auf eine grundlegend neue Basis gestellt. Damit ist sie mehr als nur ein „Nachfolger“ von Codesys 2.3. – Ein Erfahrungsbericht aus Sicht eines Systemanbieters.

Wenn ein Software-Anbieter nach rund einer Dekade einen Relaunch seiner bestehenden Basis unternimmt, kann das nicht in kleinen Schritten und nahtlosen Übergängen geschehen. So auch bei Codesys, das sich in der Version 2.3. als Tool zur Hardware-unabhängigen SPS-Programmierung auf breiter Front etabliert hat. Mit der neuen Version 3.5 hat dieser Standard mehr als nur eine Evolution erfahren. Dies birgt naturgemäß Schwierigkeiten für die Umstellung in sich – bietet aber andererseits große Chancen.

Zugegeben: Zum Teil steht noch zu wenig Hardware zur Verfügung, die von Codesys V3.5 unterstützt wird. Teils existieren zudem – wie fast immer bei entscheidenden Neuerungen – Berührungsängste gegenüber der neuen Technik, weshalb Codesys V3.5 derzeit noch nicht in dem Maße den Weg in die Applikation findet, wie es die zu erwartenden Vorteile vermuten ließen. Doch was wird konkret besser durch die neue Tool-Generation? Auf diese Frage gibt es viele Antworten, die sich wie folgt zusammenfassen lassen:

• Neue optimierte Entwicklungsober­fläche für höhere Produktivität.
• Feinere Modularisierung und bessere Wiederverwendung der Programmierung durch Objektorientierung.
• Einfachere Inbetriebnahme durch die besser strukturierte Bedienoberfläche.
• Integration einer neuen Visualisierung, die HTML5-fähig ist (für Smart Phones, Mobile Remote etc.).
• Einfaches Engineering, auch für CAN­open und Ethercat.
• Einfachere Anbindung von E/As, Motion- und Safety-Funktionen.
• Klare Versionierung für genaue Bezeichnung und Funktionsbeschreibung – ein nicht zu unterschätzender Vorteil gerade im Servicefall.
• Internationalisierung bei der Sprache (Unicode wird nativ unterstützt).

Die Entwicklungsoberfläche

Wer die neue Entwicklungsoberfläche nutzen will, wird etwas umlernen und umdenken müssen. Der Lohn dafür ist dann aber eine verbesserte Funktio­nalität, eine bessere Beherrschung der Komplexität sowie ein moderneres „Look&Feel“. Einfach ausgedrückt könnte man sagen, dass Codesys V3 mit der neuen Entwicklungsoberfläche aus der klassischen „SPS-Ecke“ herauskommt. Mit anderen Worten: Der V3-Anwender programmiert seine Anwendungen auf dem PC, bevor diese auf die SPS gespielt werden, und befindet sich vom Look&Feel her auch eher in der PC-Welt. Zudem kann er erstmals die Möglichkeiten der objektorientierter Programmierung nutzen.

Bei komplexen Anwendungen reichten bisher die Sprachelemente der Ver­sion 2.3 nicht immer aus. Zum Beispiel gab es bei den benutzerdefinierten Datentypen keine UNION, keinen LTIME-Datentyp für eine Nanosekunden-Auflösung oder einen WSTRING für die Unicode-String-Verarbeitung. Mit der Version 3.5 hat sich dies geändert: Hier sind viele Aspekte enthalten, die Embedded-Programmierer aus der C-Programmierung kennen – etwa die bedingte Code-Compilierung oder der indizierte Zugriff auf einzelne Elemente des Datentyps STRING. Allerdings wäre es übertrieben, Codesys V3 mit der C-Programmierung zu vergleichen, denn es geht eher in die Richtung von übersichtlicher und strukturierter Codierung – das zeigt auch die mögliche Integration eines Source-Code-Modellierungstools für UML (Unified Modeling Language).

Der Vergleich mit der C-Programmierung soll lediglich illustrieren, dass man in Sachen Software-Architektur die Anwendung in Module und Sektionen unterteilen und dafür die Anwendung noch einmal extra generieren kann. Gerade der Maschinenprogrammierer kann dadurch seine Applikation besser modularisieren und die maschinennahen Elemente kapseln.

Bei Codesys 2.3 werden Bausteine kopiert und dann geändert, was zu einer ständigen Veränderung des Source Code führt. Hie­runter leidet jedoch die einfache Reproduzierbarkeit. Auch diesbezüglich hat sich etwas getan: Künftig kann sich der Anwender durch die neue Objektorientierung eine einheitliche Datenbasis schaffen und arbeitet dann nur noch an Erweiterungen. Nach diesem Prinzip der „Vererbung“ lassen sich Varianten einfacher realisieren. Ferner sorgt dieses Prinzip für eine Vereinfachung der Inbetriebnahme, indem speziell dafür ausgelegte Interfaces vorbereitet werden, die dem Bediener die Prozesse erleichtern. Kurzum: Das Copy&Paste-Zeitalter gehört nun der Vergangenheit an.

Visualisierung und Programmcode wachsen zusammen

Gerade bei der Visualisierung stellt Codesys V3.5 einen Quantensprung im Vergleich zu den Vorgängerversionen dar. Sie wirkt nicht wie Windows 95, sondern ist mit dem gesamten Erscheinungsbild im Jahr 2013 angekommen. Über den Aspekt der Modernität hinaus ergeben sich eine Reihe weiterer neuer Optionen: Beispielsweise ist es möglich, den Programmcode sowie die Visualisierung direkt zu einem Funktionsbaustein zusammenzufassen und in Modulen zu kapseln. So kann eine Bibliothek nicht nur die Methode beinhalten, sondern auch die passende Visualisierung.

Die einmal erstellte Visualisierung ist zudem auf vielen unterschiedlichen Plattformen verwendbar – etwa bei  der Target-Visualisierung (zum Beispiel auf Display-Steuerungen) oder bei der HTML5-basierenden Web-Visualisierung (zum Beispiel auf Ethernet-Terminals oder Smart-Phones). Nicht zuletzt wurden das Layout, die Anzeige der Funktionen sowie die Darstellung der an­geschlossenen Geräte in einer übersichtlichen, projektorientierten Baumstruktur gegliedert. Dort finden sich die projektierten Geräte sowie Projekt- und Zielsystemeinstellungen, die in der früheren Version noch verstreut und damit nicht dem einzelnen Projekt zugeordnet waren. So bedeutet die neue Bedienoberfläche für viele Codesys-Anwender zwar ein Umdenken, was aber in der Praxis, sprich bei der Erstellung der Visualisierung, in aller Regel keine Probleme bereitet.

Ein Manko der V3-Visualisierung ist der derzeit noch spärlich ausgestattete Codesys-Baukasten: Er beinhaltet zwar Grundelemente wie Rechtecke, Buttons, Tabellen, Lampen und Schalter, könnte jedoch beispielsweise in puncto Trendanzeige und Alarmbehandlung besser ausgebaut sein. Der Hersteller bietet zwar ein Toolkit, mit dem man selbst Elemente bauen kann; dies ist jedoch entsprechend aufwendig. So haben Systemanbieter wie Berghof auch diesbezüglich Antworten parat, indem sie selbst Visualisierungselemente für die Anwender „nachrüsten“ – zum Beispiel Elemente wie Trendgrafik, Alarmtabelle oder Zeigerinstrument.

HTML 5 – für neue Smart-Anwendungen

Die Codesys-Visualisierung mit HTML 5 vereinfacht den Zugriff per Tablet.

© Berghof

Wie bereits angesprochen, lässt sich die Visualisierung mit Codesys V3.5 vollständig in HTML 5 erstellen. Damit ist es jetzt möglich, „abgekoppelte“ Visualisierungen zu erstellen, so dass ein reiner Bediener beziehungsweise Operator mit einer Mobilanwendung einfachen Zugriff auf seine Anwendung oder die Daten erhalten kann – und zwar ohne dass er damit gleich direkt auf die Maschinendaten zugreifen muss. In diesem Thema steckt mehr Zukunftspotenzial, als auf den ersten Blick zu vermuten wäre – zum Beispiel hinsichtlich der Verschmelzung der Industrieautomation mit der Büro- und Office-Welt.

Das beginnt damit, dass der Manager oder Produktionsleiter in seinem Büro die Performance-Werte mobil auslesen kann, und zwar völlig unabhängig von der eigentlichen Programmierung der Maschinendaten. Auch das Servicepersonal kann sich damit einfach via Tablet in eine Maschine einloggen, ohne dass die Programmierung dadurch „angefasst“ wird. Manche Maschinen bräuchten so kein Display mehr.

Softmotion und integriertes Ethernet

Screenshot mit dem Projektstrukturbaum: In dem dargestellten Projekt werden Standard-Softmotion-Bausteine von Codesys für einen Ethercat-Antrieb zusammen mit der Motion-Bibliothek von Berghof für einen CANopen-Controller betrieben.

© Berghof

Auch die Hardware-Projektierung hat sich verändert. So ist es in der Praxis sehr hilfreich, alle projektrelevanten Hardware-Komponenten und deren Einstellungen direkt in einer Projektbaum­strukur erfassen zu können. Denn die Motion-Funktionen werden in derselben Struktur mit im Projektbaum eingegliedert, was die Übersichtlichkeit deutlich verbessert. Früher musste der Anwender dafür oft in vielen unterschiedlichen Registerelementen hin und her navigieren.

Insbesondere die Einbindung von Antriebskomponenten, die zum Beispiel Ethercat als industrielles Ethernet-Protokoll nutzen, ist jetzt in der Version 3.5 integriert. Damit kann das zuvor erforderliche zusätzliche, externe Tool entfallen, was das Handling deutlich komfortabler macht. Gleichzeitig sind die Komponenten übersichtlich in der Projektbaumstruktur angeordnet und werden mit Standard-Softmotion-Bausteinen eingesetzt. Und im gleichen Projektbaum lassen sich dazu parallel zum Beispiel CANopen-Antriebskomponenten mit einer speziell für sie angepassten Softmo­tion-Bibliothek betreiben.

Im Hinblick auf eine effiziente Software-Entwicklung für SPS-Projekte mit Feldbus- und Industrial-Ethernet-Komponenten ist eine leistungsfähige Unterstützung durch Tools der Schlüssel zum Erfolg. Da ist es wichtig, dass die relevantesten Ehernet-Protokolle wie Ethercat, Profinet Device oder auch BACnet integriert sind. Identisch wie für CAN­open- und Profibus-Feldbus-Module ist in Codesys nur die entsprechende Konfigurations-Datei erforderlich und schon können die Kommunikationsparameter eingestellt werden. Und weil alles in einem Tool integriert ist, lassen sich zum Beispiel die E/A-Daten im Online-Betrieb innerhalb des Projektbaumes beobachten. Falls für Sondermodule eine Kommunikation über Systembibliotheken erforderlich sein sollte, können Systemdienstleister dies individuell nachrüsten.

Versionierung und Hardware-Unabhängigkeit

Was das Thema Versionierung betrifft, so geschieht diese bei Codesys V3 und der zugehörigen Bibliotheken jetzt auf dieselbe Art wie bei den bekannten Betriebs-
systemen oder bei Browserprogrammen. In der Vergangenheit waren insbesondere Codesys-Bibliotheksfunktionen nur über den Datumstempel zu unterscheiden. Jetzt ist auf einfache Weise ermittelbar, welche Version im Einsatz ist und was damit alles installiert ist. Dies eröffnet beispielsweise dem Support des Systemanbieters die Möglichkeit, durch eine einzige Nachfrage sofort den Funktionsumfang einer Bibliothek und der im Projekt verwendeten Targetversion zu erfassen.

Mit der Vielzahl neuer Features in Verbindung mit der Modularität und Erweiterbarkeit der Hardware- und Software-Interfaces erwirbt der Anwender nicht zuletzt ein Stück Unabhängigkeit. So kann er – wenn er das Tool entsprechend einsetzt – seine Applikationssoftware Hardware-unabhängig gestalten. Dazu entkoppelt er mit einem Hardware-Ab­straktionslevel die spezifischen Details von SPS-, E/A- und Motion-Hardware vom Anlagen- beziehungsweise Maschinensteuerungsprogramm. Ein weiteres Beispiel dafür ist der Share-Gedanke mit der Etablierung eines im Aufbau befindlichen Codesys-Stores für Erweiterungen, der ähnlich wie der App-Store von Apple Anwendungen und Programmierbausteine zentral zur Verfügung stellt.

Als Fazit bleibt: Die neue Codesys-Version V3 weist den Weg in die Zukunft der Steuerungsprogrammierung und wird sich über kurz oder lang etablieren. Nicht zuletzt schon deshalb, weil der Support für das alte Paket 2.3 nachlassen wird und die Entwicklungsarbeit bei Codesys komplett auf die neue Version 3.5 ausgerichtet ist.
Und wer auf Industrial-Ethernet-Anbindungen setzt, kommt an der neuen Version ohnehin nicht vorbei.

Schneller ans Ziel via Starterpaket

Berghof bietet das Starterpaket 'Target Support Package' an.

© Berghof

Um dem Anwender den Übergang in die Codesys-V3-Welt zu erleichtern, gibt es von Berghof ein „Starterpaket“. Das so genannte „Target Support Package“ beinhaltet unter anderem diverse Kommunikationsbibliotheken, darunter zum Beispiel eine CAN-Bibliothek, die direkt auf dem Codesys-Standard aufsetzt, aber das Handling der CAN-Nachrichten deutlich vereinfacht. Zudem enthält das Starterpaket die Codesys-Steuerung EC1000, die auf 25 mm Breite eine 400-MHz-CPU sowie eine CAN- und Ethercat-Schnittstelle vereint. Zum Paket gehört auch ein Ethercat-I/O-Modul und ein Ethernet-Terminal für die Codesys-Visualisierung.

Autoren:
Robin Turner ist verantwortlich für den technischen Support bei Berghof Automation,
Jürgen Wanner ist Marketing Manager Controls bei Berghof Automation.