Restrictions

The boot project must be loadable and executable on both controllers. A seamless update of the runtime system with different versions of these runtime systems is made possible by a feature from the CODESYS Redundancy Configuration add-on.

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

Exactly one task (the redundancy task) is synchronized with the functionality of the CODESYS Redundancy Configuration add-on. Other tasks and applications are possible, but they run unsynchronized on the 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. The communication link used for this purpose should be used exclusively for redundant communication.

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.

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 name of the redundant application or redundant task is a significant change and is not possible during redundant mode. After such a change, both PLCs must be reconfigured. As described in the Getting Started section (under "Configuring the redundancy system").

The timeout value which you specify must be greater than the sum of the task jitter time and the maximum communication jitter time.

Both times are system-specific. Both features – real-time tasks and real-time communication – are needed to specify a specific maximum timeout. 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.

In the Redundancy Configuration editor, on the Redundancy Settings tab, on the General tab, you define the timeout which switches the active PLC to standalone mode.

Moreover, the value is stored in the runtime configuration file (example: CODESYSControl.cfg) with the entry StandbyWaitTime.

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.

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">

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.

For more information, see the following: Task and communication in real time

The I/O mapping method "Map on Existing” (mapping I/Os to existing variables) is not recommended when using the CODESYS Redundancy Configuration add-on. 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 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 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 the respective file handles in the data areas which are not subjected to redundancy control. Each PLC opens its files independently of each other. A shared handle is not supported. A file handle created on a PLC must not be used to access files on the other PLC or on files on the local PC.

When compiling, the system 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.

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.

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