Hi everyone.
At our plant we have two frame 6B GE turbines which is controlled/protected by a Mark VI.
The architecture is pretty standard, supplied by GE, and consists of three Racks (R, S and T) which performs 2oo3 voting to increase availability without letting go of safety.
After every turnaround or even after a minor turbine "pitstop", in addition to the usual diagnostics evaluation and hardware checks, we also perform a redundancy test as soon as the turbine comes back to operation. This test consists of:
1) Normal procedure to start the turbine
2) Wait until it gets to FSNL
3) Turn off Rack R (switch off the Rack R power supply) and check if the turbine keeps running with only racks S and T.
4) If no trip occurs, restabilish Rack R, wait some minutes after it achieves appropriate control state, and repeat the procedure to racks S
5) Repeat step 4 for rack T
Obviously, before starting the test you have to make sure there isn't already a problem with some 2oo3 logic points at R, S or T, because if you already have one problem and switch off a second rack, definitely there will be a trip.
Well, this test goes pretty well with one of our 6B, no trip occurs. However, the other 6B is tripping when rack R is powered off. It does not happen when S or T are powered off, but only when Rack R is. That indicates that it is not a 2oo3 redundancy problem, because we would have to have a trip when powering off S or T also (for example, if there is a 2oo3 voting issue with S, when shutting down S there would be no trip, but when shutting down R and T definitely there would be a trip).
Also, as the first cause indicated problem with GCV or SRV, we did another test at FSNL disconnecting rack R, S and T VSVO output points to the SRV and GCV (one each time) and that was no trip at all.
We couldn't perform more detailed tests this time because the turbine start was already late, and as these redundancy tests are last thing to be done, unfortunately it got postponed for next stop. Also, it does not jeopardize the turbine safety, only availability (worst case scenario we would get a safe trip).
Well, I'd be happy if you guys could share your experience with these kind of tests, and maybe suggest how to identify faster where the problem is. IMHO, the possibilities are:
1) The power supply of Rack R is wrongly being used to supply some vital point, or maybe to supply something that should be supplied from S or T (mistake at field connections).
2) Some Mark VI logic is operating as 1oo1 with a variable from Rack R. That is a logical but unpractical possibility. I also checked all Rack R single card points and could not find out anything like that.
At next stop, I'm thinking about to, instead of switching off Rack R, remove the cards cables one by one, so we would be able to narrow down the search. Do you have any other suggestions/ideas?
Thank you very much.
Kind regards,
RRA
At our plant we have two frame 6B GE turbines which is controlled/protected by a Mark VI.
The architecture is pretty standard, supplied by GE, and consists of three Racks (R, S and T) which performs 2oo3 voting to increase availability without letting go of safety.
After every turnaround or even after a minor turbine "pitstop", in addition to the usual diagnostics evaluation and hardware checks, we also perform a redundancy test as soon as the turbine comes back to operation. This test consists of:
1) Normal procedure to start the turbine
2) Wait until it gets to FSNL
3) Turn off Rack R (switch off the Rack R power supply) and check if the turbine keeps running with only racks S and T.
4) If no trip occurs, restabilish Rack R, wait some minutes after it achieves appropriate control state, and repeat the procedure to racks S
5) Repeat step 4 for rack T
Obviously, before starting the test you have to make sure there isn't already a problem with some 2oo3 logic points at R, S or T, because if you already have one problem and switch off a second rack, definitely there will be a trip.
Well, this test goes pretty well with one of our 6B, no trip occurs. However, the other 6B is tripping when rack R is powered off. It does not happen when S or T are powered off, but only when Rack R is. That indicates that it is not a 2oo3 redundancy problem, because we would have to have a trip when powering off S or T also (for example, if there is a 2oo3 voting issue with S, when shutting down S there would be no trip, but when shutting down R and T definitely there would be a trip).
Also, as the first cause indicated problem with GCV or SRV, we did another test at FSNL disconnecting rack R, S and T VSVO output points to the SRV and GCV (one each time) and that was no trip at all.
We couldn't perform more detailed tests this time because the turbine start was already late, and as these redundancy tests are last thing to be done, unfortunately it got postponed for next stop. Also, it does not jeopardize the turbine safety, only availability (worst case scenario we would get a safe trip).
Well, I'd be happy if you guys could share your experience with these kind of tests, and maybe suggest how to identify faster where the problem is. IMHO, the possibilities are:
1) The power supply of Rack R is wrongly being used to supply some vital point, or maybe to supply something that should be supplied from S or T (mistake at field connections).
2) Some Mark VI logic is operating as 1oo1 with a variable from Rack R. That is a logical but unpractical possibility. I also checked all Rack R single card points and could not find out anything like that.
At next stop, I'm thinking about to, instead of switching off Rack R, remove the cards cables one by one, so we would be able to narrow down the search. Do you have any other suggestions/ideas?
Thank you very much.
Kind regards,
RRA