How Does CODESYS Automatic Type Conversion Really Work?

A mixed-type CODESYS expression compiles, but its result type or numeric value differs from what the engineer expected. Commission the expression by fixing the intended result type, tracing operand promotion, controlling narrowing conversions, and testing target-dependent floating-point boundaries.

Intended Result Type

Before anything else, confirm the type required by the destination variable and the numeric range expected during operation. Separate the expression into its source operands, operator, intermediate result, and destination. An accepted assignment proves only that the compiler found a conversion path; it does not prove that the conversion preserves the intended value.

1. Record the declared type of every operand.
2. Identify the highest-priority operand type used by the operation.
3. Record the operation's result type before assignment to the destination.
4. Compare that result type with the destination type and flag any conversion to a smaller type.

Checkpoint	Question	Confirmation
Inputs	Which declared types enter the operation?	Each operand type is listed.
Evaluation	Which type has the highest priority?	The promoted evaluation type is identified.
Output	What type does the operation return?	The intermediate result type is known.
Assignment	Does the destination require another conversion?	Any narrowing step is marked for testing.

Do not move on until the intermediate type and destination type are both explicit in the review notes or test code.

Operand Promotion

CODESYS applies automatic type promotion when an operation receives operands of different elementary types. The inputs are promoted to the type with the highest priority among those inputs, and the operator evaluates the promoted values.

For example, when an INT is added to a REAL, the INT value is promoted to REAL before addition. The addition therefore returns a REAL. This promotion happens at the operator; a later assignment can introduce a second conversion.

Expression inputs	Evaluation type	Operation result
INT and REAL	REAL	REAL

The applicable standards references identified for elementary-type promotion are IEC 61131-3 Second Edition, Table 10, and IEC 61131-3 Third Edition, Table 10. Use the table from the edition governing the project to check type priority; treat the edition as a project requirement because behavior should not be inferred from a different edition silently.

1. Break a compound calculation into individual operators.
2. Determine the promoted type at each operator rather than only at the final assignment.
3. Expose important intermediate results in typed temporary variables during commissioning.

Proceed only after an online observation or controlled test confirms the intermediate value and its intended type.

Narrowing Conversion Control

CODESYS also permits some implicit conversions from a larger type to a smaller type, including INT to BYTE and DINT to WORD. These conversions require a separate engineering decision because the smaller destination may not represent every source value.

Do not treat implicit acceptance as a range check. The result for an out-of-range value must be established from the applicable target documentation or measured on the target; it should not be guessed as truncation, wrapping, saturation, or a runtime fault.

1. Find every assignment where the destination is smaller than the evaluated expression type.
2. Determine the minimum and maximum values the expression can produce from process limits.
3. Compare those limits with the destination type's documented range.
4. Use an explicit conversion where the narrowing operation is intentional, placing any required range handling before it.
5. Test the minimum, maximum, zero-crossing, and first out-of-range values applicable to the process.

The explicit conversion documents the intended boundary between calculation and storage. Do not move on until every narrowing assignment either has a proven in-range source or a tested handling path.

Floating-Point Boundary Checks

Conversions involving floating-point values need target-specific tests. Borderline rounding depends on the target system or its floating-point unit. A value of -1.5, for example, can convert differently on different controllers.

This matters during controller replacement, runtime migration, or reuse of the same application on another processor. Identical source code does not by itself prove identical borderline conversion results.

1. Identify each floating-point-to-non-floating conversion that affects control decisions, counts, limits, or displayed values.
2. Read the target documentation for its rounding behavior.
3. Run a target test using values immediately below, at, and immediately above each operational boundary.
4. Record the observed result with the controller and runtime configuration used for the test.
5. If identical cross-target behavior is required, implement the rounding decision explicitly before the type conversion.

Do not approve the conversion after testing only ordinary positive values. Confirm negative half-way cases such as -1.5 when they fall within the application's operating range.

Date and Time Operation Review

Date and time arithmetic must be reviewed by operator semantics, not by elementary numeric promotion alone. CODESYS documents special conversion behavior for date and time values used with the ADD operator. The operand categories determine whether the operation represents an absolute value, a duration, or another supported result.

1. Open the CODESYS help entry for ADD that matches the installed environment.
2. Match the declared operand types to the documented combination.
3. Confirm the documented return type before assigning the result.
4. Use explicit intermediate variables when a following assignment changes that return type.
5. Test a known input pair and compare the online result with the calculated expected value.

Do not generalize the INT-plus-REAL example to date or time operations. Continue only after the operator documentation and an online test agree.

End-to-End Verification

Complete commissioning with a small conversion test matrix on the actual target. The matrix should exercise normal operation, type boundaries, negative values where applicable, and every intentional narrowing point.

Test class	Input selection	Pass condition
Mixed-type promotion	INT plus REAL	The observed intermediate and result are REAL.
Narrowing	Values at and around the destination range	Results match the documented or explicitly handled behavior.
Floating boundary	Below, at, and above the conversion boundary	Observed rounding matches the project rule.
Date/time operation	Known operands for ADD	Return type and value match the operator documentation.

1. Build the conversion test without changing the production calculation.
2. Monitor source operands, promoted intermediates, and destinations online.
3. Record expected and observed values for each row.
4. Repeat target-dependent cases after a controller, processor, or runtime change.
5. Release the logic only when every observed value and type matches the documented project rule.

FAQ