Object Oriented Programming in Programmable Logic Controllers (PLC). What’s really new?
Object-oriented programming (OOP) is a programming paradigm based on the concept of objects, which can contain data in the form of properties, and code in the form of procedures known as methods. Objects are distinguished by the fact that they can have procedures which we can use to access and modify data fields of an object with which the fields are associated. In OOP, computer programs are made up of objects that interact with one another. OOP languages are diverse. However, the most popular ones are class-based, meaning that objects used in them are instances of classes that determine object types.
This is what Wiki says about OOP in general, and that is what most of us would like to have in PLC system development. When I need to code a program in any high-level language like C++ or C#, it seems to me that I have much more tools and possibilities; consequently the development process advances much easier and faster.
TwinCat3 by Beckhoff introduced OOP to the PLC world. Here is a list of features they brought to the table:
- Methods
- Properties
- Interfaces
From this list we can infer that we can now benefit from most of the OOP advantages applied to Factory Automation. But are they as new as they seem to be, and will they add the C# look and feel to PLC development?
We would like to present to you a series of articles in which we will try to compare the old CoDeSys2 way with the new TwinCat3 through simple examples of how we would do both with and without OOP. I will try to use Beckhoff’s PLC sample project intended to illustrate some of the basic functions of object-oriented programming. At the same time, I’ll code it in non- object-oriented CodeSys2, so we all can see the difference, including bugs and features it might entail with regard to PLC development.
In this first article I would like to shed light on the most recent feature available in TwinCat3: Properties.
They first appear in JavaScript to simply establish the association between a particular name and the value of an object. In TwinCAT, a property has Get and Set accessor methods to retrieve and set its value respectively. TwinCAT automatically calls these methods while reading or writing to the function block that implements the property.
Properties are recognizable by the following characteristics:
Access specifier
- PUBLIC: Corresponds to the specification of no access modifier.
- PRIVATE: Access to the property is limited to the function block only.
- PROTECTED: Access to the property is limited to the program or to the function block and its derivatives.
- INTERNAL: Access to the property is limited to the namespace, that is to the library.
- FINAL: Overwriting the property in a derivative of the function block is not allowed. This means that the property cannot be overwritten or extended in a possibly existing subclass.
Properties can be Abstract, which means the case that a property has no initial implementation and that the actual implementation is provided in the derived function block.
However, we have always had a simple association in PLC: VarIn, VarOut, and all the other kinds of variables with different access types which can be called as easy as properties.
For example: Cylinder.var_in_out_bAtBasePos is the same as Cylinder.State_AtBasePos.
Additionally, we can specify some rules for setting and getting within the function block Cylinder. For public use I can confine myself to conventional internal variables.
PROTECTED, INTERNAL and FINAL is really new stuff making properties more flexible. But these require additional coding and entail one disappointing feature:
As you can see, you cannot monitor them!
But it’s surprising only at first. Adding some more code helps regain proper functionality as follows.
Pragmas come in very handy for monitoring of properties in online mode. For this, write them at the top of properties’ declarations (attribute ‘monitoring’):
{attribute ‘monitoring := ‘variable’}: When accessing a property, TwinCAT stores the actual value in a variable and displays the value of the latter. This value may become obsolete if the code no longer accesses the property.
{attribute ‘monitoring’ := ‘call’}: Each time the value is displayed, TwinCAT calls the code of the Get accessor. Any side effect, caused by that code, can appear in the monitoring.
Thus using properties, we can gain access to benefits for libraries with more complicated code. We don’t use properties often in the projects within our programming team, but they have taken place in libs for external use.
The next article is intended to familiarize you with Methods, among other brand new things in the modern PLC development tools.
