Observe that the used →target system influences the usage of logi.CAD 3 in the following aspects:

This article is valid for target systems for which you are able to load applications in all variants of logi.CAD 3. Therefore, target systems here listed might not be supported for your extended version of logi.CAD 3.

Scheduling priority of POUs

The priority of a task can be used for controlling the preemptive or non-preemptive scheduling of →POUs – according to the →IEC-standard. However, the target systems supported by logi.CAD 3 allow just the preemptive scheduling. In pre-emptive scheduling, when a POU is scheduled, it can interrupt the execution of a POU of lower priority on the same resource, that is, the execution of the lower-priority unit can be suspended until the execution of the higher-priority unit is completed. A POU must not interrupt the execution of another unit of the same or higher priority.

See under Declaring more tasks within PLC-object how to define priorities for different tasks.

Controllino and Arduino Nano allow just the non-preemptive scheduling. However, this fact is not relevant for the scheduling priority of POUs as only one task is supported for Controllino and Arduino Nano (see below).

Influence of the scheduling priority onto Linux-based target systems

Linux-based target systems are: →phyBOARD-Regor, →phyBOARD-Wega, →Raspberry Pi, →Revolution Pi and when using the platform LinuxX86

These target systems support different types of →tasks:

Real-time tasks (tasks = threads; see the following note) – Such tasks must have a short execution time. Of course, this execution time depends on the content of the appropriate program.
If this execution time exceeds the value determined by the operating system, the operating system automatically interrupts the execution of all real-time tasks. This mechanism is also known as real-time throttling. Due to the interruption, the task is no longer a real-time task.
A common setting for the real-time throttling is an interruption of 50 ms within one second.
Non real-time tasks

Note: Usually, the tasks created within logi.CAD 3 are generated as real-time operating system threads. Exceptions are the tasks created with the lowest priority 65535. These tasks are generated as non real-time operating system threads

Endian format of data

All target systems supported by logi.CAD 3 save the data in little →endian format. If you need data in big-endian format, use the appropriate convert functions.

Accuracies of the mathematical functions

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);`
→Runtime system for Windows	`-2147483648`
→Raspberry Pi	`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.

Example for ST-code

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.

Resources, tasks, program instances: maximum number

Target system	Elements within a PLC-object
	→Resources	→Tasks	Program instances
Built-in PLC	1	max. 32	any⁽¹⁾
Windows NT/X86	1	max. 32	any⁽¹⁾
Linux-based target systems: →phyBOARD-Regor, →phyBOARD-Wega, →Raspberry Pi, →Revolution Pi and when using the platform `LinuxX86`	1	max. 32	any⁽¹⁾
→Controllino or →Arduino Nano	1	1	1

Note:

⁽¹⁾ = restricted by the memory capacity of the PLC

Memory for STRING values

The memory that is available for STRING values is restricted to 1,024 bytes. Exception: In case of Controllino or Arduino Nano, the memory is restricted to 64 bytes.

This restriction affects blocks with STRING values (e.g. string blocks), if there is a nested usage of them in the application. Observe that 1 byte of the memory is used for internal purpose. See "In case of nested string blocks: How can the return value be entirely mapped ?" for more information and examples.
Consequence: It is possible for a Controllino and an Arduino Nano that the output ENO of these blocks is set "earlier" to value FALSE (or an equivalent) – in contrast to the other target systems.

Duration literals

→Duration literals (e.g. TIME#14ms) are mapped correctly on the →PLC, if these literals are within the timer frequency valid for the PLC.

Target system	Timer frequency	Smallest possible value in duration literal⁽¹⁾
→Runtime system for Windows	10 kHz	100 us
Linux-based target systems: →phyBOARD-Regor, →phyBOARD-Wega, →Raspberry Pi, →Revolution Pi and when using the platform `LinuxX86`	1 MHz	1 us
Controllino	1 kHz	1 ms
Arduino Nano	1 kHz	1 ms

Other values for duration literals and values for variables (e.g. within the ST-editor) are possible within logi.CAD 3 but they are rounded down to the next multiple of the smallest possible value. The Values of Variables view will display the values correspondingly.
Example: The duration literal t#12h4m34ms230us400ns is rounded down to t#12h4m34ms200us with logi.RTS for Windows and processed correspondingly.

Time literals

logi.RTS stores the data types TIME, DATE, TIME_OF_DAY and DATE_AND_TIME as a signed 64-bit long integer data type in the form of "ticks". The number of ticks per time unit (1 second) depends on the timer frequency of the target-system platform (see the previous table). Subsequently, the range of values for the data types TIME, DATE, TIME_OF_DAY and DATE_AND_TIME on the PLC is outside the limits that can be processed by logi.CAD 3. Therefore, if you enter →time literals within logi.CAD 3, the lower and upper limits for logi.CAD 3 apply (see Supported data types (in ST)).

Timing scheduling of the target systems

An application is executed periodically based on the defined duration literal for the task (= cycle time). The used target system influences the timing scheduling as follows:

For the execution, the cycle time is rounded down to a multiple of the default timer resolution. This rounded value is used as interval for the execution. Mind that the cycles of the application start at a multiple of the default timer resolution.
The default timer resolution is equal to the minimum cycle time.
The default timer resolution depends on the target system:

Target system	Default timer resolution
logi.RTS for Windows	1 ms
Arduino Nano	1 ms
Controllino	1 ms
Linux-based target systems: →phyBOARD-Regor, →phyBOARD-Wega, →Raspberry Pi, →Revolution Pi and when using the platform `LinuxX86`	500 us

Example: In case of a defined cycle time TIME#3.3ms, the interval for the execution is the following:

TIME#3ms for a Windows computer – Subsequently, the cycles of the application start at a multiple of TIME#3ms.
TIME#3.25ms for a Raspberry Pi – Subsequently, the cycles of the application start at a multiple of TIME#3.25ms.

If an application is executed (see "3rd execution" in the following illustrations) until the next interval has already begun, the target system influences the starting time of the next execution.
In case of the following target systems, the next execution is started when the interval after this one begins (see "4th execution"). Hence, one interval is skipped. Following intervals and applications (see "5th execution") are not delayed.
- logi.RTS for Windows
- logi.RTS for Linux x86
- Arduino Nano
- Controllino
- Revolution Pi
- Raspberry Pi