reference · South Africa
IEC Data Conversion: Rounding, Scaling and BCD
IEC data conversion for PLC learners: compare rounding rules, scaled integer storage, BCD formats and range checks with practical examples and clear tests.
IEC data conversion changes how a value is represented for another operation, storage field or interface. Names such as INT_TO_REAL and REAL_TO_INT are useful starting points, but a correct conversion also needs a range, rounding rule, unit convention and failure policy. Changing the type does not automatically preserve every detail of the original value.
For South African PLC learners, the practical goal is to explain what information a conversion preserves and what it can discard. This guide uses mathematical fixtures for rounding, hundredths-based storage and a simple packed decimal format. They are training examples, not recommended process settings or proof of native controller behaviour.
This site has a commercial connection to PLC Simulator. Its educational tools do not provide vendor engineering licences or guarantee support for arbitrary native conversion code. The illustrations are conceptual study scenes, not vendor screenshots or evidence of a production installation.
Distinguish conversion, scaling and reinterpretation
A numeric conversion attempts to represent a numerical value in another type. Scaling changes the numerical value according to a defined relationship, such as converting a count of hundredths into whole engineering units. Reinterpreting bits gives an existing pattern another meaning without necessarily preserving its numeric value.
These operations can appear next to each other in a program, but they should not be confused. Converting the integer 450 to a floating-point value gives a representation of 450. It does not automatically turn a measurement stored in hundredths into 4.50. The scale factor is a separate part of the interface contract.
| Operation | Question to answer before using it |
|---|---|
| Numeric type conversion | Can the destination represent the required value and precision? |
| Unit or scale conversion | What formula and units define the relationship? |
| Rounding | Which integer should represent a fractional value? |
| Bit reinterpretation | What encoding does the source pattern actually contain? |
| String formatting | What text format and length does the receiver require? |
Do not use a memory-copy operation as a general substitute for a numeric conversion. It may be appropriate when reconstructing a documented encoded value, but that is a different task from turning a number into the same number in another type.
Write the conversion contract first
A short contract should state the source type and meaning, the destination type and meaning, the accepted range, the rounding rule and the response to an invalid input. Include whether the destination changes on failure. Without those decisions, a successful assignment can still produce an unusable application result.
For a fictional setpoint archive, suppose the source is expressed in engineering units and the destination stores integer hundredths. The contract might accept values from zero through 100 units inclusive, multiply by 100, round to the nearest integer with ties to even and store the result only after validation. It returns a status for rejected input instead of silently changing the active record.
That is a complete teaching policy, not a universal recipe rule. Another application may require truncation, a different range or more precision. The point is to make the decision visible so tests can distinguish an implementation error from an ambiguous requirement.
For broader context on units and resolution, use our analogue scaling guide. A type conversion should fit into that documented measurement path rather than being used to guess what an input number means.
Integer width and floating-point precision solve different problems
A wider integer can represent a larger range of exact whole numbers. A floating-point type can represent fractions and a wide range of magnitudes, but not every number within that magnitude range is represented exactly. A type with a large maximum value does not necessarily distinguish every adjacent integer below that maximum.
When choosing a destination for an exact counter or identifier, ask whether exact whole-number distinctions must remain intact. For an engineering calculation, ask how much resolution the representation supplies where the calculation operates. Do not choose a type merely because its name sounds more precise.
The CODESYS REAL and LREAL reference documents the floating-point formats and notes that LREAL support depends on the target. It also warns that out-of-range conversion to integer types can have target-dependent results, including exceptions. Checking the range is part of a portable application design.
Our comparison-instruction reference includes a checked example in which two distinct large integers become equal after conversion to binary32. Converting the rounded result to a wider type afterwards cannot recover the distinction that has already been lost.
Rounding, truncation, floor and ceiling
Rounding to nearest selects the closest integer, with an additional rule needed when the input lies exactly halfway between two integers. Truncation towards zero removes the fractional part in the direction of zero. Floor chooses the greatest integer no larger than the input; ceiling chooses the smallest integer no smaller than it.
Negative values expose the difference. Truncating negative 2.9 gives negative 2, while its floor is negative 3. A rule that says “drop the decimal part” is not an adequate explanation of every rounding function a platform provides.
For this mathematical table, nearest rounding uses ties to even. Apply each column independently to the original input. The results do not depend on a native PLC instruction being available under the same name.
| Input | Nearest, ties to even | Truncate towards zero | Floor | Ceiling |
|---|---|---|---|---|
| 2.5 | 2 | 2 | 2 | 3 |
| 3.5 | 4 | 3 | 3 | 4 |
| 2.9 | 3 | 2 | 2 | 3 |
| -2.5 | -2 | -2 | -3 | -2 |
| -3.5 | -4 | -3 | -4 | -3 |
| -2.9 | -3 | -2 | -3 | -2 |
“Ties to even” does not mean always rounding down. The two positive halfway cases go in different directions because their nearest even integers differ. The negative cases also need explicit expectations; testing only positive values leaves an important part of the contract unexamined.
Check the actual vendor conversion rule
Siemens' STEP 7 V21 ROUND reference describes nearest-integer rounding and choosing the even integer at an exact halfway point. It also documents the enable output for execution errors. Confirm the selected operand types and instruction form in the project.
Rockwell's Logix Designer REAL-to-integer reference describes rounding fractional parts, including nearest-even treatment of halfway values. The claim that Studio 5000 always truncates a REAL-to-DINT conversion towards zero is therefore incorrect. A separately selected truncation operation is a different choice.
CODESYS documents its REAL and LREAL conversion operators, including examples and target-range considerations. Do not infer that every operation containing a type name follows every other vendor's syntax or lifecycle. Use a small positive-and-negative fixture in the intended environment to verify the exact operation being taught.
A conversion rule is also not permission to ignore overflow. The documented rounding outcome for a small input says nothing about whether a much larger rounded result fits the selected destination.
Scale before rounding when the destination stores hundredths
Return to the fictional archive contract. The source value 9.75 units should be stored as 975 hundredths. Multiplying by 100 first preserves the intended two-decimal resolution before the final integer conversion.
Rounding 9.75 to a whole unit first gives 10, and multiplying that by 100 gives 1000. This differs from the required result by 25 hundredths, or 0.25 units. Both sequences contain a multiplication and a rounding step, but their order changes the meaning.
| Source in units | Correct mathematical hundredths | Round to whole units first, then multiply |
|---|---|---|
| 9.75 | 975 | 1000 |
| 9.25 | 925 | 900 |
| 0.04 | 4 | 0 |
The last case shows that rounding too early can remove the entire small value. Casting to a wider type afterwards does not restore it. Keep the intermediate arithmetic in a representation that supports the intended calculation, then round at the boundary where an integer representation is required.
For inputs with more than two decimal places, the contract still needs its tie rule. In exact decimal arithmetic, 1.225 units becomes 122.5 hundredths and rounds to 122 under ties to even. 1.235 becomes 123.5 and rounds to 124. These are exact-decimal expectations; a native binary floating-point implementation must also be checked for its representation of the original decimal values.
Validate range before committing the result
The example accepts source values from zero through 100 units. Under that contract, a negative input or one above 100 is rejected before a new archive value is committed. A destination capable of storing a larger integer does not make an out-of-contract setpoint acceptable.
Also check the representable range of every intermediate and destination type. An intermediate multiplication can overflow before the final conversion even if the intended mathematical result appears reasonable in a larger destination. Choosing the output type alone does not determine the types used throughout an expression.
For the fictional archive, the maximum accepted stored value is 10000 hundredths. On failure, the previous archive remains unchanged and the conversion returns an explicit rejected status. The user interface should report the current request's failure rather than presenting the previous stored value as a newly accepted result.
Do not rely on wraparound or a truncated bit pattern as a usable overflow response unless that behaviour is expressly the requirement. A controller diagnostic can help reveal an error, but it does not choose the correct application recovery policy for you.
Binary-coded decimal is an encoding, not a display preference
For a separate fictional interface, define an unsigned four-digit packed BCD word. Each four-bit group represents one decimal digit from zero through nine. There is no sign field in this teaching format, and all four groups are digits.
The pattern 1234 hexadecimal then represents decimal digits 1, 2, 3 and 4, giving the decimal number 1234. If the same sixteen bits are interpreted as an ordinary unsigned binary integer, the numerical value is 4660. Merely changing the monitor's display radix does not perform the BCD decoding required by the interface.
| Word pattern | Interpretation under the fictional BCD format | Ordinary unsigned binary value |
|---|---|---|
| 0000 hexadecimal | Decimal 0 | 0 |
| 0099 hexadecimal | Decimal 99 | 153 |
| 1234 hexadecimal | Decimal 1234 | 4660 |
| 9999 hexadecimal | Decimal 9999 | 39321 |
| 12A4 hexadecimal | Invalid digit A | 4772 |
Validate every digit group. The invalid 12A4 fixture must not silently become an accepted decimal record. A real legacy interface can use other digit counts, sign conventions or byte layouts, so obtain its exact format before selecting a conversion instruction.
When encoding a decimal value for this fixture, the accepted integer range is zero through 9999. The value 10000 cannot fit into four decimal digits, even though it fits easily into a sixteen-bit unsigned binary integer. Binary storage capacity and decimal encoding capacity are different limits.
Old mnemonics do not establish conversion direction
A course or inherited project may use older instruction names. Rockwell's version 36 release notes document changes including TOD to TO_BCD, FRD to BCD_TO, MOV to MOVE and TRN to TRUNC. Establish the release and intended direction before following an old screenshot.
Write “binary integer to the documented BCD format” or “BCD format to integer” in the requirement. That is clearer than remembering two short mnemonics without their operand meanings. Confirm the supported digit count and invalid-data behaviour of the actual instruction rather than assuming the four-digit fixture is universal.
Do not mix BCD conversion with byte swapping. An interface can require both correct digit interpretation and correct byte ordering, but they are separate transformations. A known test value with different digits helps reveal which operation is wrong more clearly than a pattern of repeated zeros.
String conversion needs a formatting contract
Converting a number to text introduces questions beyond numeric range. Specify the decimal separator, sign convention, precision, maximum length and whether exponent notation is permitted. A receiver expecting a fixed number of decimal places may not accept a generic formatted string that contains the same apparent value.
The CODESYS conversion documentation describes limits and possible truncation when a destination string is too short. Treat formatting as an interface operation with tests, rather than assuming that every numeric-to-string conversion is a lossless archive format.
For an operator-entered value, distinguish parsing failure from an out-of-range valid number. An empty string, unexpected separator or additional unit text should follow the documented input policy. Do not silently use zero as the universal result of every unsuccessful parse, because zero may be a legitimate requested value.
Keep the accepted numeric value and its formatted presentation separate where useful. A rounded display can be appropriate for reading while the stored value retains more detail. The display alone is then insufficient evidence for a precision-related conversion investigation.
Analogue input conversion needs the module's actual representation
An analogue example copied from another project may assume a raw range that does not match your input module, channel configuration or signal type. Obtain the relevant representation and diagnostic information before applying a familiar scaling constant.
Converting a raw integer to REAL changes its representation; it does not identify which counts represent normal measurement, overrange or invalid data. Check those meanings before the value enters a general formula. A numerically valid conversion can otherwise turn a diagnostic code into an apparently plausible engineering value.
Our analogue signal types guide provides context for understanding the measurement path. Keep the actual channel documentation with the project and state which parts of a classroom example are assumed rather than measured.
For a test, use the documented low and high points, an intermediate point and relevant invalid or out-of-range cases. Compare the expected engineering value and validity result, not merely whether the conversion instruction completed without a visible error.
Keep conversion outside an unreviewed recipe change
A successfully converted value is a candidate for use, not proof that applying it now is appropriate. A recipe or parameter workflow may require additional consistency checks, permissions and process-state conditions. Keep those decisions visible rather than hiding them inside a type conversion.
In the fictional archive example, conversion validates and prepares a candidate integer. A later application operation owns the decision to replace the active record. The recipe-management guide discusses that broader distinction between stored data, selection and application.
If several parameters belong together, validate the complete candidate set before treating the update as accepted. Converting one field successfully while another fails can leave a mixed record if the application commits fields independently. The appropriate consistency mechanism depends on the project, but the requirement should describe the intended all-fields result.
A conversion test set that catches real distinctions
For rounding, include positive and negative values, exact halves and values just to either side. For range handling, include both accepted endpoints and rejected values outside the contract. For scaled storage, compare scaling-before-rounding with the deliberately wrong reversed order.
For the BCD fixture, test zero, the largest four-digit value, a mixed-digit pattern and an invalid digit group. Test both encoding and decoding, but do not rely only on a round trip: two implementations can share the same mistaken convention and still reverse each other.
For strings, test the longest accepted output, a negative value and input that violates the chosen format. Record whether failure leaves the previous destination unchanged, returns a status or follows another explicitly defined policy.
PLC program testing practice can help build this evidence. The checks supplied with this guide verify the exact mathematical and encoding fixtures, not compiled native instructions or equipment behaviour.
What to ask a South African PLC training provider
Ask whether the course distinguishes numeric conversion from scaling and bit interpretation. A useful practical task should require the learner to choose a rounding rule, test a negative input and explain what happens when the destination cannot represent the result.
Confirm the software version, target and individual access arrangements. A provider teaching legacy migration should identify the actual legacy formats and updated instruction names it covers. A generic claim to cover all PLC conversions does not establish that the learner will practise those specific tasks.
A credible portfolio includes the conversion contract, expected table, environment and a failed case with its correction. Label mathematical checks, vendor simulation and measured hardware work separately. Do not turn a successful conversion exercise into an unsupported claim of commissioning experience or formal accreditation.
The Structured Text learning tools can support earlier work with expressions and test cases. Use the required vendor environment when the objective is its actual conversion, status and diagnostic behaviour.
Common data-conversion questions
Does REAL_TO_INT always discard the fraction?
No. Rounding depends on the documented operation and environment. If the requirement is truncation towards zero, select and verify an operation that implements that rule rather than assuming every numeric cast does so.
Should I round before converting a measurement to hundredths?
For this guide's contract, scale into hundredths first and round once at the integer-storage boundary. Rounding to whole units first loses the fractional information the destination was designed to retain.
Can a larger output type recover lost precision?
No. A wider destination can preserve more information only if that information reaches it. It cannot reconstruct fractions removed by earlier rounding or distinctions lost in an earlier narrow representation.
Why does a BCD value look wrong in decimal display?
The monitor may be interpreting the bits as an ordinary binary integer. Decode the documented BCD format before treating the value as a decimal quantity. Changing the display radix alone does not establish the intended encoding.
What should happen on conversion failure?
The application needs an explicit policy. The fictional archive preserves the previous value and reports rejection. A real system must define how that status affects its interface and operation rather than silently treating an old value as a fresh success.
Save the meaning with the number
Keep the units, source and destination types, accepted range, rounding rule and invalid-data response with the exercise. Show why 9.75 units becomes 975 hundredths, why negative rounding needs its own cases and why a BCD digit pattern is not an ordinary binary integer.
That record makes a conversion reviewable. It lets another learner distinguish a correct transformation from a result that merely fits into the destination field.