Object-oriented techniques are also suitable for PLCs

Onno van Roosmalen and Tim van Heijst have set up a five-day course in which PLC experts and OO specialists learn how to develop a PLC application through object-oriented programming. High Tech Institute will be rolling out this course for the first time in early 2020.

More and more, PLC programmers are facing the same challenges that were previously reserved for large, complex software projects. Object-oriented techniques offer a solution, but in the past, they could not be applied one-on-one due to the traditional limitations of PLCs. With the new release of the IEC 61131-3 standard for PLCs, object-oriented functions are now available and the possibilities have grown enormously.

Universities of Applied Sciences and academics regularly dismiss PLCs as an inferior technology. Nice for simple machines, but totally inadequate for the complex systems they work on. In the past, they may have had a point. Basically, PLCs are always cyclical, but the cycle time can often throw a wrench in the works. However, for modern PLCs, a cycle of less than ten milliseconds is quite normal. For time-critical applications, there are even PLCs available with a cycle time of less than a millisecond.

Onno van Roosmalen (left) and Tim van Heijst (right) have set up a five-day course in which PLC experts and OO specialists learn how to develop a PLC application through object-oriented programming.

“Packaging machines – even if they have to reach a very high speed – can easily be controlled with a PLC,” says Tim van Heijst, owner of the Codesys specialist, Extend Smart Coding, and lecturer at High Tech Institute. “PLCs are also an excellent platform for robot applications. With the current power of PLCs, there are hardly any applications where they fail.”

This does not mean that suppliers such as B&R, Beckhoff, Rockwell and Siemens will also sell their PLCs in the higher segment without a hitch. In the case of larger machine builders, it is sometimes still an internal struggle: ‘do we design everything ourselves or do we choose a PLC?’, Van Heijst has experience. However, the definition of the problem is almost always the same. They want to develop an application as quickly and as well as possible and, if feasible, reuse existing code. “A PLC meets all these requirements. It is a standard product that is well supported by the supplier. If you have a bug in the firmware, it will fix it for you. You can easily connect to your actuators and sensors, because there are all kinds of standardized communication protocols available. That’s why you can get your system up and running very quickly,” says Van Heijst. An additional advantage is that almost all PLC manufacturers follow the IEC 61131-3 standard. This means that the application software you build is hardware-independent and switching to a faster PLC – or even an industrial PC – is a breeze.

Uncoupling

Whereas PLCs have traditionally been used in applications with limited functionality, the possibilities are now so extensive that modern programming techniques are needed to regulate everything in a good way. With version 3 of the IEC 61131 standard, developers can also opt for an object-oriented approach.

Van Heijst: ‘With the current power of plc’s, there are virtually no applications where they fail’.

“You will then have to deal with important software features such as information hiding and encapsulation, i.e. the idea that you locate information and do not throw it through the entire system,” says Onno van Roosmalen, independent software engineering consultant and lecturer at High Tech Institute. “In practice, you regularly see that a team provides a component with extra functionality, causing a cascade of events throughout the entire system. That makes it difficult to add anything. In many web applications you see that encapsulation is broken, but that depends on their nature: making information available. With machine control, that’s a different matter.”

“The thought of hiding information goes hand in hand with the way in which components address each other: the interface. This allows you to hide the detailed shape of your objects and ensure that no implementation details leak out. You then make sure that the user can only do what is currently required, no more and no less,” explains Van Roosmalen. The idea behind this is that the evolution of components can be disconnected. If a new version of a component continues to do what it used to do via an interface, the software built on it does not need to be modified immediately. A development team that programs against the component can use the new version without fear of something falling over in the meantime. When encapsulation and interfaces are in order, a maintainable, scalable architecture that can grow with the application almost automatically emerges.

“The condition, however, is that teams take a defensive stance when designing their interface. You shouldn’t just offer everything that other teams ask,” says Van Roosmalen. “The more you offer, the more unintended uses there are and the more likely it is that things will break in a new version. You can always expand an interface later, but downsizing is a lot more difficult.

How does that work in practice? Van Heijst gives an example: “I recently visited a manufacturer of charging stations. They make a lot of variants and work with a wide range of plugs. The company wanted to develop an energy management system that could cope with all these differences. We solved that with PLCs and an object-oriented approach. Now the management system communicates with all charging station versions via defined, generic interfaces and the company can manage the development of all blocks separately. This reduces the risk of errors, makes re-use easier and makes an application much faster in the air.”

Building knowledge

“For PLC programmers ‘from the old pedigree’, the object-oriented approach means a new way of thinking. Software engineers for whom OOP is a piece of cake, find that PLCs work just that little bit differently from their familiar PC environment. PLC vendors offer courses, but these are about how to connect to your i/o, for example. Real programming courses are not,” says Van Heijst, “because you don’t learn how to build your own application.”

‘Object-oriented thinking for the PC is almost identical to object-oriented thinking for the PLC,’ says Van Roosmalen.

That is why Van Heijst and Van Roosmalen have set up the training “Object-oriented system control automation.” A five-day course in which PLC experts and OO specialists learn how to develop a PLC application via object-oriented programming. In this way, companies can build up knowledge and do not have to fall back on system integrators who prefer to take care of everything.

“Object-oriented programming is essentially different from procedural programming,” says Van Roosmalen. “But object-oriented thinking for the PC is almost identical to object-oriented thinking for the PLC. You can use the same software design. Well, with some minor adjustments because the programming concepts for a PLC are a bit more limited.”

“We explain the technique and tell you how to apply it,” adds Van Heijst. “A large part of the training is about how to get a good software design. It still happens very often that a programmer just goes to work and delivers a working piece of software a few weeks or months later. Then, suddenly, there is a change and they have to make all sorts of turns to get it done. If you apply the object-oriented methodology properly, you will be free of that problem. Another advantage of OOP.”

This article is written by Alexander Pil, tech editor of High-Tech Systems.