Anyone who has spent time commissioning a SCADA and PLC system has probably faced a moment of confusion when a number on the screen simply does not look right. Sometimes the value is completely wrong, showing a number that makes no physical sense compared to the actual process. Other times the display does not show a number at all, and instead shows a row of hash symbols, ####, in place of the expected value. Both situations point to the same underlying question: is this really a communication failure, or is something else going on?
In a surprising number of cases, the answer has nothing to do with the communication link itself. The PLC and SCADA may be talking to each other perfectly fine, exchanging data exactly as configured. The real issue is that the data is being exchanged and displayed using the wrong data type. This is one of those small, easy-to-overlook details that can cause hours of confusion during commissioning if it is not caught early.
Why Data Type
Selection Matters So Much
Data type selection is a foundational part of both PLC programming and SCADA configuration, and it is easy to underestimate how much weight it carries. On the surface, some data types look almost identical. They are all just numbers, stored somewhere in memory, right? In reality, each data type defines a specific number of bits, a specific range of possible values, and a specific way of interpreting whether the number can be negative or only positive. A mismatch in any of these details, even a small one, can cause a perfectly valid raw value in the PLC to be displayed completely differently on the SCADA screen.
This is exactly
why understanding the common integer data types used in modern PLC platforms is
so important:
- USInt – Unsigned 8-bit integer, storing
values from 0 to 255.
- SInt – Signed 8-bit integer, storing values
from -128 to 127.
- UInt – Unsigned 16-bit integer, storing
values from 0 to 65,535.
- Int – Signed 16-bit integer, storing values
from -32,768 to 32,767.
- UDInt – Unsigned 32-bit integer, storing
values from 0 to over 4 billion.
- DInt – Signed 32-bit integer, storing a much
larger positive and negative range.
Notice how each of these types differs not just in the size of the number it can hold, but in whether it allows negative numbers at all. If a PLC variable is defined as an unsigned type but the actual process value can legitimately go negative, such as a temperature reading below zero or a differential pressure that can swing in either direction, the SCADA system may misinterpret that value entirely. Similarly, if a smaller data type such as an 8-bit integer is used for a value that can realistically exceed 255, the number will simply overflow or wrap around, producing a displayed value that bears no resemblance to the real process condition.
Why the ####
Display Happens
The #### symbol that sometimes appears on a SCADA screen instead of an actual number is not a random glitch. In most SCADA and HMI software, this symbol is a built-in way of saying "the value I received does not fit into the display format I was configured to show." This often happens when the SCADA tag has been set up expecting a certain data type or a certain number of digits, but the underlying data being received from the PLC does not match. It could be because the data type is different than expected, because of a scaling mismatch, or because the raw data being read is fundamentally incompatible with how the SCADA tag was configured to interpret it.
Rather than displaying a wrong or misleading number, the software essentially refuses to guess and shows #### as a visual signal that something is misconfigured. While this is at least a clear indication that a problem exists, it can still be frustrating for operators and confusing for anyone trying to troubleshoot the system without understanding what is really happening behind the scenes.
Why This
Problem Happens So Often in Real Projects
One of the underlying reasons this issue shows up so frequently in real industrial projects comes down to how the work is divided. PLC programming and SCADA configuration are frequently handled by different people, sometimes from entirely different companies or departments. If the details of each variable, its data type, its scaling, its address, and its format, are not clearly and explicitly documented, each person involved may end up making their own assumptions about how the data should be structured.
The PLC programmer might choose a data type based on what feels natural for the logic they are writing, without necessarily thinking about how that value will later be interpreted on the SCADA side. Meanwhile, the SCADA configuration engineer might set up a tag based on a general expectation of what the value should look like, without directly confirming it against the PLC program. These two independent assumptions do not always line up, and the mismatch often does not become obvious until commissioning, when the system is finally tested end-to-end and unexpected values or #### symbols start appearing on screen.
Good
Practices to Avoid These Issues
Fortunately, this entire category of problems is largely preventable with a few disciplined habits.
Use standard data types. Sticking to commonly used, well-understood data types across a project reduces the chances of confusion and makes the system easier for anyone to review later.
Avoid unnecessary data conversion. Every conversion between data types introduces another opportunity for a mismatch or rounding error. Keeping data types consistent from the PLC through to the SCADA display minimizes this risk.
Create separate data blocks or structures for SCADA communication. Organizing tags specifically intended for SCADA into their own dedicated data blocks makes it much easier to review, document, and validate exactly what is being exchanged.
Clearly document address mapping and data types. A simple, well-maintained document listing every SCADA tag, its corresponding PLC address, and its exact data type removes guesswork for everyone involved in the project.
Check the same data type in both PLC and SCADA. Before assuming a mismatch is a communication error, always confirm that both sides are configured to interpret the value using the same data type.
Test communication using a simulator or OPC client before commissioning. Verifying data exchange in a controlled test environment, before connecting to the real process, gives the team a chance to catch and fix these mismatches early, when they are far easier and cheaper to correct.
Conclusion
A wrong number
or a row of #### symbols on a SCADA screen can feel like a mysterious
communication failure, but very often the real cause is something much simpler:
a mismatch in data type selection between the PLC program and the SCADA
configuration. Because PLC programming and SCADA setup are frequently handled
by different people, small assumptions about data format can easily diverge
without anyone noticing until commissioning day. Taking a few extra minutes
early in a project to standardize data types, document address mappings
clearly, and test communication before final commissioning can save an enormous
amount of troubleshooting time later. In industrial automation, these small
details are rarely glamorous, but they are exactly the kind of details that
separate a smooth commissioning process from a frustrating one.
No comments:
Post a Comment