Whether you’re new to OOP or an experienced PLC programmer, you’ll gain useful insights into OOP and learn helpful techniques for building more efficient, effective programs.

Why OOP?

Before we use a concrete example, there’s one question we need to think over: why OOP? If I’m doing fine with my procedure programming for years, why use it? The reason is that PLC programs are becoming increasingly complex, and application requirements are changing more frequently than ever before, making it a challenge to create and maintain efficient programs.

Therefore, OOP could provide the following:

  • Increased modularity. Breaking down programs into smaller, reusable modules makes the program more adaptable and scalable.
  • Flexibility. The program can be easily modified or extended as requirements change.
  • Ease of maintenance. The program is easier to understand, test and maintain over time.

Example: A Conveyor System

The key principles of OOP are encapsulation, inheritance and polymorphism. While you can find thousands of articles to explain these principles, the following example offers a deeper understanding.

The example is a simplified scenario of a conveyor system that consists of a conveyor belt and a motor. The goal of this conveyor is to transport boxes from one end to the other. On both sides, there are two light barrier trigger sensors connected to two inputs of a PLC, indicating if there is a box present. The motor of the conveyor needs two digital signals — start and stop — and an analog output for controlling the speed.

While the conventional approach may seem sufficient, what if the customer’s requirements change or the machine needs to be updated?

Changing the light barriers to a camera. Let’s say we want to replace the light barriers with a camera that can scan barcodes. The barcode scanning may not be necessary for the conveyor system, but it will be used in other parts of the machine. Furthermore, the camera can also be used to detect whether there is a box on the conveyor or not. As a result, we can remove the light barriers, and we will have two extra inputs that we can use for other purposes.

Upgrading to servo motors with EtherCAT connectivity. As technology advances, servo motors have become more affordable and efficient, prompting our customer or project manager to suggest upgrading the current motor to a servo motor. The new servo motor will be connected to EtherCAT, a high-performance industrial communication protocol that allows for real-time data exchange between the motor and the PLC.

While these changes may appear to be simple modifications to the current program to meet the new requirements, it’s essential to step back and restructure our program using OOP before making any changes. Although this course may require more effort initially, it pays off significantly in the long run.

The Class Diagram

When it comes to OOP, the class diagram is an essential aspect that we can’t overlook. It serves as a useful tool for illustrating the software architecture and can be utilized in planning, development and system documentation. The class diagram represents the basic classes used in our software architecture. There are three classes — Conveyor, Sensor and Motor.

The Conveyor class is a high-level class and includes three methods:

  • Enable
  • Disable
  • Run

The Sensor class includes only one method — isBoxDetected — while the Motor class includes three methods:

  • Start
  • Stop
  • SetSpeed

What We Have Achieved

In short, we’ve used encapsulation to simplify the usage of objects — as we saw with the “start” and “stop” methods of Motor. Through inheritance, we replaced Motor with ServoMotor without modifying other parts of our software.

This approach made our software modular and easier to comprehend and maintain. Please note that the programming approach in this example for OOP is only for demonstration purposes and may not be the best practice. However, if it has helped you understand OOP in PLC programming, it has achieved its purpose.

Disclaimer

This post is provided solely for the purpose of offering setup assistance and general guidance. It is important to note that the ultimate responsibility for ensuring the overall safety and proper functionality of the machine lies with the System Integrator / End User. It is crucial to exercise caution, adhere to proper safety protocols, and consult relevant experts or professionals when necessary.

Although Festo employees will be contributing to this blog, please note this is not the official Festo support channel. For more timely technical support please reach out to your regional Festo support channel and/or consult user manuals and relevant documentation.