Restrictions

CODESYS version

The same version of the runtime system has to be installed on both devices because the boot project is transferred between the PLCs and therefore has to be loadable on the second PLC.

Task and communication in real time

Only cyclical tasks are permitted. Tasks of type Event, Status, or Freewheeling cannot be synchronized.

The CODESYS Redundancy functionality synchronizes exactly one task (Redundancy Task). Other tasks and applications are possible, but they run non-synchronized on both PLCs.

Moreover, the redundancy system which affects the task execution and communication has to fulfill certain real-time demands: The runtime of the messages (request and response) of the redundancy communication has to exist within a previously defined time interval and the task jitter has to be considered.

Real-time task execution means that the application task that is controlled by redundancy has a limited jitter. Real-time communication means that a message that is sent by means of the redundancy linking has to be received by the other PLC within a specific time.

Task execution time

The messaging duration (time for request and response) increases the execution time of the task: the total execution time of the task is longer when redundancy is used.

Changing the names of the application and the task

Changing the names of the redundant application or the redundant task is a significant change and is not possible during redundant mode. This is because, after a change, you need to reconfigure both PLCs as described in "Getting Started" under "Configuring the redundancy system".

Value for timeout

The value which you specify for the timeout has to be greater than the sum of the task jitter time and the maximum communication jitter time. Both times are system-specific. At runtime, when the task jitter is high and the message transfer is delayed, a timeout occurs. While waiting for a message from the other PLC, the system assumes that the other PLC is not running anymore. As a result, the waiting PLC and the sending PLC switch to standalone mode. That leads to synchronization losses and to communication problems on the fieldbus.

IEC timer

Different execution times on both PLCs can cause "bumps" (deviating output values) when switching PLCs. To prevent this, the IEC timer values are frozen during the execution of an IEC task. Calls from IEC timers (example: the function TON) when executing an IEC task therefore always lead to the same timer values, even if the physical time continues to run. Therefore, implementations should wait inactively (possibly in a loop). This is because IEC timer values do not change in the current task scan.

Pointers, References, and Interfaces

The POINTER TO, REFERENCE TO, and INTERFACE statements (and interface instances) for expressing relationships between application units do not work with synchronized redundant applications.

POINTER variables must not be declared in data areas that are controlled by redundancy. This is because redundantly controlled data is transmitted to the other PLC during synchronization. However, pointers are not valid on the other PLC because another memory layout may be located there.

When compiling, the redundancy feature checks that a pointer is located in a redundantly controlled area. A warning is displayed for each pointer found there. The check can be deactivated in the device description file with the following entry:

<Device>
    <Custom>
            <Redundancy DisablePointerChecks="true">

EtherCAT DC

This redundancy extension is intended more for the process industry than for factory automation. For this reason, EtherCAT drives with distributed clocks are not supported. However, EtherCAT I/Os are supported.

See also the section "Task and communication in real time" above.

"Map on Existing": Mapping to existing variables

The I/O mapping method "Map on Existing” (mapping I/Os to existing variables) is not recommended for use with CODESYS Redundancy. These kinds of variables are not stored in the input or output data areas, but where they are declared. As a result, they are not synchronized during operation.

Network variables

Network variables with write access must not be used because multiple write telegrams are sent at the same time. Network variables with read access are permitted.

File access

File access must not be used because different file data can cause "bumps" on the different PLCs when they are switched.

If you use files, then you need to declare file handles in the data areas which are not subjected to redundancy control. The files have to be opened separately on both PLCs. The file handle of another PLC must not be used to access files on the local PC.

When compiling, CODESYS Redundancy checks that handle variables (RTS_IEC_HANDLE, CAA.HANDLE) are located in a redundantly controlled area. A warning is issued for each handle variable which is detected in such an area.

Online security user management

If an online security user management is used, then you need to configure both PLCs with the same user name and password. Otherwise, online services such as write variable or online change are not transmitted to the standby PLC.

SoftMotion

CODESYS SoftMotion and CODESYS Redundancy cannot be combined. The time demands of SoftMotion cannot be fulfilled when using redundancy.