Click the blue text to follow!

Deployment Strategy for Process Control Based on Modular Design in PLCs

Two days ago, Xiao Zhang from the workshop rushed to me: “Old Li, the filling system on production line 3 has problems again. The program is a complete mess; modifying one part requires retuning everything, which not only delays production but also kept me working overtime until 2 AM to fix it.” Hearing this, I knew where the problem lay. “Xiao Zhang, you haven’t used modular design; your PLC program is like a chaotic stew, so of course, every modification is nerve-wracking. Let me share with you the experience I’ve gathered over the past decade…”

Modular design is about breaking down a complex control system into multiple independent functional blocks. This approach is particularly practical; when I first started, I didn’t understand it either, and even a small function change made me nervous. Nowadays, the automation systems in factories are becoming increasingly complex; if the program is written like a long snake, anyone who touches it is in trouble.

I remember the project at the paper mill last year, where the entire production line had hundreds of I/O points, and the client kept changing requirements every few days. If I hadn’t used a modular approach, I would have been overwhelmed. Here’s how I did it:

First, we need to divide the system into independent modules based on functionality. For example, a filling line can be divided into several modules: feeding, filling, capping, labeling, inspection, and packaging. Each module acts like an independent “black box,” only concerned with its inputs and outputs, without worrying about how others are implemented.

Let’s look at a simple module example:

// Main program segment for the filling module

M_FILLING:

IF Bottle_In_Position AND Liquid_Level_OK THEN

Start_Filling_Pump();

Start_Timer(T_Fill);

ENDIF

This has many benefits. First, it makes fault location easier; second, it allows for good functionality expansion; third, multiple people can collaborate without interference. Previously, the old equipment in the workshop had PLC programs written like noodles, making it a headache for anyone to modify. Now, after I redesigned it, it’s clear where any issues arise.

The second step is to define standard interfaces between modules. This interface is like the “rules” we agree upon; it specifies how information is passed between modules, what variables are used, and when updates occur, all of which must be predetermined. I usually use a global DB block to store these shared data:

// Communication data block between modules

DATA_BLOCK "Shared_DB"

Module1_Ready : BOOL;   // Module 1 readiness status

Module2_Start : BOOL;   // Trigger for Module 2 to start

Transfer_Count : INT;   // Count of products transferred

END_DATA_BLOCK

Xiao Wang asked me recently: “Old Li, this modular design looks good, but our factory has so many different brands of PLCs, some of which are old equipment. How do we unify them?” This kid asked a good question!

The key is the third step: create a device-independent function library. Just like when we renovate a house, regardless of whether the materials are domestic or imported, as long as the interfaces are consistent and the dimensions match, they can be used. I usually build a function library containing all the commonly used control functions, which can be used even if the hardware platform changes:

// Universal PID temperature control function block

FUNCTION_BLOCK "Universal_PID"

Input_PV : REAL;        // Process variable input

Setpoint : REAL;        // Setpoint

Output : REAL;          // Control output

// Other parameters and algorithm implementations...

END_FUNCTION_BLOCK

Finally, don’t forget to implement self-diagnosis and exception handling for the modules; this is something I’ve learned from experience. Each module should be able to determine whether it is functioning normally, and if there is a problem, it should be able to alarm and safely shut down. Previously, the labeling machine in the workshop caused the entire line to stop due to inadequate exception handling; now, with modular design, if one part has an issue, it doesn’t affect the production of other parts.

Here’s a little trick for you: after writing a module, create a template and save it. The next time you encounter a similar requirement, you can modify it and use it, saving you from starting from scratch. I have stored over a dozen commonly used function modules on my computer, such as measurement control, temperature control, and material transport, which I can use right away. The clients even think I stayed up late writing them!

After I finished explaining, Xiao Zhang’s eyes lit up: “Old Li, I understand! I’ll reorganize the program for line 3 and modify it according to your modular design approach.”

“That’s right, young man, you have good insight. Remember, automation is not about showing off how high your programming skills are; it’s about making it easier for the maintenance personnel. The program you write today might require you to get up in the middle of the night to maintain it someday. Modular design is about making things easier for your future self!”

In summary: modularization is not some profound technology; it is simply breaking down complex problems into simpler ones, solving them piece by piece, and then combining them. In the factory, simplicity and reliability are key!