Effects of the compiler settings on the execution
Accuracy and behavior of mathematical functions
Mathematical functions that are processing floating-point numbers (REAL, LREAL) might return different results on different target system s – in particular, if the result of the function is located within the threshold of the data type. These different inaccuracies of the mathematical functions is caused by the following factors:
the →target system itself,
the compiler used for the target system and
the configured optimization flags for the compiler.
Do not use blocks/variables with LREAL for Controllino or Arduino Nano
If you create an application for a →Controllino or an →Arduino Nano, avoid the usage of blocks/variables processing/returning LREAL values. The usage of such blocks/variables is possible but the LREAL values are processed with the accuracy of REAL values.
Observe that the DIV_TIME block is internally always using LREAL values.
Behavior of convert blocks in case of a range of values not overlapping
TRUNC blocks and other convert functions with a REAL/LREAL input might return different results for different compilers and on different target system s as well, if the connected value is not within the range of values overlapping for the data type of the input and for the data type of the return value . These different results are caused by the following factors:
the compiler used for the target system and
the →target system itself
Therefore, enter code in your application to detect when the range of values is not overlapping (e.g. IF-statements
in the ST-code). See under "Convert functions" and "ConvertEnh functions" which of the convert functions provide a REAL/LREAL input.
Known examples:
Target system |
Result of the mathematical function TRUNC_DINT(REAL#3.402823466e+38); |
→logi.RTS for Windows |
-2147483648 |
2147483647 |
|
RTOS32 compiler |
-2147483648 |
The RTOS32 compiler reports an error in case of a specific division.
If you are using the RTOS32 compiler, avoid a specific division (see the following example) in your application.
PROGRAM Program1
DIV(DINT#-2_147_483_648, DINT#-1);
END_PROGRAM
When building the application, the compilers report the expected warning overflow in constant division, undefined behavior. But the RTOS32 compiler also reports an error divide or mod by zero. Other compilers do accept the code – only the mentioned warning is reported. To avoid the reporting of the error when using the RTOS32 compiler, do not use a division with the above-mentioned negative integers.