Object Oriented Programming in Siemens and Allen Bradley PLCs

Object Oriented Programming in Siemens and Allen Bradley PLCs

Since their conception PLC programs have been founded on simple programs. RLL (Relay Ladder Logic) and IL (Instruction List) commands have dominated PLC programs since PLCs first came to market in the 1970s. However in the past few years automation requirements have grown more complex and demanding. This has in turn led to PLC manufacturers beginning to include some higher level programming concepts in their software packages. What exactly have they added? And what does it mean for your manufacturing processes? Answers to all of these questions will be answered…right now.

Object-oriented programming (OOP) is a complicated beast, but in essence it is based on a few simple concepts:

  1. Classes. The big one. A class is a definition of a group functions and attributes that are all related in some way.
  2. Encapsulation. OOP pushes forward the practice of hiding data and class definitions except where it is needed.
  3. Inheritance. Building classes based on other classes is one of the foundations of most modern OOP languages.

These concepts have helped speed up software development and testing time by several orders of magnitude compared to programming 30 years ago. Why then, up until a few years ago, were none of these concepts available in PLCs? The answer is simply that most PLC programmers were not software engineers or computer scientists. Luckily that has started to change. Let’s talk about each one of the OOP concepts above, how it has been added to the PLC repertoire, and how it can help YOU make gains on software development time, machine commissioning, and safety standards.

  1. Classes. The direct correlation to classes in the PLC world is the function block. A function block, like a class, is a definition of actions and attributes. For instance, a valve function block has actions, such as opening, closing, or throwing an alarm, and attributes, such as a timeout length or open/closed status. By creating a single valve function block, you have created the correct actions and attributes for every single similar valve in your system. See Tim’s article about IEC 61131-3 Function Blocks for more information about the vast power of this concept.
  2. Encapsulation. This is a little trickier to establish in PLCs, however, you can make it work. The easiest way to establish encapsulation is to use a combination of user-defined types (UDTs) and function blocks. UDTs group like-minded data together in a hierarchy. In our valve example, we might have a UDT for all valve data and inside it a UDT for all valve errors. We can then declare one of these for each of our valves, and then our function block will know to access all data from within the UDT. A timeout error in a water valve, for example, would be something extraordinarily clear and readable—something like “HotWaterValve.Errors.TimeoutFault”. Once again my coworker Tim Jager has written a great article about this topic. See IEC 61131-3 Data Structures for more information.
  3. Inheritance. Here is the one area central to OOP that simply hasn’t made it to PLCs yet. Inheritance means that you can define classes starting from a baseline (i.e. starting from other classes). You could have a Bar Chart class, for instance, that hardly requires any code whatsoever, because it inherits from a Chart class where most of the work is performed. Unfortunately if you want this kind of capability in PLCs you will probably have to wait a few years. Inheritance could mean some pretty cool stuff in the industrial controls field. For instance, we could define a base motor class with all common motor functionality, then create custom inherited classes, like a Profibus motor versus a Modbus motor, with minimal code effort.

Well, there you have it. OOP, the most widely adopted programming structure in the world, is slowly but surely making its way into the industrial controls space. As controls demands become more and more demanding, leveraging these new techniques becomes vital in order to decrease development costs and test time, while increasing program robustness.

Learn more aboout DMC's Siemens PLC and Allen-Bradley PLC programming expertise.


What about

They have OOP!

In my opinion the examples given above are not OOP at all.
In my opinion OOP is matter of having all of it or nothing... you cant do it half in my opinion.
This is because the design changes as soon as Inheritance,for example, becomes available.
Jay Mackey
# Jay Mackey
Less than four years after this article was written, we now have an implementation of IEC 61131 by CoDeSys which incorporates Inheritance, Interfaces, and Function Blocks that match the traditional class definition more completely with Actions, i.e. 'methods' that have their own private data. The 'Implements' and 'Extends' keywords have been added for use with Function Blocks, which enable inheritance and the use of interfaces. For PLC hardware, Beckhoff TwinCAT 3, which utilizes CoDeSys, has been released to run on Beckhoff PLCs. Other hardware manufacturers also license CoDeSys, and CoDeSys offers a free time-limited version that runs on Raspberry Pi hardware, as well as a full license for Raspberry Pi for 35 euros.

Post a comment

Name (required)

Email (required)

Enter the code shown above: