Data types can be simple or complex, and many engineers have encountered issues due to data type mishaps, which is countless. Today, I want to casually discuss this topic, especially since I recently encountered a novice who didn’t understand the difference between INT and DINT, which made me so frustrated that I snatched the keyboard and solved his problem in ten minutes that he had been struggling with for an entire morning.
Last summer, at an automotive parts factory in Suzhou, I was troubleshooting a fault in an automatic line. The issue was that sometimes the counter would inexplicably run away, turning negative after exceeding 32767. The young engineer was baffled, but I immediately recognized the problem when I saw the program: using INT to store production counts is just plain foolish! INT has such a limited range; even if a shift produces 1000 units, it would overflow in a month! I changed the data type to DINT on the spot, and the problem was immediately resolved.
Speaking of data types, I must say that Siemens does a great job. The data type management in the S7-1500 is much clearer than in the S7-300/400. As long as you define the type when declaring a variable, the compiler will give you a bunch of prompts, unlike some domestic PLCs that lack proper data type checks, where errors can only be discovered at runtime, which is just ridiculous.
PLC
Data Type Perspectives from Various PLCs
Siemens’ data type system is very comfortable. BOOL, BYTE, WORD, DWORD, INT, DINT, REAL… all types are clearly defined. Especially when combined with the S7-1500 and TIA Portal, errors in data types can be detected during compilation, rather than waiting for on-site debugging to reveal issues. Look at this piece of code:
VAR
Speed: REAL; // Motor speed, unit Hz
Counter: DINT; // Production counter, using DINT to avoid overflow
Status: BOOL; // Running status flag
END_VAR
Allen-Bradley’s ControlLogix is also quite good, especially the ease of using structures. Creating UDTs (User Defined Data Types) in RSLogix5000 is super simple, organizing related data together significantly improves code readability. In 2019, I worked on a pharmaceutical project where I used a lot of UDTs; although the initial definition was a bit troublesome, maintenance became much easier later on.
However, to be honest, some domestic PLCs have disastrous data types. I encountered a PLC (I won’t name it, but everyone probably knows it) whose data type conversion capabilities were terrible; converting between WORD and DWORD required writing functions, and it was prone to errors. This is also why I prefer to spend a bit more on Siemens or AB, not asking for much, just seeking peace of mind.
1
Pits of Data Types
The biggest pitfall of data types? Overflow! This is simply catastrophic. I remember once at a paper mill control system, using an INT variable to store cumulative flow values was fine at first, but after a week, the counter suddenly turned negative. The people on the DCS side thought the flow meter was malfunctioning, and after a lot of hassle, they discovered it was a data type issue.
Then there’s the precision issue with floating-point numbers. Young folks, remember: never use the equals sign to compare two REALs for equality! Noise in industrial environments, sensor precision, and A/D conversion errors can make floating-point comparisons extremely unreliable. The correct approach is to set an allowable error:
// Incorrect approach
IF Temperature = SetPoint THEN
Valve := TRUE;
END_IF;
// Correct approach
IF ABS(Temperature - SetPoint) < 0.1 THEN
Valve := TRUE;
END_IF;
By the way, speaking of this, I remembered an old problem I encountered a couple of months ago. A novice asked me why his analog reading values were always jittery. I asked him to show me his code, and I was furious. This kid directly assigned the sensor value to the PWM output without any smoothing, and with so much noise on-site, how could it not jitter! On-site signals must be filtered, brother!! Even a simple moving average method wouldn’t work; I pulled out my phone and wrote a first-order filtering algorithm for him on-site, and the problem was immediately solved.
So, what is the principle for choosing data types? My experience is: just enough, don’t waste memory. Especially with older PLCs, memory is precious. But there is an exception to this principle – for production counts, cumulative values, and large cycle counts, go straight for DINT; don’t skimp on that little memory, it’s not worth it!
2
Data Type Conversion Between Different Protocols
What’s the most annoying thing? Inconsistent data types between communication protocols of different devices! Siemens, AB, Mitsubishi, Omron… each has different byte orders, and big-endian vs. little-endian can be a nightmare. When exchanging data between Modbus protocol and Profinet, the byte order must be checked carefully. I remember in 2020 at a steel plant in Henan, communication between Siemens S7-1500 and Mitsubishi Q series took two whole days just because the byte order was incorrect, resulting in all wrong data.
Also, during S7 communication, the DTL and DATE_AND_TIME data types; why can’t Siemens just unify them? The old S7-300 uses DATE_AND_TIME, while the new 1500 uses DTL, and the format conversion during communication is like a roller coaster.
Sometimes I wonder if these PLC manufacturers do this on purpose? Creating so many incompatible data types just to force you to buy their equipment. However, Siemens is relatively standardized; at least the documentation is detailed, and you can find what you need. Some domestic PLCs have documentation that is practically non-existent, and the details of data types are all guesswork, which is simply prayer-based programming!
Finally, I want to say that regardless of the brand of PLC, the first thing to do in a project is to design the UDT and global variable table well, clearly defining data types. Don’t think it’s a hassle; spending an extra day upfront defining data types can save you a week of debugging time later. I have seen too many engineers cramming at the last minute, changing data types while writing, resulting in programs riddled with holes, making debugging a nightmare.
Alright, I’ll stop rambling here. By the way, next time I have the chance, I’ll talk about the pitfalls of PLC interrupts and task priorities, which are truly the things that can make you lose your hair…
Before you go, remember to click “Looking”~