Over the years, I have seen too many on-site programs, especially in the area of PLC sequential control, where the choice of variable types is poor, leading to numerous pitfalls. A few days ago, I went to a food factory to troubleshoot, and the program almost drove me crazy. They used a bunch of BOOL variables to store states, but they were all over the place, and the maintenance personnel spent a long time without knowing where the problem was.
1
About Variable Types
To be honest, many fresh graduates like to use BOOL because they think it’s convenient. Yes, it is convenient, but it saves your programming time at the cost of maintenance headaches later. In 2018, at a packaging line in Hangzhou, I saw a program that used BOOL to store all counting statistics, and as a result, it reset to zero once it exceeded 1, driving the operators crazy.
Think about it, isn’t sequential control just a state machine? Using BYTE or INT to store states is much better, right? One variable can store 8 or 16 states, and it’s easier to check. A couple of months ago, I helped a friend modify a program, and his program had all states as separate M points, making it as confusing as reading a foreign language; during debugging, the states were not fully visible.
The old Siemens S7-300 series actually processes INT much faster than BOOL; the internal bus operates on word size. The AB ControlLogix is similar. Using the correct data type can improve program execution efficiency by over 30%, and this is not just my opinion; it was measured in a plastic factory in Guangdong in 2021.
// This is my commonly used state definition method VAR nState : INT := 0; // Device state: 0=Stopped, 1=Starting, 2=Running, 3=Alarm, 4=Paused nStep : INT := 0; // Process step: each value corresponds to a processing step END_VAR
2
Data Processing Pitfalls
Many people like to use REAL types, thinking that having decimal points is impressive. Let me ask you, do you really need four decimal places of precision? Do you know the cost of using REAL? It’s execution time! Especially on older PLCs. Last winter, at a paper factory, they used REAL to calculate temperature, and the PLC scan cycle skyrocketed to 120ms, moving as slow as a snail, and the equipment couldn’t even respond to alarms.
By the way, when transmitting REAL types in Profinet communication, the byte order can also cause issues. When connecting devices from different manufacturers, if the byte order is not uniform, the data becomes chaotic. I encountered this pitfall in a factory in Chongqing in 2017, and it took me three whole days to debug.
Another performance bottleneck in data processing is the misuse of bit operations. I’ve seen some programs that extract a bit here and set a bit there, making the PLC unhappy and constantly timing out. If you need to process bits, why not read them into a variable all at once, process them, and then write them back in one go?
By the way, I usually use intermediate variables for data conversion, rather than operating directly on the original data. My years of experience tell me that whenever a program goes haywire, comparing it with the intermediate variable will quickly reveal the cause of the problem.
// The correct way to handle bit operations temp := source_int; temp := temp AND 16#00FF; // Mask the high 8 bits dest_byte := INT_TO_BYTE(temp); // Convert and write
3
On-Site Modification Experiences
Speaking of which, there was an incident two years ago at a textile factory in Guangzhou. Their intelligent line was all Siemens S7-1500, and the program was well-written, but there was a safety hazard in data processing. The variable boundaries were not checked, and once an operator input exceeded the limit, it caused the production line to explode. When I went to check, I thought, isn’t this asking for trouble?
There’s also a strange phenomenon; in recent years, I’ve encountered many new devices using structures to store data, which looks quite advanced. However! Many domestic PLCs have terrible support for structures, and they can’t even handle memory alignment properly; a slightly complex structure can become misaligned internally. In the summer of 2019, I visited a customer using a Xinjie PLC in Taizhou, and their structure data was all messed up, and the program wouldn’t run; it took me a whole day to discover this issue.
This is how I do it: if I can use simple variables, I won’t use structures; if I can use INT, I won’t use REAL; if I can solve it with one variable, I won’t use two. Simple, straightforward, and effective.
To be honest, there is no perfect solution in industrial control, only the most suitable solution for the site. I remember once at an auto parts factory in Shijiazhuang, their program was overly complex, with a bunch of advanced data types, and when the equipment supplier went bankrupt, no one could modify it. I went in, took a sledgehammer, and rewrote it, simplifying it to the most basic types and logic, and later their maintenance personnel could handle it themselves.
4
A Few Pieces of Advice
If you are a newcomer to this field, don’t always think about being fancy. The most valuable aspects of PLC programming are reliability and maintainability, not your flashy techniques. Remember a few points:
1. Use INT for state machine programming, don’t use a bunch of BOOLs
2. Always perform boundary checks on critical data; otherwise, if the production line explodes, you’ll be responsible
3. Variable names should be understandable; don’t use names like x1, x2 that are confusing
4. In delay-sensitive control scenarios, minimize the use of REAL and avoid fancy bit operations
Lastly, I want to say that over the years, I have seen too many programs, and the most durable ones are always the simplest. Code that can run for 30 years without issues is definitely not flashy. By the way, if anyone tells you that Industry 4.0 must use complex data structures, just tell them to go away; those people have never been to a factory site.
Before you leave, remember to click “Looking”~