Click the blue text for more exciting information

Things About Modular Design in PLC Industrial Automation Systems

I just returned from a pharmaceutical factory in Jiangsu, where I spent three days and nights getting the production line up and running. To be honest, every time I see those messy PLC programs, I get a headache. Some of the code written by outsourcing companies is simply a pile of junk, completely lacking modularity, making it impossible to modify! I’ve seen this situation far too often.

Modular design is not something fancy; it simply means breaking down the PLC program into independent blocks that can work together. The automotive line project I did in 2017 was a great example of good modularization. We changed the process three times, and each time we only had to adjust a few functional blocks, which saved a lot of money according to my boss.

I have always admired Siemens’ approach; their TIA Portal for the S7-1500 makes modularization really comfortable. Using Function Blocks (FB) with Data Blocks (DB) is incredibly satisfying. In contrast, those cheap domestic PLCs don’t even have decent modules. Every time I look at their programs, it’s just a bunch of networks strung together, and it takes forever to find a parameter to change, which is infuriating!

When it comes to reducing costs, many people’s first reaction is to buy cheaper PLCs. I want to curse! This is the dumbest approach.

Think about it, a production line costs hundreds of thousands or even millions; what good is saving a few thousand on a PLC? The real costs lie in maintenance, upgrades, and production losses! If it takes a day to find a bug in a lousy program, the loss in production can be tens of thousands a day; that’s the real cost!

By the way, a few days ago, our beverage factory had another issue. The reason was that they modified some programs themselves, and the entire filling line went haywire. When I went to check, the program was full of GOTO statements jumping around; who can understand that? It took me four hours to find the problem. If they had done modularization properly, it would have been resolved in half an hour.

Key points for effective modularization:

First, the IO allocation must be unified. This needs to be considered during the initial design phase; the input and output address allocation should follow a pattern, such as segmenting by function or device, and not be done haphazardly. I’ve seen the most ridiculous cases where the IO of a single device is scattered across four or five different locations, making it impossible to find. Engineers like that should be executed!

Next is data processing. Many people like to use global variables and read/write directly from various places, which is simply laying a minefield. Last year, a paper mill had this issue; when one parameter was changed, the program had inexplicable problems in three different places, and debugging left me and Xiao Li exhausted. The correct approach is centralized data management with a unified read/write interface. Siemens’ DB is very useful, and AB’s is also acceptable.

Communication modules are crucial. I remember back in 2020, I worked on a distributed control system with seven or eight PLCs and dozens of frequency converters, all relying on communication to work together. If we hadn’t modularized the communication functions from the start, we would have had to rewrite everything during expansion.Communication issues are the hardest to troubleshoot; if it can be modularized, it must be!

// Example of a communication function block on Siemens S7-1500

FUNCTION_BLOCK "ModbusTCP_Read"

{ S7_Optimized_Access := 'TRUE' }

VERSION : 0.1

VAR_INPUT

Execute : Bool;   // Trigger read

DeviceID : Int;   // Device ID

Address : DWord;  // Register address

END_VAR

VAR_OUTPUT

Done : Bool;      // Completion flag

Busy : Bool;      // In progress

Error : Bool;     // Error flag

Data : Array[0..31] of Word;  // Data read

END_VAR

I have also seen a bizarre case where everything was crammed into timers. Timers were flying all over the PLC program, using T0 to T255, and they didn’t even know what each timer was for. Programs written by such people become incomprehensible even to themselves after six months, let alone for others. The correct approach is to encapsulate functionality in blocks, with each module doing one thing and all parameters passed externally for high configurability.

By the way, alarm handling is often the worst part of many projects. What do I mean by bad? It means when something goes wrong, you have no idea where the problem is. Last year, at a plastic injection factory in Guangdong, the alarm just displayed “system fault”; what the hell is a system fault? With hundreds of sensors and dozens of actuators, just telling me “system fault”? Debugging was a nightmare!

The modular approach to alarms is simple: number each possible fault point, with each number corresponding to a specific fault description and handling suggestion, then create a function block that can be called where needed. Don’t be lazy; does writing a few more lines of code hurt?

// Alarm handling function block snippet

IF Sensor1_Error THEN

AlarmCode := 1001;  // Sensor 1 fault

AlarmText := "Feed sensor disconnection or signal anomaly";

AlarmAction := "Check sensor wiring and signal";

ELSIF Motor1_Overload THEN

AlarmCode := 2003;  // Motor 1 overload

AlarmText := "Main drive motor overload protection";

AlarmAction := "Check load or adjust overload protection settings";

END_IF;

After writing all this, the core message is:Programs are meant to be read by people, not just executed by machines. A program that runs today may need to be modified tomorrow; good modularization can reduce maintenance costs by more than half.

Lastly, even if modularization is done well, documentation cannot be neglected. I absolutely hate it when people finish writing a program without adding any comments. When you leave, and others take over, if they can’t understand it, they’ll have to come back to you or just rewrite it, which incurs additional costs.

Modularization + documentation is the true way to reduce the total lifecycle cost of PLC systems. Whether you use Siemens, AB, or any domestic brand, this principle is universal.

As an old electrical engineer, I can’t say much, but I’ve fallen into enough pits over the years.In industrial control, don’t just focus on equipment costs; consider maintenance costs and downtime costs, and you’ll understand the importance of modularization.

Disagree? Just keep watching me.