CoDeSys Version 3.4 SP3 offers an integrated script language for the first time.
Instead of developing a proprietary language as in the BatchMode in CoDeSys V2, CoDeSys V3 uses the wide-spread Script Language Python by imbedding the .NET based implementation IronPython into CoDeSys. You can benefit from the following benefits:
• Python is rather easy to use and to learn, simple scripts can be written linearly.
• For advanced users, Python offers the possibilities of modern high-level languages such as loops, functions, modules, objects, classes or functional elements.
• It is very difficult to design a high-quality programming language. Python is evolving since 20 years now which guarantees a certain maturity of the language. Python Standard Library
• Due to the widespread use of Python, you can profit from a number of ready-designed modules for different purposes on the Internet. The internet also provides many forums and code samples.
As easy as the Python principle may be, beginning to learn a new language always means some additional effort. To make your first steps a bit easier, we have listed a few links and commented code samples below. You will be able to solve many of your tasks by using code snippets from our samples. Of course you may also ask for help in this forum.
As the average CoDeSys user has already gained experience in the IEC languages, he/she probably knows how to work with variables, loops and functions and how to transfer this knowledge to Python.
Those who intend to deepen their Python knowledge and to carry out their own experiments should download the Python Standard Package which provides all necessary elements for starting with Python along with a simple development environment called IDLE.
Here some links for starting with Python:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-05-05
Originally created by: M.Schaber
The language Python currently is in a phase of transition. For the first time in the 20 years of history, the developers did decide to get rid of some legacy features. Thus, this is the first (and in the forseeable future the only) language update which is not completely backwards compatible.
As version 3 of the .NET variant IronPython can be expected around the end of the year, we embedded the current version 2.6.2. But we plan to migrate to the new version as soon as it is available, if possible. This then raises the problem that some scripts are possibly incompatible.
We do not yet have an exact migration strategy, but we will try to provide a smooth transition. One helpful fact is that there exists a converter which converts python scripts to the new syntax automatically, and it is expected that we can embedd both language versions in parallel into CoDeSys - at least for some transitional period.
But it should be possible to author CoDeSys scripts in a way so they are compatible with both language versions, just by obeying a few rules.
The most changes are related to the removal of obsolete language features (e. G. the so-called 'old style classes') and obsolete modules in the standard library. Newly written code should not use them anyway, and thus there should be no migration problems in this regard. Some other points like the transition of string types are not affecting the IronPython implementation we use, but only other implementations of the language.
But there exist some changes which will affect freshly written scripts. The most serious ones are:
Print used do be a statement and will be a function.
Code like ```
print 'hallo'
has to be converted to
print('hallo')
. The new syntax provides some advantages compared to the old one, and can be activated in the current Python 2.6 via the statement
from future import print_function
``` - then the new syntax (and only the new one) is accepted. Thus, it is advisable to activate this by default in all new scripts.
The default division operator will return floating point values.
The division of two integral values via the "/" operator returns a downwards rounded integer, '1/2' thus returns '0'. In Python 3, a floating point number will be returned, thus '1/2' will return '0.5'. In both python versions, the operator '//' is available and behaves like the old '/' operator, returning '0'. Using the statement ```
from future import division
```, the new behaviour for the '/'-Operator can be activated.
Some functions in the standard library now return views or iterators instead of lists.
If one just iterates over the result of those functions using a loop, no change is necessary. But if one needs the list functionality (e. G. because one wants to access members via index), one has to pack the result into a list. This can be accomplished via the list constructor, instead of ```
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-05-05
Originally created by: M.Schaber
Due to time constraints, the documentation for the script commands was currently delivered in a somewhat temporary form. In the CoDeSys installation directory, in the subdirectory is a file called . In this file, all CoDeSys-specific python interfaces for the script engine are documented. This file is generated directly from the C# source, and thus its content is complete, but its form is not integrated into the online help, and
The namespace _3S.CoDeSys.ScriptEngine.BasicFunctionality contains the objects we provide for the scripts (unfold the lowest entry in the content tree). The other namespaces only contain some enum values which are imported from other areas of CoDeSys.
The following entry points are provided for the scripts:
Projekts:
The Functions of projects are documented at "IScriptProject Interface" and "IScriptProjectDeviceExtension Interface". Projects are the root of the project trees which contains the devices and POUs.
Objekts:
The objects are documented at "IScriptObject Interface". Additionally, all projects provide two marker properties: "is_libman" and "is_device". For library managers, the first one returns "True", a sign that the objects provide all the "IScriptLibManObject" commands, too. In analogy to that, device objects return True from is_device, to show that they support the methods of "IScriptDeviceObject".
I hope this faciliates your entry into the world of scripting.
I think, the best strategy is to read the examples here in the forum, cross-compare them with the documentation, and in case of any doubts, ask here in the forum.
[1] If you're interested in the details: CoDeSys is a modular product built from about 200 plugins, which can be extended and exchanged by our OEM customers in line with our "Automation Platform". For this reason, our scripting implementation is also modularized internally. A main plugin called "ScriptEngine" provides the infrastructure (Scripting interpreter, commands, command line options). Five more plugins, so-called ScriptDrivers, provide the actual commands[2] for the scripts, separated into the areas "System", "Project", "Online", "LibraryManager" and "Device". Such script drivers can provide objects and types (classes, interfaces, enums), and even extend objects of other script drivers with their own functionality. This modular architecture ensures that our ScriptDriver does not exploit any internal shortcuts, thus our OEMs can integrate their plugins into the ScriptEngine seamlessly.
[2] Calling this functionality "commands" is a little bit simplified, the interface for the scripts is object oriented (as python is an object oriented language). This might seem a little bit komplex compared to the old V2 Batch Mode, but is considerably more powerful and flexible.
Is it possible to get an updated list of entry points?
I can see that at least "librarymanager" has been added.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-08-24
Originally created by: M.Schaber
Hi, Frank,
Frank Jepsen hat geschrieben:
Is it possible to get an updated list of entry points?
I can see that at least "librarymanager" has been added.
Our Documentation department is sometimes lagging a little bit behind.
You can generate such a list yourself using the following script:
importscriptengineformemberindir(scriptengine):Â Â print(member)
The dir() function works with all python objects and lists all members.
The listing for V3.5.1.20 is as follows:
        ApplicationState        ConflictResolve        DeviceID        ExportReporter        Guid        ImportReporter        MultipleChoiceSelector        NativeExportReporter        NativeImportFilter        NativeImportHandler        NativeImportResolve        NativeImportResult        ObjectPermissionKind        OnlineChangeOption        OperatingState        PermissionState        PromptChoice        PromptChoiceFilter        PromptHandling        PromptResult        ResetOption        Severity        TimeoutException        ValuesFailedException        __doc__        __file__        __name__        librarymanager        online        projects        system
Names beginning with two underscores are reserved for implementation defined behaviour, and (Iron)python Modules contain the members doc, file and name as their docstrings.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-08-24
Originally created by: M.Schaber
M.Schaber hat geschrieben:
Hi, Frank,
Our Documentation department is sometimes lagging a little bit behind.
You can generate such a list yourself using the following script:
importscriptengineformemberindir(scriptengine):Â Â print(member)
The dir() function works with all python objects and lists all members.
The listing for V3.5.1.20 is as follows:
        ApplicationState        ConflictResolve        DeviceID        ExportReporter        Guid        ImportReporter        MultipleChoiceSelector        NativeExportReporter        NativeImportFilter        NativeImportHandler        NativeImportResolve        NativeImportResult        ObjectPermissionKind        OnlineChangeOption        OperatingState        PermissionState        PromptChoice        PromptChoiceFilter        PromptHandling        PromptResult        ResetOption        Severity        TimeoutException        ValuesFailedException        __doc__        __file__        __name__        librarymanager        online        projects        system
Names beginning with two underscores are reserved for implementation defined behaviour, and (Iron)python Modules come with the members doc, file and name carrying some meta information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally created by: M.Schaber
CoDeSys Version 3.4 SP3 offers an integrated script language for the first time.
Instead of developing a proprietary language as in the BatchMode in CoDeSys V2, CoDeSys V3 uses the wide-spread Script Language Python by imbedding the .NET based implementation IronPython into CoDeSys. You can benefit from the following benefits:
• Python is rather easy to use and to learn, simple scripts can be written linearly.
• For advanced users, Python offers the possibilities of modern high-level languages such as loops, functions, modules, objects, classes or functional elements.
• It is very difficult to design a high-quality programming language. Python is evolving since 20 years now which guarantees a certain maturity of the language.
Python Standard Library
• Due to the widespread use of Python, you can profit from a number of ready-designed modules for different purposes on the Internet. The internet also provides many forums and code samples.
As easy as the Python principle may be, beginning to learn a new language always means some additional effort. To make your first steps a bit easier, we have listed a few links and commented code samples below. You will be able to solve many of your tasks by using code snippets from our samples. Of course you may also ask for help in this forum.
As the average CoDeSys user has already gained experience in the IEC languages, he/she probably knows how to work with variables, loops and functions and how to transfer this knowledge to Python.
Those who intend to deepen their Python knowledge and to carry out their own experiments should download the Python Standard Package which provides all necessary elements for starting with Python along with a simple development environment called IDLE.
Here some links for starting with Python:
Originally created by: M.Schaber
The language Python currently is in a phase of transition. For the first time in the 20 years of history, the developers did decide to get rid of some legacy features. Thus, this is the first (and in the forseeable future the only) language update which is not completely backwards compatible.
As version 3 of the .NET variant IronPython can be expected around the end of the year, we embedded the current version 2.6.2. But we plan to migrate to the new version as soon as it is available, if possible. This then raises the problem that some scripts are possibly incompatible.
We do not yet have an exact migration strategy, but we will try to provide a smooth transition. One helpful fact is that there exists a converter which converts python scripts to the new syntax automatically, and it is expected that we can embedd both language versions in parallel into CoDeSys - at least for some transitional period.
But it should be possible to author CoDeSys scripts in a way so they are compatible with both language versions, just by obeying a few rules.
The most changes are related to the removal of obsolete language features (e. G. the so-called 'old style classes') and obsolete modules in the standard library. Newly written code should not use them anyway, and thus there should be no migration problems in this regard. Some other points like the transition of string types are not affecting the IronPython implementation we use, but only other implementations of the language.
But there exist some changes which will affect freshly written scripts. The most serious ones are:
Print used do be a statement and will be a function.
Code like ```
print 'hallo'
has to be converted toprint('hallo')
. The new syntax provides some advantages compared to the old one, and can be activated in the current Python 2.6 via the statementfrom future import print_function
``` - then the new syntax (and only the new one) is accepted. Thus, it is advisable to activate this by default in all new scripts.
The default division operator will return floating point values.
The division of two integral values via the "/" operator returns a downwards rounded integer, '1/2' thus returns '0'. In Python 3, a floating point number will be returned, thus '1/2' will return '0.5'. In both python versions, the operator '//' is available and behaves like the old '/' operator, returning '0'. Using the statement ```
from future import division
```, the new behaviour for the '/'-Operator can be activated.
Some functions in the standard library now return views or iterators instead of lists.
If one just iterates over the result of those functions using a loop, no change is necessary. But if one needs the list functionality (e. G. because one wants to access members via index), one has to pack the result into a list. This can be accomplished via the list constructor, instead of ```
foo = map(...)
one writesfoo = list(map(...))
``` and it will work with both python versions.
A more detailed outline is provided by the web sites http://wiki.python.org/moin/Python2orPython3 and http://docs.python.org/release/3.1.2/whatsnew/3.0.html.
Originally created by: M.Schaber
Due to time constraints, the documentation for the script commands was currently delivered in a somewhat temporary form. In the CoDeSys installation directory, in the subdirectory is a file called . In this file, all CoDeSys-specific python interfaces for the script engine are documented. This file is generated directly from the C# source, and thus its content is complete, but its form is not integrated into the online help, and
The namespace _3S.CoDeSys.ScriptEngine.BasicFunctionality contains the objects we provide for the scripts (unfold the lowest entry in the content tree). The other namespaces only contain some enum values which are imported from other areas of CoDeSys.
The following entry points are provided for the scripts:
Projekts:
The Functions of projects are documented at "IScriptProject Interface" and "IScriptProjectDeviceExtension Interface". Projects are the root of the project trees which contains the devices and POUs.
Objekts:
The objects are documented at "IScriptObject Interface". Additionally, all projects provide two marker properties: "is_libman" and "is_device". For library managers, the first one returns "True", a sign that the objects provide all the "IScriptLibManObject" commands, too. In analogy to that, device objects return True from is_device, to show that they support the methods of "IScriptDeviceObject".
Examples and Receipes
I hope this faciliates your entry into the world of scripting.
I think, the best strategy is to read the examples here in the forum, cross-compare them with the documentation, and in case of any doubts, ask here in the forum.
[1] If you're interested in the details: CoDeSys is a modular product built from about 200 plugins, which can be extended and exchanged by our OEM customers in line with our "Automation Platform". For this reason, our scripting implementation is also modularized internally. A main plugin called "ScriptEngine" provides the infrastructure (Scripting interpreter, commands, command line options). Five more plugins, so-called ScriptDrivers, provide the actual commands[2] for the scripts, separated into the areas "System", "Project", "Online", "LibraryManager" and "Device". Such script drivers can provide objects and types (classes, interfaces, enums), and even extend objects of other script drivers with their own functionality. This modular architecture ensures that our ScriptDriver does not exploit any internal shortcuts, thus our OEMs can integrate their plugins into the ScriptEngine seamlessly.
[2] Calling this functionality "commands" is a little bit simplified, the interface for the scripts is object oriented (as python is an object oriented language). This might seem a little bit komplex compared to the old V2 Batch Mode, but is considerably more powerful and flexible.
Related
Talk.ru: 1
Talk.ru: 2
Is it possible to get an updated list of entry points?
I can see that at least "librarymanager" has been added.
Originally created by: M.Schaber
Hi, Frank,
Our Documentation department is sometimes lagging a little bit behind.
You can generate such a list yourself using the following script:
The dir() function works with all python objects and lists all members.
The listing for V3.5.1.20 is as follows:
Names beginning with two underscores are reserved for implementation defined behaviour, and (Iron)python Modules contain the members doc, file and name as their docstrings.
Originally created by: M.Schaber
The dir() function works with all python objects and lists all members.
The listing for V3.5.1.20 is as follows:
Names beginning with two underscores are reserved for implementation defined behaviour, and (Iron)python Modules come with the members doc, file and name carrying some meta information.
Hi Markus,
Thanks for your answer. Nice to have the small script, so I can check for myself at a later time.
Best regards,
Frank