Fail over of CI871 module using BC810 issues
I am currently working on a system with a new redundant pair of 866 controllers that use the BC810 as well as CI871 for Profinet IO connections. Running through some redundancy checks I saw what I would assume is strange behaviour for fail over and recovery of the CI871 and was hoping somebody here with more experience might be able to shed light on the situation.
The setup has CPU A with CI871 in slot 1 and CPU B with CI871 in slot 7. At the start of the redundancy checks, CPU A is acting as primary and CI871 in slot 1 is also acting as primary. We have powered down the network switch connected to CI871 in slot 1 and it appeared that CPU A remains as primary and is immediately switching to use CI871 in slot 7 as primary with no loss in communication. However, when power is returned to the switch after a short delay, there is a brief moment when Control Builder M shows Profinet I/O in the failed state and all module icons on graphics appear to display the bad status indication. This lasts for only a few seconds before the I/O recovers. After recovery, when I check the hardware, I see that the CI871 in slot 7 is primary and CPU A is still primary.
To me, it seems that there is a brief time when connection is recognized in CI871 in slot 1 but not fully established and the CPU A begins using that card (producing the failed I/O state) before swapping back to the CI871 in slot 7. Is there a place where I can change the amount of time needed to pass before a CPU tries to use the hardware connected to it instead of the hardware across the BC810? Or is there a way that I can set it to just continue reading across the CEX-bus until there is a failure on that side instead of trying to retake primary status with its own card?
The setup has CPU A with CI871 in slot 1 and CPU B with CI871 in slot 7. At the start of the redundancy checks, CPU A is acting as primary and CI871 in slot 1 is also acting as primary. We have powered down the network switch connected to CI871 in slot 1 and it appeared that CPU A remains as primary and is immediately switching to use CI871 in slot 7 as primary with no loss in communication. However, when power is returned to the switch after a short delay, there is a brief moment when Control Builder M shows Profinet I/O in the failed state and all module icons on graphics appear to display the bad status indication. This lasts for only a few seconds before the I/O recovers. After recovery, when I check the hardware, I see that the CI871 in slot 7 is primary and CPU A is still primary.
To me, it seems that there is a brief time when connection is recognized in CI871 in slot 1 but not fully established and the CPU A begins using that card (producing the failed I/O state) before swapping back to the CI871 in slot 7. Is there a place where I can change the amount of time needed to pass before a CPU tries to use the hardware connected to it instead of the hardware across the BC810? Or is there a way that I can set it to just continue reading across the CEX-bus until there is a failure on that side instead of trying to retake primary status with its own card?
Asked 1 month ago
Answers
0
Hello
We can customise switch over of slave modules by enabling Web server.
We can find settings related to switch over and redundancy.
Please try this in test set up so that we can trace out the real impact on redundancy as well as Controller.
In running system this is not recommended.
We can customise switch over of slave modules by enabling Web server.
We can find settings related to switch over and redundancy.
Please try this in test set up so that we can trace out the real impact on redundancy as well as Controller.
In running system this is not recommended.
Add new comment