My first post at the site and it has to be regarding admission to the "DOH" dept. However, it just goes to show that no matter how careful and thorough you are, sometimes things come back to bite you.
8 years ago I did a job in one of the largest office towers in Sydney (Ozz) for the Canucks). 3 x 1.5mW generators, capacity control, load control, automatic dummy load control to keep the generators loaded between 50 & 60%, etc etc.
Several scenarios of power failure to start the generators and change individual floors over to emergency power.
1) Single floor failure.
2) Sub failure (2 subs in building).
3) Multiple floor failure.
Sub failure works very well and there has never been a glitch since commissioning the system.
Single floor failure has always worked very well and the code for this is incorporated in multiple floor failure mode to cut down on code.
Recently, a circuit breaker failed cutting power to 7 floors fed from the same riser. The generators started, capacity control worked perfectly, dummy load control worked perfectly but none of the floors turned on. Panic stations and relays were set to power the floors. Could not find the problem and suspected a netwotk problem. 10 year old fairly basic network.
Since then several floors have been vacated and today we were able to do some controlled testing to determine where the problem lay, or if it still existed.
In the case of several floor failures, I use a bit counter in the software to determine a failure and start the sets. I then used an XOR function to indicate that there are floors that had suffered a power failure and have not yet received generator power. The plan is to load risers at the same rate and in parallel so I then added the result or the XOR functions together to start a pair of timers to operate shift registers to turn on generator power to the floors.
Normally, there is a single floor failure or sub failure and so the situation of 4 contigious floors failed on the same riser had never arisen before. Today we failed 4 floors together by turning off a circuit breaker. The 4 least significant bits in a channel turned on. XOR worked perfectly as I had a value in the result channel. Looked at the ADD function and it was not adding. Consequently the compare function had nothing to compare.
"DOH"
Had used a BCD add instead of binary add. The 4 least significant bits = "F". BCD add would not recognise it. Changed to binary add and all is now well.
I am very annoyed with myself for missing this in the initial code. I am also extremely surprised that in 8 years this situation has never arisen. Testing is done regularly where single unoccupied floors are failed. Because the building manager walks between floors to operate circuit breakers to simulate a power failure, the previous floor has already turned on before he gets to the next floor so A, B, C, D, E & F have never previously occurred to trip up the software.
I wonder how many other similar stories are out there. Come on, I'm game if you are. One thing is for sure, I will never do that again.
beerchug
8 years ago I did a job in one of the largest office towers in Sydney (Ozz) for the Canucks). 3 x 1.5mW generators, capacity control, load control, automatic dummy load control to keep the generators loaded between 50 & 60%, etc etc.
Several scenarios of power failure to start the generators and change individual floors over to emergency power.
1) Single floor failure.
2) Sub failure (2 subs in building).
3) Multiple floor failure.
Sub failure works very well and there has never been a glitch since commissioning the system.
Single floor failure has always worked very well and the code for this is incorporated in multiple floor failure mode to cut down on code.
Recently, a circuit breaker failed cutting power to 7 floors fed from the same riser. The generators started, capacity control worked perfectly, dummy load control worked perfectly but none of the floors turned on. Panic stations and relays were set to power the floors. Could not find the problem and suspected a netwotk problem. 10 year old fairly basic network.
Since then several floors have been vacated and today we were able to do some controlled testing to determine where the problem lay, or if it still existed.
In the case of several floor failures, I use a bit counter in the software to determine a failure and start the sets. I then used an XOR function to indicate that there are floors that had suffered a power failure and have not yet received generator power. The plan is to load risers at the same rate and in parallel so I then added the result or the XOR functions together to start a pair of timers to operate shift registers to turn on generator power to the floors.
Normally, there is a single floor failure or sub failure and so the situation of 4 contigious floors failed on the same riser had never arisen before. Today we failed 4 floors together by turning off a circuit breaker. The 4 least significant bits in a channel turned on. XOR worked perfectly as I had a value in the result channel. Looked at the ADD function and it was not adding. Consequently the compare function had nothing to compare.
"DOH"
Had used a BCD add instead of binary add. The 4 least significant bits = "F". BCD add would not recognise it. Changed to binary add and all is now well.
I am very annoyed with myself for missing this in the initial code. I am also extremely surprised that in 8 years this situation has never arisen. Testing is done regularly where single unoccupied floors are failed. Because the building manager walks between floors to operate circuit breakers to simulate a power failure, the previous floor has already turned on before he gets to the next floor so A, B, C, D, E & F have never previously occurred to trip up the software.
I wonder how many other similar stories are out there. Come on, I'm game if you are. One thing is for sure, I will never do that again.
beerchug
