It’s unbelievable, I see someone asking about PLC address allocation again. It’s already 2024, and people are still struggling with this issue, which is a common problem for field electricians. What is there to discuss? Alright, for the sake of all the newcomers, I will talk about it today to save you from stepping into pitfalls one by one.
AB and Siemens Issues
I remember back in 2018 at an auto parts factory in Suzhou, when we just installed an S7-1500, the guys started allocating addresses randomly, resulting in the program running away and we couldn’t find the cause. These electrical novices were completely clueless! Siemens PLC address allocation has its rules; it’s not just a matter of writing anything down.
First of all, inputs and outputs must be separated, this is common sense, right? The I area is for inputs, and the Q area is for outputs. How can the program not have errors if you mix them up? Some beginners come in and define variables in all sorts of chaotic types, using MD, DB, etc., just digging their own graves.
Let me tell you, in the old Siemens system, the M area memory addresses are global, so don’t use them randomly, especially those variables called in functions. Use local variables in the DB area to avoid problems that you can’t even trace back.
// This is the correct address allocation method
"Motor_Start" AT %I0.0; // Motor start button
"Motor_Stop" AT %I0.1; // Motor stop button
"Motor_Run" AT %Q0.0; // Motor run output
By the way, AB’s PLC uses a completely different logic; they differentiate by file areas, like N7, B3, C5, the foreigners like to do things differently. When I went to a steel plant in Hebei in 2021 to troubleshoot, the entire control system just wouldn’t work. Upon checking the code, I found that they were using the Timer file area as a Counter and the Counter as a temporary variable, making a complete mess. I thought about quitting right then.
Memory Allocation Pitfalls
Speaking of address allocation, do you know why sometimes the program suddenly freezes? It’s due to address overlap! Speaking of which, last month at a factory in Wuhu, they were using domestic PLCs (I won’t name names, but it was either Xinjie or Hexin), and what a mess it was; the INT type addresses overlapped with BOOL addresses, causing the program to fail after running for a while.
Data types and the number of bytes they occupy, if you don’t understand them, don’t touch PLCs, seriously. BOOL occupies 1 bit, BYTE occupies 8 bits, INT occupies 16 bits, and DINT occupies 32 bits; these are common knowledge. If you can’t even grasp this, I suggest you go farm instead.
Moreover, different PLCs have different rules; for example, in Siemens’ S7-300 series, word addresses must start with even numbers, like MW0, MW2, etc. If you use MW1, it will throw an error in no time. I remember a new engineer, a master’s graduate, who was quite good on paper, but when it came to on-site programming, he directly used odd addresses, and the equipment crashed, leaving him completely bewildered. It was infuriating.
My Best Practices
Alright, I’ve vented enough; let’s talk about some practical advice. Over the years, I have summarized a few iron rules:
1. Input signals go in the I area, output signals go in the Q area, and all intermediate variables go in the DB area; avoid using the M area unless necessary.
2. Variable naming must be standardized; don’t use x1, x2, etc., or you won’t be able to find anything when problems arise. I prefer to use “DeviceName_Function_IOType”, for example, “Pump1_Start_In”.
Look at my code; it’s quite standard:
// This is my commonly used DB block definition method
DATA_BLOCK "Motor_Parameters"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
VAR
Speed : Real; // Motor speed
RunTime : Time; // Running time
Fault : Bool; // Fault flag
END_VAR
3. Leave enough space for expansion, this is super important. For example, I start input addresses from I0.0, but I won’t use them continuously; I will leave 8 points empty for each device module. You think the project is done and dusted? After a while, you’ll realize that requirements keep piling up, and having reserved space can be a lifesaver.
4. Ensure that the configuration addresses match the PLC addresses. In the summer of 2019, at a factory in Guangzhou, with temperatures soaring to 35 degrees, I was debugging in front of the cabinet and found that the HMI couldn’t control the equipment no matter what. After a day of hassle, I discovered that the configuration software address mapping was incorrect. Since then, I have enforced that addresses must correspond one-to-one.
Lastly, Siemens’ TIA Portal has now implemented symbolic programming, making address allocation less critical. However, I still recommend that everyone build a solid foundation; if you don’t understand the underlying principles, you will eventually suffer.
Real Case
Last winter, I remembered an automation project at a grain depot in Northeast China, where the temperature was below -20 degrees, and the heating system broke down. The person in charge, Xiao Wang, insisted that his address planning was fine, but when the system started running, the sensor data was all over the place. I looked at his program, and good grief, the analog address was completely misaligned; MD10 directly overwrote the previous digital signals, wasn’t that just asking for trouble?
So, address allocation may seem simple, but there are more pitfalls than you think. However, as long as you follow my advice, you won’t go wrong! Oh, by the way, recently someone asked me about domestic PLCs. To be honest, they are cheap, but as for stability… let’s not get into that, so you can figure it out for yourselves.
Before you go, remember to click “Looking”~