Fundamentals of PLC Programming: A Beginner’s Guide to Data Types

Author: Electric Guy | 15+ years of frontline engineering experience

I’ve been asked a lot of questions about PLC data types by beginners, it’s really frustrating! Honestly, isn’t this just the most basic thing? Today’s electrical novices are really falling behind, they can’t even distinguish between BOOL and INT, yet they want to jump into programming, and when things go wrong, they come to me for help.

Last week at that paper mill, a young guy learned PLC for half a year and claimed he understood it, but ended up reading temperature data as BOOL, causing the equipment to crash and stop, resulting in losses of hundreds of thousands. The factory manager was so anxious he was stomping his feet. I got the call and rushed over, fixing their problem in 10 minutes after they had struggled with it for a day. This industry really isn’t just about talking; you need on-site experience.

–

Basic Data Types – Don’t tell me you don’t know

Old Siemens and AB PLC data types are actually very simple, but many people just can’t understand them. BOOL (just one bit, 0 or 1), INT (integer), REAL (floating point, the kind with a decimal point). These few types can confuse a lot of people, it’s really unbelievable.

In June 2019 at that factory in Suzhou, a guy stored temperature in WORD, and lost the sign, resulting in negative temperatures turning into tens of thousands of degrees in winter, causing the temperature control to explode. I asked him at the time: Are you out of your mind? Temperature can be negative, use INT!

Speaking of this, it really makes me mad! Domestic PLCs can’t even copy correctly. Siemens INT is 16 bits, DINT is 32 bits. Some domestic PLCs have secretly changed the bit count, which means every time I use a new brand, I have to check the documentation first, otherwise, I might fall into a pit.

Common Data Type Comparison

Type	Siemens	AB	Electric Guy’s Complaints
Boolean	BOOL	BOOL	Surely you can’t get this wrong?
Integer	INT (16 bits)	INT (16 bits)	Remember it’s signed!
Long Integer	DINT (32 bits)	DINT (32 bits)	Use this for large values
Floating Point	REAL	REAL	Takes longer to process, use sparingly!

-1

Pitfall Scene – I’ve dug the pit for you, don’t jump in again!

What happens if you choose the wrong data type? At best, the data is all messed up; at worst, the system crashes! Back in 2018, during a car line project, a guy used a timer as UINT, resulting in all the timing being messed up. It took a week of day and night troubleshooting to find out. At that time, I hadn’t seen my wife and kids for a long time, and I hadn’t taken a vacation in three years, all because of such a rookie mistake.

Honestly, the biggest mistake you make when choosing the wrong data type is mismatching. Stuffing BOOL into INT, converting INT to REAL without caring about the conversion process, thinking as long as it compiles, it’s fine. Just because it compiles doesn’t mean it won’t have runtime issues, do you understand?

The most common pitfalls:

• Using BOOL for analog values, I just want to ask what you’re thinking?
• Storing floating point in INT, directly losing the decimal part, losing all precision
• Using WORD/DWORD for negative numbers, losing the sign bit, -10 becomes 65526
• Mixing STRING and CHAR, incorrect length for Chinese characters, displaying all garbled

By the way, the Profinet communication implementation here has even more serious data type mismatch issues. If the data types between the master and slave are inconsistent, communication timeouts can cause a crash. Lying on the ground looking for sensors? Tired to the point your eyes can’t open? Hungry to the point of dizziness? No, it’s all because you didn’t choose the right data type!

Classic Error Code Example

// This code is simply a disaster, I want to hit the person who wrote it
TEMP := INT_TO_BOOL(AnalogValue);  // Forcing analog value to BOOL, purely suicidal
IF TEMP THEN
    Motor_Speed := 100;  // Motor runs at full speed, equipment will definitely explode
ELSE
    Motor_Speed := 0;    // Motor completely stops, no intermediate state
END_IF;

// Storing floating point calculation result in integer, without rounding, utterly foolish
Result_INT := REAL_TO_INT(3.14159 * Diameter);  // All decimals lost

-2

Data Conversion – Don’t convert blindly, it can be deadly

While staying up all night with Xiao Wang, I found that an old Siemens PLC in a control cabinet just wouldn’t work. Where was the problem? Communication interruption. The reason was that variable type conversion went wrong, and there was no overflow check when converting from floating point to integer. Overflow values don’t even throw errors, they silently give you a wrong value, making debugging impossible.

Remember a few basic principles:

• Converting small types to large types (INT to DINT) is generally safe
• Converting large types to small types must check for overflow
• When converting between floating point and integer, always handle precision and rounding
• When converting between boolean and numeric values, clarify what counts as TRUE

In the summer of 2021 at a paper mill in Zhejiang, they had one person watching the HMI, manually pressing the stop button when the analog value exceeded the threshold. I asked him why not directly program the control? He said someone had written it before, but it often stopped incorrectly, and after checking, it turned out that the REAL comparison was written incorrectly, causing precision issues. I slammed this writing style with a brick; floating point comparisons must use difference judgment!

Correct Floating Point Comparison Method

// This is the correct way to compare floating points, not just random comparisons
IF ABS(Real_Value1 - Real_Value2) < 0.0001 THEN
    // Considered equal
ELSE
    // Not equal
END_IF;

// Converting integer to floating point before calculation to avoid overflow
Result_REAL := INT_TO_REAL(Value1) / INT_TO_REAL(Value2);
Result_INT := REAL_TO_INT(Result_REAL + 0.5);  // Rounding

4

Advice from an Old Electrician

After so many years, I still believe that choosing the right data type is the most fundamental and important thing. It’s like laying the foundation for a house; if the foundation isn’t done well, everything built on top is wasted. A few suggestions:

First, choose types based on actual needs, don’t take shortcuts. If a thermometer can go to negative tens of degrees, don’t use WORD; if pressure values have decimals, don’t use INT. Let me tell you, the first thing I do when taking over someone else’s project is to check all variable types, and if I find a mistake, I scold them.

Second, don’t be lazy with conversion functions. Many people take shortcuts and directly force conversions without any protection or checks. Strange phenomena arise from this, and the system behaves erratically; upon investigation, it’s all due to type conversion issues.

Third, make good comments. There’s nothing more to say about this, every special data type’s usage must be clearly marked, otherwise, six months later, even you won’t understand it. Especially for those bit operations (BITFIELD), if the comments aren’t clear, maintenance is impossible.

In the past two years, the market has been tough, and the quality of newcomers I’ve encountered is concerning. A monthly salary of over ten thousand isn’t given for free; foundational knowledge must be solid! Take my advice, practice more, step into pits, and don’t find it annoying. There are no shortcuts; you have to do the dirty and hard work to understand.

Any questions? Don’t get into those fancy things; first, master data types, or else see how you survive in this industry! Ultimately, if you can’t even understand something as simple as data types, you might as well change careers to become a product manager, haha!

This article is purely a personal experience sharing by the author; take the essence and discard the dross. Feel free to communicate if you have questions, but if not, don’t ask nonsense!

Before you go, remember to click “Looking”~