Last week, I went to a paper mill to troubleshoot, and the site was a complete mess. Their PLC programmer seemed to be a recent graduate, and the address allocation was a total disaster. I/O addresses were all over the place, and variable names were just a1, a2, b1, b2, it made my head hurt! Not to mention maintenance, he probably won’t understand it himself in a few days. I couldn’t take it anymore and gave that young man a lesson on the spot.
1
What is Address Allocation?
Many electrical novices do not understand the significance of address allocation, thinking it can be done randomly. I just want to ask, is your stuff thrown around at home, making it hard to find anything? The addresses in a PLC program are like the drawers in your home, if planned well, it will be ten times easier to use later!
Speaking of this, I remember in 2019 at a pharmaceutical factory in Suzhou, I took over a program where the previous guy had used S7-300 to allocate all intermediate variables in the MW area, starting from MW0 and continuously up to over MW500. Later, when the equipment was reset, the entire system went haywire because, during the reset, the MW area was cleared, and all those intermediate flags used to determine valve states were gone. I ** spent a whole day debugging.
PLC
Address Allocation Differences Among PLCs
There are significant differences in address allocation between old Siemens and AB. On the Siemens side, for the S7-300/400 series, you need to distinguish between the I area, Q area, and M area, while the S7-1200/1500 has a different concept of DB blocks. AB ControlLogix simplifies it with a single Tag, which looks easy, but the underlying structure is quite similar.
By the way, many domestic PLCs have copied the models of these two companies, just with different names. Brands like Huichuan and Xinjie are okay for use, but don’t expect reliable technical support from them. Last year, a food factory project used a certain domestic PLC, and the PROFINET kept disconnecting and reconnecting. When I called the manufacturer, they hesitated for a long time and finally said, “Try restarting it.” I was really speechless!
// Example of DB block structure in Siemens S7-1500 DATA_BLOCK “Motor_Parameters” { S7_Optimized_Access := ‘TRUE’ } VERSION : 0.1 NON_RETAIN VAR Speed : Real; // Motor speed, unit RPM Current : Real; // Current value, unit A Running : Bool; // Running status flag END_VAR BEGIN Speed := 0.0; Current := 0.0; Running := false; END_DATA_BLOCK
I generally prefer Siemens’ allocation method: physical I/O fixed in the I and Q areas, M area for system flags and intermediate variables, important parameters all placed in DB blocks. Data blocks should also be categorized, one DB for motors, one for valves, one for temperature. This way, data can be retained during power outages, and the program is easier to find.
2
Pitfalls in Real Cases
Last summer, at a parts factory in Hebei, there were five assembly lines controlled by S7-1500. The address allocation before I took over the project was a disaster, using absolute addresses like I0.0, Q2.0, which made my eyes hurt.
Even more ridiculous was a cylinder control where the intake valve was Q0.0, the exhaust valve was Q0.1, but the corresponding feedback signals? The intake valve feedback was I8.0, and the exhaust valve feedback was I10.2. Can you imagine how painful this maintenance was? It was completely asymmetrical! Fortunately, the factory manager was reasonable and allowed me to rewrite the program structure, which took three days, but maintenance became much easier afterward.
To be honest, I really dislike those self-righteous programmers who write code only considering their own understanding, completely disregarding the maintenance people. The inherited code ends up being so fragile that no one dares to change it for fear of breaking it.
// AB’s Tag structure is much clearer Motor_1.Speed // Speed value Motor_1.Current // Current value Motor_1.Running // Running status Motor_1.Fault // Fault code Motor_2.Speed // Clear at a glance, unlike those I0.0, Q2.0 messes
3
Best Practices
With many years of frontline experience, I summarize a few points:
First, physically allocate addresses by functional modules! Don’t think about saving trouble with continuous numbering. For example, use I0.0-I1.7 for the feeding area, I2.0-I3.7 for the processing area, and I4.0-I5.7 for the packaging area. Even if a few points are wasted in between, it’s okay; it makes future expansions easier.
Second, symbolic addresses must be named according to standards. If I find names like a1, b1, I will directly ask them to rewrite it. Proper naming should be like this: Valve_Inlet_Open (intake valve open), Motor_Main_Speed (main motor speed). Don’t tell me it’s too long and cumbersome; you are a programmer, not a telegrapher, typing a few more words won’t kill you.
Third, DB blocks should be clearly categorized. I usually put system parameters in DB1, motor parameters in DB10-DB19, valve parameters in DB20-DB29, and temperature parameters in DB30-DB39. This way, just by looking at the DB block number, you know what it is.
And most importantly, comments must be written! Especially in places with special handling. In 2018, I took over a car line where the previous programmer added an M area flag in a certain network without comments. As a result, every time the car body passed the inspection station, it would inexplicably stop, and it took a week to find out that this flag was a temporary patch for a specific model.
By the way, speaking of that, it’s really… never mind, I won’t say it, it’s going to make me angry again.
In short, if you do a good job with address allocation, you will save three years of overtime! Remember this, especially you newcomers. Address allocation may seem simple, but it reflects a PLC programmer’s level the most. Don’t always think about learning those flashy advanced features, if the foundation is not solid, the ground will shake. If you can’t even allocate addresses properly, how can you talk about Industry 4.0?
Before you leave, remember to click on “Looking”~