Originally created by: M.Schaber

Mit der Version 3.4 SP3 bringt CoDeSys V3 erstmals eine integrierte Scriptsprache mit.

Anstatt wie im alten BatchMode in CoDeSys V2 eine eigene Sprache zu entwickeln, wurde auf die bekannte und verbreitete SkriptSprache Python in der .NET-Implementierung IronPython zurückgegriffen, und diese in CoDeSys eingebettet. Dies bietet u. A. die folgenden Vorteile:

Allerdings ist der Einstieg in eine neue Sprache immer mit einer kleinen Anfangshürde verbunden. Um den Einstieg zu erleichtern, wollen wir deswegen hier einige Links und kommentierte Code-Beispiele sammeln. Viele Aufgaben kann man durch reines Anpassen und zusammenkopieren aus unseren Beispielen lösen, und sich natürlich auch hier im Forum helfen lassen.

Und da der durchschnittliche CoDeSys-Anwender zumindest in den IEC-Sprachen schon Programmiererfahrung gesammelt hat, sollten Konzepte wie Variablen, Schleifen und Funktionen bekannt sein, und sich leicht auf Python übertragen lassen.

Wer jedoch tiefer in die Sprache einsteigen will, für den empfieht es sich für eigene Experimente, das Python-Standardpaket herunterzuladen und selbst ein bisschen herumzuprobieren - für den Einstieg ist alles dabei, inklusive einer einfachen Entwicklungsumgebung namens IDLE.

Einige Links für den Einstieg in die Sprache Python selbst:

Originally created by: M.Schaber

Die Sprache Python befindet sich gerade in einer Umbruchphase. Zum ersten mal in der 20jährigen Geschichte der Sprache haben sich die Entwickler entschlossen, beim Umstieg von der Sprachversion 2 auf die Sprachversion 3 einige Altlasten über Bord zu werfen. Das ist somit auch das erste (und auf absehbare Zeit einzige) Sprach-Update, das nicht vollständig abwärtskompatibel ist.

Da die .NET-Version IronPython vermutlich erst zum Jahresende in Version 3 verfügbar sein wird, wurde aktuell die Version 2.6.2 eingebunden. Allerdings wollen wir nach Möglichkeit auf die neue Python-Version umsteigen, sobald diese verfügbar ist. Dies wirft dann das Problem auf, dass einige Skripte ggf. nicht mehr kompatibel sind.

Eine genaue Migrationsstrategie steht noch nicht fest, wir werden aber auf jeden Fall versuchen, einen weichen Übergang zu ermöglichen. Hilfreich dabei wird sein, dass es zum einen Konverter gibt, der Python-Skripte automatisch in die neue Syntax konvertiert, und es zum anderen nach aktuellem Stand möglich sein wird, (zumindest für eine Übergangszeit) beide Sprachversionen parallel in CoDeSys einzubinden.

Allerdings sollte es auch problemlos möglich sein, die CoDeSys-Skripte so zu verfassen, dass sie zu beiden Sprachversionen kompatibel sind, wenn man ein paar Kleinigkeiten beherzigt.

Die meisten der Änderungen beziehen sich auf das entfernen veralteter Sprachfeatures (wie z. B. die sogenannten "old style classes") und veralteter Module der Standardbibliothek. Neu geschriebener Code sollte dieses sowieso nicht mehr benutzen, und damit diesbezüglich keine Umstiegsprobleme haben. Einige weitere Punkte wie die Umstellung der Stringtypen betreffen die von uns verwendete IronPython-Implementierung nicht, sondern nur andere Implementierungen der Sprache.

Allerdings gibt es auch ein paar Änderungen, die auch neu geschriebene Skripte betreffen können. Die gravierendsten davon sind:

Print wird vom Statement zur Funktion.

Code wie ```

print 'hallo'

muss zu

print('hallo')

werden. Die neue Syntax bietet einige Vorteile gegenüber der alten, und lässt sich im aktuellen Python 2.6 durch das Statement

from future import print_function

``` aktivieren - dann wird (nur noch) die neue Syntax akzeptiert. Es empfiehlt sich daher, dieses standardmäßig bei allen Skripten zu aktivieren.

Der standard-Divisionsoperator liefert Fließkommawerte zurück.

Die Division zweier ganzer Zahlen mittels des "/"-Operators liefert bei Python 2 einen abgerundeten Integer zurück, "1/2" ist also "0". In Python 3 wird dagegen eine Fließkommazahl zurückgegeben, "1/2" liefert dann also "0.5" zurück. In beiden Python-Versionen gibt es den Operator "//", der sich wie der alte "/"-Operator verhält, also "0" zurückliefert. Mittels des Statement ```

from future import division

``` kann das neue Verhalten für den "/"-Operator aktiviert werden.

Einige Funktionen der Standardbibliothek liefern anstelle von Listen jetzt Views und Iteratoren zurück.

Sofern man nur in einer Schleife über das Ergebnis iteriert, ist keinerlei Änderung erforderlich. Wenn man dagegen die Listenfunktionalität benötigt (z. B. weil man mittels Index darauf zugreifen will), dann muss man das Ergebnis in eine Liste packen, was sich durch den Listenkonstruktor erledigen lässt. Anstelle von ```

foo = map(...)

schreibt man also

foo = list(map(...))

``` und der Code läuft mit beiden Python-Versionen.

Einen detaillierteren Überblick bieten die Webseiten http://wiki.python.org/moin/Python2orPython3 und http://docs.python.org/release/3.1.2/whatsnew/3.0.html (inklusive der Vorgänger für 2.7 und 2.0).

Originally created by: M.Schaber

Die Dokumentation für die Skriptbefehle wurde im Moment aus Zeitgründen leider noch in einer etwas provisorischen Form ausgeliefert. Im CoDeSys Installationsverzeichnis im Unterverzeichnis liegt eine Datei . Dort sind alle CoDeSys-spezifischen Schnittstellen dokumentiert, die für die ScriptEngine zur Verfügung stehen. Diese Datei ist aus dem C# Quelltext autogeneriert, und deswegen zwar inhaltlich vollständig, aber von der Form her noch nicht in die Online-Hilfe integriert, und

Im Namespace _3S.CoDeSys.ScriptEngine.BasicFunctionality (den untersten Punkt im Inhalts-Reiter links aufklappen) liegen die Objekte, die wir den Skripten zur Verfügung stellen. In den anderen Namespaces liegen nur ein paar Enumerationstypen, die aus anderen CoDeSys-Bereichen importiert wurden.

Für die Skripte stehen folgende Einstiegspunkte zur Verfügung:

Projekte:
Die Funktionen der Projekte sind unter "IScriptProject Interface" und "IScriptProjectDeviceExtension Interface" dokumentiert.
Projekte sind auch die Wurzel des Objektbaumes, der z. B. die Geräte und POUs beinhaltet.

Objekte:
Die Objekte selbst sind unter "IScriptObject Interface" dokumentiert. Zudem haben alle Objekte zwei Marker-Eigenschaften: "is_libman" und "is_device". Bei Library Managern liefert ersterer "True" zurück, als Zeichen dafür, dass das Objekt zusätzlich die Kommandos von "IScriptLibManObject" unterstützt. Das gleiche gilt dann für is_device bei Geräten, die dann zusätzlich alles aus "IScriptDeviceObjekt" unterstützen.

Beispiele und Rezepte-Thread

Ich hoffe, das erleichtert den Einstieg etwas.

Ich denke, die beste Strategie ist, sich die Beispiele hier im Forum durchzulesen, mit der Dokumentation quer zu vergleichen, und im Zweifelsfall hier im Forum fragen.

[1] Wen die Details interessieren: CoDeSys ist als modulares Produkt aus knapp 200 Plugins aufgebaut, die im Rahmen unserer "Automation Platform" von unseren OEM-Kunden nahezu beliebig erweitert und ausgetauscht werden können. Aus diesem Grund ist auch die Implementierung unserer Script-Sprache intern modularisiert. Ein Hauptplugin namens "ScriptEngine" stellt die Infrastruktur (Skript-Interpreter, Kommandos, Kommandozeilenoptionen, etc.) bereit. Fünf weitere Plugins, sogenannte ScriptTreiber, stellen die eigentlichen Kommandos[2] für die Skripte zur Verfügung, aufgeteilt nach den Bereichen "System", "Projekt", "Online", "LibraryManager" und "Device". Solche Skripttreiber können Objekte und Typen (Klassen, Interfaces, Enums) zur Verfügung stellen, und sogar Objekte anderer Scripttreiber um eigenen Funktionalitäten ergänzen. Diese modulare Architektur stellt sicher, dass wir für unsere ScriptTreiber keine internen Sonderwege beschreiten, somit können auch OEMs ihre Plugins nahtlos in die SkriptEngine integrieren.
[2] Bei dieser Funktionalität von "Kommandos" zu sprechen ist etwas vereinfacht, die Schnittstelle für die Skripte ist objektorientiert, da ja auch Python eine objektorientierte Sprache ist. Das mag im Vergleich zur alten Batch-Sprache der V2 etwas komplexer wirken, ist aber deutlich mächtiger und flexibler.