AC900F Modbus TCP Reconnect delay after CPU switchover
we configured redundant AC900F to a redundant Modbus TCP slave using a switch in the middle allowing for all possible communications (master PRI - Slave PRI; PRI-SEC, SEC-PRI and SEC-SEC)
The redundancy handover works fine when a single cable is dropped, but in case I drop the connection to the primary slave and then to the active CPU, the new active CPU occasionally needs ca 50s to detect, which slave is available and to re-establish communication.
Same happens when I use a 'parallel redundancy': Master PRI - Slave PRI and Master SEC - Slave SEC, each exclusive connections: Occasionally the reconnect needs up to 60s
The CPUs are correctly configured as redundant CPU, same for the application. The MODTCP_M object holds two IP Adresses for the both slaves.
Is it a known behavior?
Thanks for help, Ulrich
With regards to the switchover time of a redundant Freelance controller, the typical time lies between 350 and 400 ms if you press the toggle button. Freelance has a warm standby redundancy where the backup controller does not actively calculate the application in parallel to the primary controller but gets the inner state of the primary's application and all the output values with each task cycle as well as all parameter changes or downloads to the primary. The 350 - 400 are needed to start the application and wait for the first read of the inputs (in the case of PROFIBUS for example)
In case of an error activated switch over you have the additional time of detecting the error.
The timeout for Modbus TCP is set to 15 seconds by default. In that case, it takes already 15 seconds to detect a fault in the primary slave via the time out in the master. If you use the first timeout to toggle the redundant controller with your application the new primary will first try to establish communication with the primary slave address first. The new controller waits max 300 ms for the first read cycle before it starts the application. But because the primary slave is off, the application will start using initial values for the inputs. At this point, your switching application would try to switch back to the old primary controller in case you have not prevented that. If you prevented the switchback it takes another 15 seconds to detect that the primary slave is off. So 30+ seconds are over. Then the connection to the second Slave address is established provided that the backup communication at the slave is active.
The timing depends on your switching application (what signals does it use and does it have an internal waiting time...) and the slave's behaviour with regards to activating the second interface.