For a balanced performance of the HA system consider the following recommendations in your project task configuration:
General
-
Use the real time priorities for all HA related tasks. The HA program/ task should be called at highest priority as it is responsible for the core HA functionality and should be the fastest task.
-
The Modbus task contains the Modbus communication function blocks at lower priority and (depending on CPU performance) also a faster cycle time to ensure sufficient update rates on Modbus without over- loading the CPU with communication.
-
The application program parts should be called in the application task with even lower priority and a larger cycle time than above tasks.
-
Configuration to improve standard Modbus TCP for a fast switch over between PLCs.
-
RTO retransmission time function block “EthSetRtoMin” for the ETH port where fieldbus communication is configured. By default, minimum retransmission time configured is 15 ms.
|
Task |
Priority |
PM57x, PM58x, PM59x |
PM595-4ETH |
V3 PLCs |
|---|---|---|---|---|
|
HA |
10 (high) |
4 ms or higher |
2 ms or higher |
4 ms or higher |
|
Modbus |
11 (medium) |
Maximum of (HA cycle time *2), (3 ms + roundup (#CI/2)) |
Maximum of (HA cycle time *2), (3 ms + roundup (#CI/2)) |
Onboard ETH: Max ((HA cycle time *2), (3 + roundup (#CI modules/2))) |
|
CM5640-2ETH: Max ((HA cycle time * 2), (#CI modules)) |
||||
|
Application |
12 (low) |
Maximum of (Modbus cycle time *2), (iNoOfEthFrames * HA cycle time) |
(iNoOfEthFrames * HA cycle time) |
Maximum of (Modbus cycle time *2), (iNoOfEthFrames * HA cycle time *2) |
Procedure for task configuration
-
Choose suitable CPU type according to chapter CPU choice, system size, performance indications
-
Configure task priorities according to the table
-
Set HA task to minimum according to above table
-
Calculate Modbus cycle time according formulas in the table, based on HA cycle and number of CI modules “#CI”
-
Calculate Application cycle time according to formulas in the table, based on Modbus cycle time and variable iNoOfEthFrames, which is defined in the global variables of HA-Modbus TCP library.
-
Measure PLC and CPU load during trial operation.
V3: PLC Utilisation⮫ “PLC utilization”
If the PLC load is higher than 40 % or CPU load higher than 60 % then increase HA cycle time (e.g. to 8 ms / 12 ms / 24 ms, …) and go to step 4, repeat the steps until loading is within defined range.
A new V3 CPU configuration option is introduced from Automation Builder 2.4.1 and onwards which allows to change the priority for Ethernet communication in PLCs.
Set this configuration in the device tree of the CPU in Automation Builder double click on PLC “CPU Parameters Communication Schema Select “Onboard Ethernet””.
The above parameter should be set to “Onboard” Ethernet for HA systems and it will consequently increase the loading due to the higher priority. PLC Load < 50 % and CPU load < 70 % should be considered as guidelines here instead, while setting the task times while setting the task times.
-
Following timeout values has to be defined in the user project according to the relation defined.
Timeout variables (see definitions in box below table)
HA in V2
HA in V3
timCI52xTimeOut
1 * Modbus Task time
50 ms or 2 * Modbus Task time, whichever is higher
timHaModSyncTimeOut
1* HA Task time
2 * HA Task time
timResponseTimeout
Not applicable
50ms or (3 * “Modbus Task time”), whichever is higher
timCanTimeOut
Not applicable
100 ms or increase in multiple of 100
timeLifecom2TimeOut
50 ms
50 ms
timDualSyncPingTimeout
100 ms
100 ms
-
Add additional applications and SCADA communication: Check PLC and CPU load again vs. your requirements.
In the HA Modbus system different timeouts must be configured for the fine operation of the system as described above in the task configuration for V2 and V3 PLCs. These different timeouts meaning, and relation is explained below:
timHaModSyncTimeOut:
Time limit to check if the new sync data is received or not in the secondary PLC. If this timeout is not defined properly, Sync lost error/ “lifecom1” lost error will be generated.
timCanTimeOut:
Time used for the check whether “lifecom2” is received when configured via CAN. This value is applicable only in AC500 V3. Lifecom2 via CAN won’t be stable between the PLCs and runtime error "lifecom2 lost" will be flickering if not the right value is configured.
timCI52xTimeOut:
Time limit to check whether new data is received in the Modbus field modules. It is also used to check whether “lifecom2” is received when configured via Modbus TCP. If “timCI52xTimeOut” is not defined as described, “lifecom2” error / communication interface diagnosis error will not be generated as expected.
timResponseTimeOut:
Timeout value to check whether CPU has lost the communication interface modules connected in the network. If this value is not defined as described, communication interface module lost detection will not be indicated properly.
timLifecom2TimeOut
Time limit to check whether “lifecom2” is received when configured via Modbus TCP. Set “timlifecom2TimeOut” value to default 50 ms, if the value is not defined correctly, runtime error “Lifecom2 lost” diagnosis error will not be generated as expected.
timDualSyncPingTimeout
Time limit to check whether “lifecom2” is received when configured via Modbus TCP. Set “timlifecom2TimeOut” value to default 50 ms, if the value is not defined correctly, runtime error “Lifecom2 lost” diagnosis error will not be generated as expected.
Dual sync ping timeout which defines the timeout to receive ping reply from another PLC . If “timDualSyncPingTimeout” is not defined properly, runtime error “Sync along with Lifecom1 is stopped and Sync is activated with Lifecom2” diagnosis error will not be generated as expected. This timeout is required only if Dual sync feature is enabled, Global variable “xEnableDualSync” is set to TRUE