Click the blue text for more exciting information
Having been in this industry for over a decade, I must say, I get really frustrated when I see new electrical engineers designing PLC systems. Especially when it comes to data types, many have no concept at all, just copying a few lines of code from the internet, piecing things together, and ending up with a bunch of inexplicable issues during debugging.
About Data Types
Let’s start with Siemens. Back in the old S7-300 days, people might not have paid much attention to data alignment. As long as it runs, it’s fine. But with the S7-1500, if data alignment is not handled properly, you can easily encounter offset errors. In the summer of 2021, I was at a printing factory in Guangdong, and a young engineer couldn’t solve a communication problem after three days of trying. When I took a look, it was all mixed-up BOOL types and DWORDs, completely disorganized.
Data types are not something to be used casually. BOOL is 1 bit, BYTE is 8 bits, WORD is 16 bits, DWORD is 32 bits; each type occupies different space, and with byte alignment, if you’re not careful, the addresses can be wrong. The most troublesome thing is that some PLCs’ BOOL arrays are stored compactly in Siemens, where one byte can hold 8 BOOLs, but in Allen-Bradley, each BOOL occupies a separate byte. If you don’t understand this difference, you can expect issues when porting code.
Speaking of Allen-Bradley’s ControlLogix, the UDT (User Defined Type) is completely different from Siemens’, and mixing them up can lead to disaster. By the way, I won’t even mention those domestic PLCs… If you’re going to copy, at least do it properly; the API design is unnecessarily complicated, and some don’t even support structure definitions, making it a nightmare for large projects.
Pitfalls in HMI Interaction
Now let’s talk about the data interaction between HMI and PLC. I’ve seen the most ridiculous cases where all data is dumped into DB1, a bunch of disorganized variables without any structure, and when communication issues arise, they don’t even know where to start looking. The correct approach is to design the data structure by functional modules, for example, DB10 for drive parameters, DB11 for recipes, DB12 for alarm information; isn’t that much clearer?
Then there’s the choice of communication protocol. In 2019, I modified a project where the guy was using S7-1200 with Modbus TCP, and it turned out that the HMI occasionally failed to read. Later, I found out that he had redefined variable addresses for every screen in the HMI, it’s 2023, and you’re still doing this primitive operation? A good system design should have the PLC internally define the structure, and the HMI should just read specific DB blocks, separating read and write, with centralized variable management.
// This is my commonly used PLC data structure definition method (SCL language)
TYPE Recipe_Type
Name : STRING[20]; // Recipe name
Speed : REAL; // Running speed
Temp : INT; // Temperature setting
RunMode : BOOL; // Running mode
END_TYPE
// Then create an array to store multiple recipes
"Recipes" : ARRAY[1..10] OF Recipe_Type;
Speaking of structures, those who have worked with Siemens know that when defining UDT in TIA Portal, placing BOOL variables at the end can save a lot of space. I taught this little trick in a car factory in Jiangsu in 2018, but the guy forgot it right after, and still placed BOOL types randomly, causing the data block to occupy 30% more space, how can the transmission efficiency not be low?
Also, when designing HMI, many people like to pass strings around, especially those using configuration software. But you should know that string processing in PLCs is resource-intensive! Old Siemens, especially the 300 series, processes strings as slowly as a snail. If you can use numeric encoding, don’t use strings; if you can use bit states, don’t use integers; this is basic common sense for improving efficiency. Yet, in about 90% of the projects I see, people don’t pay attention to this.
A Real Case
Last winter, a paper mill’s production line control system kept crashing inexplicably. The factory was in a panic because every downtime cost them tens of thousands. When I went to check their program, it was all bad code. The funniest part was that they used a huge STRING variable in the PLC, set to 254 (the maximum value), to transmit all process parameters, and then parsed this string in the HMI. I was puzzled, who the hell taught you to write code like this??
I rewrote their data structure, using a UDT to include all parameters, each occupying the most suitable data type, and then the HMI directly read this DB block. After the changes, the system’s stability improved immediately, and the CPU load dropped from over 80% to around 30%.
// Refactored data interaction method (rewriting the previous bad code)
DATA_BLOCK "HMI_Interface"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
VAR
SystemStatus : BYTE; // Bitwise representation of different states, 8 states in one byte is enough
AlarmCode : WORD; // Alarm code, using a lookup table instead of strings
Parameters : ARRAY[0..9] OF REAL; // Process parameters stored centrally
// Other parameters...
END_VAR
BEGIN
END_DATA_BLOCK
Finally, let me say something from the heart: in automation, if you don’t understand data structures, no matter how long you work, you’ll always be a half-baked engineer. I’ve seen veterans with 8 years of experience who can only copy others’ programs and tweak parameters; when faced with slightly more complex projects, they’re at a loss. So young people, don’t just bury your head in work; think more about the underlying principles and design data structures well, and you’ll find your work efficiency can improve by more than double.
Alright, I’ve rambled on a lot; I hope this can help those new electrical engineers. Remember: A reasonable data structure is the foundation of a stable system, don’t be lazy, spend more time on design, and it will save you a lot of trouble later.
Just give me a look if you disagree
