Modular PLC Programming
By Imran Bashir
Modular programming is a technique that involves dividing a complex system into smaller, more manageable components known as modules. These modules can then be connected to form a complete and cohesive final product.
Think of building a wall using bricks. If each brick is made on the spot as the wall is being built, the final product will likely be unstable and not visually appealing. However, if standardized bricks are used, the wall will not only be sturdy but also have a neat and organized appearance.
Similarly, in programming, using standardized modules helps to create well-structured and organized code that is easy to maintain and improve upon.
Consider a motor that has a start/stop button and a discharge valve that must be open before the motor can be turned on. In this scenario, there is also a ZSO limit switch that indicates whether the valve is fully open. If the valve is fully open, the motor can be started and will stop if the switch shows that the valve is not fully open.
These inputs are connected to a Programmable Logic Controller (PLC), which then sends start and stop commands to the Motor Control Circuit. This example illustrates the difference between modular and non-modular programming by keeping the inputs and program logic simple.
Before we dive into the benefits of modular programming, let's first explore how we would create the logic in a non-modular way. We will create logic for a single motor tagged M1. To control the motor, we need to create tags for the inputs and outputs. The following is a list of tags required to control motor M1 and their descriptions:
The tags can be used in ladder logic programming as shown below. This simple ladder logic program shows that when the start button is pressed, the motor will start, and when the stop button is pressed, the motor will stop. However, for the motor to start, the ZSO limit switch must indicate that the valve is open. If not, the motor will fail to start.
While this is a simple program and non-modular programming doesn’t look like an issue for this example but imagine that we have many more motors with the same logic as motor M1. In a non-modular approach, we would have to create separate tags and ladder logic for each motor. This can quickly become unwieldy and difficult to manage as the number of motors grows.
To scale the system for multiple motors, we would have to duplicate the same code for each motor and make small changes to the tags to accommodate for the different motors. This leads to code duplication and increased maintenance overhead, as any changes to the logic would have to be made in multiple places.
Logic will have to be copied and tags modified multiple times with a possibility of mistakes in tags allocation.
Non-modular programming may be suitable for small systems, but as the system grows, it becomes increasingly difficult to manage, maintain, and modify the code. Modular programming offers a more scalable and flexible approach to coding complex systems.
Add-On Instruction (AOI) Usage for Modular Programming
One way to simplify PLC programming is to use Add On Instructions (AOIs). AOIs, also known as function blocks, are pre-built, reusable programming modules that can be added to a PLC program. They are designed to perform specific functions and can be easily integrated into a program to perform a specific task, such as controlling a motor or monitoring a sensor. AOIs can significantly reduce programming time and simplify program maintenance by minimizing the amount of code required.
Using AOIs also promotes modular programming, which is the practice of dividing a program into smaller, more manageable components or modules. This approach makes it easier to develop, test, and maintain the program, as changes to one module do not affect the entire program. AOIs can also improve program readability by organizing the code into logical, reusable components.
Creating AOIs requires some upfront effort, just like designing a cookie cutter. However, the time and effort spent in designing AOIs pays off in the long run as they can be used multiple times, providing consistency in programming and reducing the likelihood of errors. Several PLC vendors offer AOIs, which they may call function blocks or other names. These pre-built modules can be customized to meet specific requirements, and some vendors also offer libraries of pre-designed AOIs that can be easily integrated into a program.
For PLC programming, our cookie cutter will be a self-contained block that will have all the motor logic and internal tags. AOI for motor control will be developed once and will be used multiple times.
Here is an example of motor control AOI template that is based on a simplified motor control logic.
Only thing required is to declare an instance of this AOI template for a particular motor and connect that motor tags with that instance. This is AOI instance created for M1 motor. We named this as M1_CONTROL and will connect with the M1 tags as follows.
Good thing about using the AOI is that we could create another instance of same AOI and will name M2_CONTROL and will connect this instance with tags for M2 controls.
We have taken care of problem of repeatedly creating the same code by using AOI, but we still have to create tags for each motor and number of tags will increase considerably high as number of motors will increase. As an example, if there are five tags for a motor, for three motors we will have to create fifteen tags.
When working with multiple motors or other equipment in a PLC program, the number of tags required can quickly become unmanageable. To address this issue, programmers can use User-defined Data Types (UDT).
User Defined Data Type (UDT)
UDT, also known as structured data types, is a concept in PLC programming that allows tags related to a particular piece of equipment to be grouped together into a custom data type. This custom data type can then be used to define a template that contains all the necessary tags for a specific equipment type.
For example, let's consider a system with multiple motors that require the same set of tags, such as motor speed, current, and status. Instead of creating individual tags for each motor, we can create a UDT template called "UDT_MOTOR" that contains all the necessary tags for a single motor.
Once the UDT template is created, we can easily create instances of it for each motor. This approach significantly reduces the number of tags required, simplifies program development, and makes the program easier to maintain.
UDT templates can be customized to meet specific requirements, and instances of the UDT can be easily modified to reflect changes in the equipment configuration. This approach also promotes modular programming, as UDT templates can be reused across different programs and equipment types.
In summary, User-defined Data Types (UDT) is a powerful concept in PLC programming that allows tags related to a specific piece of equipment to be grouped together into a custom data type. This approach significantly reduces the number of tags required, simplifies program development, and makes the program easier to maintain. PLC programmers should consider incorporating UDT templates into their programming toolbox to streamline their work and improve program efficiency.
How to use UDTs and AOI together for modular programming?
After creating User-defined Data Types (UDT) for each equipment type, we can easily use them to connect with Add On Instructions (AOIs) in the program. Instead of creating individual tags for each component of the equipment, we can use the UDT tags to connect with the appropriate AOI input or output. For example, if we have created a UDT template called "UDT_MOTOR" for a motor and an AOI called "AOI_MOTR_CTRL" to control the motor, we can use the UDT tags to connect with the AOI inputs and outputs.
As shown in the diagram, we can use the naming convention "M1.component" to connect the UDT tags with the AOI inputs and outputs. For example, "M1.START_PB" is connected with the "START_PB" input of the AOI, and "START_CMD" is connected with "M1.START_CMD" in the UDT template.
By using consistent naming schemes for UDT tags and AOI inputs and outputs, we can easily organize the program logic and simplify the connection process. This approach significantly reduces the amount of code required, making the program more efficient and easier to maintain.
UDT inside AOI
If your Programmable Logic Controller (PLC) allows you to create User-defined Data Types (UDT) inside an Add On Instruction (AOI), it can further simplify the program logic and make it more efficient. In this approach, we can create a UDT inside the AOI and name it "MOTOR", which is based on the previously developed UDT template "UDT_MOTOR". We can use the "MOTOR" UDT tag in the program logic, and all the individual tags related to the motor are grouped together inside the "MOTOR" UDT.
For example, the previously used "START_PB" tag becomes "MOTOR.START_PB" and "START_CMD" tag becomes "MOTOR.START_CMD". This significantly reduces the number of connections required to the AOI, as we only need to make one connection to the "MOTOR" UDT.
As shown in the diagram below, when we connect the "MOTOR" UDT to the equipment, individual connections to individual components like START and STOP pushbuttons are made automatically. As long as the "MOTOR" UDT connection is correct, we don't have to worry about the individual connections, as the system takes care of them automatically.
In summary, creating a UDT inside an AOI can further simplify the program logic and make it more efficient. By using the "MOTOR" UDT tag in the program logic, all the individual tags related to the motor are grouped together, significantly reducing the number of connections required to the AOI. As a result, the program becomes more organized, efficient, and easier to maintain.
This article on LinkedIn:
Benefits of Modular PLC Programming
Similar articles on LinkedIn:
Follow me on LinkedIn:
Disclaimer: This article is intended for educational purposes only and is not a comprehensive guide. The information presented here is based on current industry standards and best practices, but it is not a step-by-step guide and shall not be used for real-world programming and implementation without seeking advice from a qualified professional. The author and publisher assume no responsibility or liability for any errors or omissions in the content of this article. The information contained herein is provided on an "as is" basis and makes no guarantees of completeness, accuracy, usefulness or timeliness. Any implementation or use of the information presented in this article is at the reader's own risk.
