Infinite loops as well as missing abort conditions are not identified by logi.CAD 3. Provide correct abort conditions (e.g. by using IF-statements) to prevent infinite loops.

Recursions for →functions and →methods are not forbidden or checked by logi.CAD 3 . Nevertheless, do not call a function/method from within itself and avoid 2 (or more) functions/methods calling each other (= mutual recursion) within your application.
Mind that recursions of functions/methods might cause unexpected results when your application is executed. For example, the application might be executed in an infinite loop and/or the →runtime system might not respond anymore.

If you are using not-unique names in the →C code and they are available in the global namespace, conflicts might be caused when using several blocks with such C code. However, these conflicts may not cause errors/warnings when building the application. As a result, the runtime behavior might be affected in an undesirable way.
Example: The Values of Variables view displays 2 variables to which the return value of POU1 an POU2 respectively has been assigned. The value for Program1.rc2 displays the unexpected value 1 while the value 2 is actually assigned in the C-code. The problem is caused due to the same name RESULT within the C-code of the 2 vendor blocks POU1 and POU2.

Additional information: This problem is valid for:

• →vendor blocks that you have created

• vendor blocks that have been created when importing a Simulink model

• vendor blocks that have been created when migrating from the predecessor product logi.CAD/32 to logi.CAD 3

• blocks with C-/C++-code that you created based on an ST-interface (see "Creating the interface for a C-block or C++-block (deprecated)")

Workaround 1: Use POU-unique names (when possible, project- and POU-unique) for all C-identifiers that are available in a global namespace. If you are importing a Simulink model, the best practice is to use the unique names already in the Simulink model.
Workaround for the above example: Now the Values of Variables view displays the expected value 2 for Program1.rc2 because POU-unique names have been used within the C-code.

Workaround 2: If you provide the blocks with C-code in a library, specify the blocks in the library configuration with DEPLOY:=OBJECT (see under " Declaration of the contents of the library " for details on DEPLOY:=OBJECT ). As a result, the binary code for the POU is built separately when the library is created.

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.

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.