OOP: Understand the software, code efficiently

Many programmers of programmable logic controllers (PLCs) may think they can skip object-oriented-programming (OOP) concepts, but it’s not advisable. Some of them don’t even realize they’re using OOP already, as I discussed previously.

Modern automation products are all about OOP. Some software-engineering skills will make ladder logic better or encourage learning scripting. Instead of arguing over whether structured text is better than ladder, let’s just talk OOP because both ladder and text use OOP.

Get your subscription to Control Design’s daily newsletter.

OOP basics include inheritance, encapsulation, abstracting and polymorphism.

Inheritance is the idea that a parent class can be created, and a child class may be defined from that parent class. In doing so, the child class has the parent-class characteristics or, in programming speak, properties. If the parent changes properties, so does the child, but also, the child can add properties and modify (Figure 1).

Encapsulation groups all the logic properties associated with an object and makes it easier to understand the object without searching through a project for various pieces. Variables used to control the type’s properties can be referenced relative to an alias on the parent.

If a user-defined tag is created and called “valve,” then the valve properties of open, closed, position feedback, analog and discrete, could be used anywhere a valve type is defined. The same is true with motor. A function block called “motor” could use start, stop, fault and idle (Figure 2).

Add a sensor, and define the sensor. If a sensor, valve and motor are added together in a function, then a system function, like wash conveyor, might be created, where a conveyor motor is started when the part is put on the conveyor and is washed when the sensor detects the part. Picture whatever interface is needed and put it in the object to use (Figure 3).

Abstraction is when an object is used at a higher level, and the code under the hood does not need to be understood or broken up. Abstraction is done in the automation software development environment (SDE) all the time. These are the premade functions that are in the SDE. But, regardless, PLC programmers can make their own that are not readily needed at higher-level troubleshooting layers, if done correctly. For instance, add-on instructions should be building blocks and never have to change, if tested out before implementation.

Polymorphism is when the interfaces of a parent class may be accessed by the child class of said parent without disruption. This allows enhancement of code without major architecture changes. In this example, a “conveyor” can be added to the system because the conveyor block has all the parts needed and that makes coding quicker. On top of that, sending the data to the human-machine interface (HMI) is easier because user-defined data types (UDTs) may be duplicated there to match the logic.

Of course, all of this depends on the application that you choose to use for programming. It also depends on how you set up your structures.

Why is it important for automation? For integrators and equipment manufacturers, over the long run, it will save time. And time is money. Also, the future is now. The Internet of Things (IoT) and communications protocols that are letting automation be more modular and more compatible means that one day the PLC may go away. If you think currently, the edge computer has an emulated PLC. This means that understanding the software and being able to code it efficiently is a win-win situation, regardless of whether using ladder or structured text.