PM861A Redundancy Testing Procedure
We are facing one issue with PM861A Controller.While doing
CPU redundancy test, change over is happening
successfully, after change over controller is going to fault
state.
We are supplying two controller PM861A & PM861A to customer.
Redundancy Testing Procedure:
1. Primary controller become primary
1. Check both Controllers are on ,OK & DUAL LED is ON.
3. Switch off Primary controller
4. Secondary controller will become primary
5. Switch on the Primary controller again and Check both Controllers are on ,OK & DUAL LED is ON.
6. Switch off Secondary controller
7. Primary controller will become primary again
8. Switch on the Secondary controller again and waiting to check DUAL LED , the Fault LED become red and and the DUAL LED is OFF.
Asked 1 month ago
Voted best answer
1
Hi,
Is the scenario (secondary controller coming in fault mode) is repetitive in nature ?
Boot secondary controller again once or twice.
If problem persists, try changing your BC810 of secondary controller and RCU Link cable.
Are these new controllers?
Can you share your controller logs ?
Also you can contact regional ABB support.
Is the scenario (secondary controller coming in fault mode) is repetitive in nature ?
Boot secondary controller again once or twice.
If problem persists, try changing your BC810 of secondary controller and RCU Link cable.
Are these new controllers?
Can you share your controller logs ?
Also you can contact regional ABB support.
Answered 1 month ago
Answers
1
Refer Product Bulletin:
Different Behaviour from PM861A and PM864A during test or demo of redundancy.
Products Concerned 800xA – Control and I/O AC 800M Controller Hardware - PM861AK01 Part no: 3BSE018157R1, PR:F - PM861AK02 Part no: 3BSE018160R1, PR:F - PM864AK01 Part no: 3BSE018161R1, PR:F - PM864AK02 Part no: 3BSE018164R1, PR:F Product Issue Number NA Description If a module is running in redundant synchronized mode as primary and has internal or external battery backup connected and is subject to power removal, which is a very common way to demonstrate the HW-redundancy, the normal and expected switch-over to the synchronized partner will occur in correct order. If, however, the former primary is powered on again, in order to have it up and running as a synchronized backup, the first start attempt will fail but succeeding attempts will work. Why isn’t this an availability/quality issue? In state of normal run a halted former primary CPU will remain in error state and is supposed to be replaced, because a HW fault is assumed. Why isn’t this an availability/security issue? The controller maintains its task in single mode until a new backup is started. As stated above we are fully aware that the mentioned operational sequence is often used as a demo and during test. The behavior was not intentionally changed and will be adjusted in the next hardware revision to support the mentioned test sequence . It should also be added that the behavior is the same if INIT pushbutton is used to stop the current primary. When CompactFlash cards are inserted in both controller CPU:s the former primary CPU will startup after the first power up in the mentioned scenario.
Corrective Action or Resolution The behaviour is adjusted from the next HW product revision to ensure that the former backup CPU boots up on the first power up in the mentioned scenario Workarounds: 1. Make sure that a CompactFlash card is inserted in both controller CPU:s, with CF-cars inserted the behavior will be as usual. 2. During demo or test with power cycling, and no CF-cards available remove or disconnect battery backup. Without battery backup the behavior will be as usual. 3. When the INIT-pushbutton is used for this purpose, and no CF-Cards available, the workaround is to do a second push on the former primary. Note: During normal run the battery backup should be inserted/connected as configured in the first place. Remember: The deviating behaviour does not by any means affect the availability of the controller,
Different Behaviour from PM861A and PM864A during test or demo of redundancy.
Products Concerned 800xA – Control and I/O AC 800M Controller Hardware - PM861AK01 Part no: 3BSE018157R1, PR:F - PM861AK02 Part no: 3BSE018160R1, PR:F - PM864AK01 Part no: 3BSE018161R1, PR:F - PM864AK02 Part no: 3BSE018164R1, PR:F Product Issue Number NA Description If a module is running in redundant synchronized mode as primary and has internal or external battery backup connected and is subject to power removal, which is a very common way to demonstrate the HW-redundancy, the normal and expected switch-over to the synchronized partner will occur in correct order. If, however, the former primary is powered on again, in order to have it up and running as a synchronized backup, the first start attempt will fail but succeeding attempts will work. Why isn’t this an availability/quality issue? In state of normal run a halted former primary CPU will remain in error state and is supposed to be replaced, because a HW fault is assumed. Why isn’t this an availability/security issue? The controller maintains its task in single mode until a new backup is started. As stated above we are fully aware that the mentioned operational sequence is often used as a demo and during test. The behavior was not intentionally changed and will be adjusted in the next hardware revision to support the mentioned test sequence . It should also be added that the behavior is the same if INIT pushbutton is used to stop the current primary. When CompactFlash cards are inserted in both controller CPU:s the former primary CPU will startup after the first power up in the mentioned scenario.
Corrective Action or Resolution The behaviour is adjusted from the next HW product revision to ensure that the former backup CPU boots up on the first power up in the mentioned scenario Workarounds: 1. Make sure that a CompactFlash card is inserted in both controller CPU:s, with CF-cars inserted the behavior will be as usual. 2. During demo or test with power cycling, and no CF-cards available remove or disconnect battery backup. Without battery backup the behavior will be as usual. 3. When the INIT-pushbutton is used for this purpose, and no CF-Cards available, the workaround is to do a second push on the former primary. Note: During normal run the battery backup should be inserted/connected as configured in the first place. Remember: The deviating behaviour does not by any means affect the availability of the controller,
Answered 1 month ago
Add new comment