The turbine was synched first time after the upgradtion of MarkV to MarkVIe control system. The turbine was running on Droop mode. It was decided to check the ISO mode and turbine was put on ISO mode. Number of things happened when the ISO command was given.
1. Turbine did not go into the ISO mode.
2. Turbine started to shed off the load.
3. Generator purging was shown on the HMI instead of ISO.
4. The ISO/Droop status of this machine (GT2) is shared with the other machine (GT1). The GT1 showed that the GT2 is still in droop mode.
The turbine was taken into to the droop mode again. It remained stable on the same load(after shedding the load). The logic for putting the turbine into ISO was different from MarkV (YES, this was an undocumented change). Some contacts were present which we were not even used anywhere. We decided to force those contacts to see the results. Again the ISO command was given and the results were same except the point number 4. This time the GT1 showed that the GT2 is in ISO mode.
There were no other process or diagnostic alarms present. What may be the causes of load shedding? What is meant by message "Generator purging"? What may be the possible causes of this message/mode of turbine?
Hydrogen-cooled generators are purged of hydrogen when hydrogen purity is very low, or there is no power for the hydrogen puruiy monitoring system or there is no AC power available for maintaining the hydrogen seal oil system pressure.
Have you let the GE commissioning field service person leave site?
The likely reason the Ststus_Field message is incorrect is because the signals used to cause the various Status_Fies messages are incorrect, in the incorrect order or the messages in the CIMPLICITY display configuration file are incorrect or in the incorrect order.
Usually, Isochronous Speed Control is not permitted unless the tie line breaker to the grid is open and the generator breaker is closed. There are often other permissives as well. It's NOT a good idea to enable Isochronous Speed Control mode if the unit is synchronized to a grid with other generators and their prime movers. Ever.
If you want to know why the load was being reduced you need to find out why L70L was a logic "1" which is what will drive TNR--and load--to decrease.
Isoch is not something to be tested when the unit is synchronized to a grid with other generators and their prime movers.
Logic Forcing is also not advisable as a general troubleshooting tool. Serious damage can be caused using Logic Forcing--even with the best of intentions.
Our generator is not hydrogen-cooled. We have checked the DPYSTAT1 block. The message "Generator Purging" is not even configured. We are amazed from where the Cimplicity is getting that message. That message even does not exist on EGD. We have checked the various status field messages by forcing when the turbine was shutdown. There was no discrepancy in the order.
The commissioning field service engineer is still on the site as commissioning is not complete yet.
I want to let you know that we are not connected to the National/Bigger grid. We are in Island mode. We have grid of our own turbines and this grid provides the electricity to our fertilizer plant only. Maybe I should not have chosen the word GRID for this scenario. So to maintain the frequency of our SMALL grid (which consist of 5 machines only), one of the turbine is always on ISO. So it was inevitable to test the ISO functionality after the upgradation. Is there anyway to check the ISO mode even without being connected to this smaller grid?
Yes, I have tried to dig into the L70L signal today. While working on that some questions came into my mind which are yet to be answered.
1. Suppose we are running on 10 MW load on droop mode. The turbine is connected to the grid with one machine running on ISO and rest are all on droop. Suppose (for simplicity) that the base load of turbine is 20 MW. So theoretically this turbine is at 50% load and its TNR is 102% while its TNH is 100.14%. What will happen if we put this machine on ISO? (The otherone which was on ISO before will be shifted to droop). On giving the signal of ISO the reference becomes TNRI which is 100% in our case. Other turbines on the grid have TNH of 100.14% while the reference of ISO turbine is 100%. This ISO machine will try to bring the whole grid down to 100% and it can only do so by lowering its speed(shedding load). Is my supposition correct? And what ideally is required that the machine should go to ISO and it should do so on the LOAD it was running before. It is possible as it was happening on MarkV, We have to figure how can we do it on MarkVIe.
2. Similarly if the turbine is at ISO at 10MW, how can we shift it to droop so that it should maintain the load of 10MW (or whatever load it was running on). How the TNR will be set when the MODE of turbine is changed?
These questions maybe very basic or even silly but I am having difficulty in understanding them.
Yes, I know your generator is not hydrogen-cooled. And, the messages that CIMPLICITY display come from the .CIM file configuration. So when the DPYSTASTn block enumerated data changes value, CIMPLICITY chooses the message to display from the messages configured for the item.
>Is there anyway to check the ISO mode even
>without being connected to this smaller grid?
You have to have some load to power; the generator breaker has to be closed.
I believe the signal that should go to a logic "1" when Isochronous Speed Control is enabled (selected by the operator AND all the permissives are satisfied) is L83SCI. So you need to find out what the permissives are for L83SCI, which will, indeed, make TNRI the reference instead of TNR.
I don't know if the SMALL grid (island) at your plant has some kind of "Power Management System" to control frequency and the loads of the units in response to some kind of "matrix" (which units should be loaded first, second, etc., and which units should be unloaded first, second, etc.) If the actual frequency is high, and this unit gets switched to Isoch, it should unload itself to bring the frequency "down." I believe the default Isoch speed control deadband is +/-0.17% (so between 99.83% and 100.17%), but sometimes plants make adjustments to that default deadband value.
BUT, I think that until the load changes to cause the frequency to go outside of the deadband (high or low) the Mark VIe unit will just hold it's load. And, the other units, in Droop Speed Control, should hold their loads, also. REMEMBER, though, that Droop Speed Control is all about the difference between the speed reference and the actual speed. So, as the actual speed changes so will the actual load (just slightly) which means the Isoch unit will also have to respond to these changes.
But, for the unit to actually control frequency by adjusting its load as required to maintain frequency, Isoch Speed Control needs to be active, and I believe the signal that says Isoch Speed Control is active is L83SCI. (That's the typical signal; your application code may vary.)
You are 100% correct--if it worked in the Mark V there's no reason it shouldn't work with the Mark VIe. The commissioning field service person should be working to compare the CSP to the application code to find out what the difference(s) is(are).
I think if L70L is actually a logic "1" when you think the unit is in Isoch Speed Control it may be because it's trying to make TNR track the load so that if governor mode is switched from Isoch to Droop there will be no load disturbance. I don't have access to any CSP or application code at this writing, so I can't offer any more than that at this time.
1. If the actual speed (frequency) is "100%" (that is, within the deadband), when the unit is switched from Droop to Isoch it will maintain its load until something happens to make the actual speed (frequency) go outside the deadband and then the Isoch unit will respond accordingly. The Droop units should basically hold their load, with some very small variations as the actual speed changes (their TNRs will NOT be changing--as long as there's no external load control system telling them to change loads!).
2. I believe the Mark VIe (and the Mark V) makes TNR track actual load--for a bumpless transfer when switched from Isoch to Droop.
I will try to get to a computer with a CSP or some app code tomorrow--and if I can have some time to review it I will have some more to say (possibly).
Transfers from Droop-to-Isoch and Isoch-to-Droop should be bumpless--there should be very little or no load change on the unit being switched (as long as the load is fairly stable). That's the idea, and I think you've said you've seen it work before the upgradation--so it should be possible after the upgradation.
Hope this helps!
We found the enumerated variable status_fld in ToolboxST (in software tab under variables. We used the search feature). When we clicked on the variable we found the enumerations information on the left side. DPYSTAST has 28 inputs. We are using only 24. Input 24 was for ISO status. Input was correct but in enumerations the message against input 24 was Generator_purging. Just AWFUL configuration. So atlast we were able to find from where Generator_purging was coming on the Cimplicity screen. We first tried to find the .cim configuration file. Lot of them were found in the screens folder but enumertions detail was not there in .cim in our case. We found it in ToolboxST.
>I believe the signal that should go to a logic "1" when
>Isochronous Speed Control is enabled (selected by the
>operator AND all the permissives are satisfied) is L83SCI.
Yes L83SCI is going to logic "1".
>So you need to find out what the permissives are for L83SCI,
>which will, indeed, make TNRI the reference instead of TNR.
I still have to find the block in which L83SCI or related signal makes TNRI the reference instead of TNR.
>I don't know if the SMALL grid (island) at your plant has
>some kind of "Power Management System" to control frequency
>and the loads of the units in response to some kind of
>"matrix" (which units should be loaded first, second, etc.,
>and which units should be unloaded first, second, etc.)
We do not have any kind of "Power Management System".
>If the actual frequency is high, and this unit gets switched to
>Isoch, it should unload itself to bring the frequency
>"down." I believe the default Isoch speed control deadband
>is +/-0.17% (so between 99.83% and 100.17%), but sometimes
>plants make adjustments to that default deadband value.
The actual frequency was a little bit higher. But it was in the deadband (+-0.17%). Shouldn't ISO mode select the actual frequency as its reference (if within its deadband)? I guess this is what we are missing. Only GUESS. When we put the turbine on ISO it gets the fixed TNRI. 100%. No change in TNRI whatsoever happens. How the transfer from droop to ISO will be bumpless in this case?
>We found the enumerated variable status_fld in ToolboxST (in
>software tab under variables. We used the search feature).
>We first tried to find the .cim
>configuration file. Lot of them were found in the screens
>folder but enumertions detail was not there in .cim in our
>case. We found it in ToolboxST.
Yes, GE keeps changing things all the time without documenting the changes. It's because the standard is: There is no standard.
>Yes L83SCI is going to logic "1".
>>So you need to find out what the permissives are for
>>which will, indeed, make TNRI the reference instead of
>I still have to find the block in which L83SCI or related
>signal makes TNRI the reference instead of TNR.
I didn't have time or access today to look at any speed control logic (CSP or application code). BUT, you should be able to use the Finder in ToolboxST and search for L83SCI or TNRI and find all the places either is used in the app code of your Mark VIe. (Or your commissioning field service person should be able to.... I don't call them field service engineers because they don't seem to do much engineering in the field. They only seem to be able to open PAC cases and use AutoCalibrate to try to solve just about every problem. Engineers try to reason their way through problems using logical thought processes, critical thinking skills, knowledge, experience and in many cases reading the manuals (BEFOREHAND--to learn as much as possible when there is NO pressure!))
>The actual frequency was a little bit higher. But it was in
>the deadband (+-0.17%). Shouldn't ISO mode select the actual
>frequency as its reference (if within its deadband)? I guess
>this is what we are missing. Only GUESS. When we put the
>turbine on ISO it gets the fixed TNRI. 100%. No change in
>TNRI whatsoever happens. How the transfer from droop to ISO
>will be bumpless in this case?
No; I don't think Isoch mode selects the current frequency; it selects whatever the value of TNRI is (and that can be changed by using the RAISE- or LOWER SPEED/LOAD buttons when Isoch Speed Control Mode is active).
Yes, the transfer should be bumpless when going from Droop to Isoch, and also when going from Isoch to Droop. But this assumes that the frequency is within the deadband, or, in other words, at rated when the switch from Droop to Isoch is made.
You said the actual speed (frequency) was high--100.14%. And you said that when you switched the Mark VIe to Isoch the unit started unloading. It's possible the deadband value in the Mark VIe is less than +/-0.17%, and so when switched to Isoch the unit started unloading because the speed (frequency) was higher than the deadband.
I just need to find some time and some logic to look over and study, because my memory just doesn't seem to be very good on this topic right now--probably because I've rarely had these kinds of issues. The CSP/app code I've had the fortune to work with has been pretty rock solid and bullet-proof in this regard, and I've only had to make minor changes (such as permissives for when Isoch could be enabled, or the deadband value). But, GE has been changing things, though some things like this which have been pretty standard for decades though weren't changing very much. That's one of the things that's made GE software so good over the decades--it's remained pretty stable even going from Mark IV to Mark V to Mark VI to Mark VIe. The only GE business which changes software simply for the sake of changing the software AND making it needlessly complicated is the GE Belfort (France) group. And, believe me when I tell you--they can screw things up like no one else. I don't think your machines software was provided by Belfort, but I may be wrong. My sincere condolences if it was. That only makes a bad situation worse.
Thanks for the feedback, by the way! It helps. Wish I had more time for these questions; I do enjoy helping, and I usually learn some things along the way, too. But, in all honesty--the field service commissioning person should be fixing these issues, and mostly be comparing the Mark V CSP to the Mark VIe application code. If there are differences, they should be able to go back to the group that provided the application code and work through the issues. Is that not happening?
>No; I don't think Isoch mode selects the current frequency;
>it selects whatever the value of TNRI is (and that can be
>changed by using the RAISE- or LOWER SPEED/LOAD buttons when
>Isoch Speed Control Mode is active).
Can we change speed in ISO control mode? We never change that. We always use the RAISE, LOWER buttons on the machine which is on DROOP. In this way when the LOAD is increased/decreased the machine which is on droop the other machine which is on ISO responds accordingly by increasing or decreasing its load.
If we decrease load on machine running on ISO, what will happen to load? Will it be picked by the machine on DROOP?
>I just need to find some time and some logic to look over
>and study, because my memory just doesn't seem to be very
>good on this topic right now--probably because I've rarely
>had these kinds of issues.
I am currently looking into the FSRN block. FSR is the final output to the fuel valve. FSR selects the minimum values from FSRN, FSRT, FSRU etc. In our case we are on FSRN. When trubine is in droop mode the FSRN is based on TNR-TNH. When the ISO mode is selected L83ISOK (Isochronos speed control selected) goes to "1". FSRN depends on TNR-TNH +/- FSRNI in this case. FSRNI takes its first value from TNRI-TNH. Later the previous value of FSRNI adds with TNRI-TNH. Anyhow I am still working on this block. I will write back about it as soon as I will complete it.
>Thanks for the feedback, by the way! It helps. Wish I had
>more time for these questions; I do enjoy helping, and I
>usually learn some things along the way, too. But, in all
>honesty--the field service commissioning person should be
>fixing these issues, and mostly be comparing the Mark V CSP
>to the Mark VIe application code.
>If there are differences,
>they should be able to go back to the group that provided
>the application code and work through the issues. Is that
Thanks for being helpful, CSA. Yes its the job of Field Service Engineer (and you provided the definition of service engineer in your reply. You are absolutely right about that. I wish GE should be aware of that too.) And yes, the FSE is doing the same thing except comparing the CSP with application code. I do not know why, but their engineering department is very reluctant to make the changes in the application code.
>Can we change speed in ISO control mode?
I believe if the operator clicks on RAISE- or LOWER SPEED/LOAD when operating in Isoch mode that will change TNRI--which will change the speed (and frequency) of all the machines synchronized to that grid.
>If we decrease load on machine running on ISO, what will
>happen to load? Will it be picked by the machine on DROOP?
I sense there is some confusion here. Operators cannot change the load of the Isoch unit using the controls of the Isoch unit. An Isochronous unit has essentially been told by the operator (when Isoch was selected) that the unit should automatically adjust its load in order to maintain frequency (speed). The ONLY way for an operator to change the load of an Isoch unit is to change the load of one or more of the Droop units synchronized to the grid with the Isoch unit. Raising the load of a Droop unit will tend to increase the frequency of the grid--but the Isoch unit will sense that change in speed (frequency) and reduce its load to maintain the frequency (speed) of all the units synchronized to that grid. Conversely, reducing the load of a Droop unit will tend to cause the grid frequency to decrease--but the Isoch unit will sense the change and increase its load to compensate and maintain the frequency (speed) of all the units synchronized to that grid.
The operator can't use the governor (control system) of the Isoch unit to change the load of the Isoch unit--it has to be done by changing the load of one or more of the Droop units, which will cause the Isoch unit's governor to respond accordingly.
The load on a grid is the sum of the lights and motors and televisions and computers and computer monitors and tea kettles--and when an operator is "changing the load" on a generator (using the prime mover's governor) one is NOT changing the number of lights and motors and televisions and computers and computer monitors and tea kettles--one is only changing the load being carried by that generator.
It's kind of a bad use of words/terms. But, for the frequency of a grid to remain constant the generators powering the grid all have to act as one generator, powering what appears to them to be one load (the sum of all the lights and motors and televisions and computers and computer monitors and tea kettles) and that includes the power required to maintain rated speed (frequency). "Changing load" on a generator isn't changing the number of lights or motors or televisions or computers and computer monitors or tea kettles--"changing load" on a generator only changes the amount of the total load on the grid that generator is supplying (carrying). The other units have to compensate when the load of one unit is changed, and if they don't compensate properly or to the extent required the amount of power required by the "load" (the number of motors and lights and computers and computer monitors and tea kettles) doesn't change--but the frequency of the grid will change, unless and until one or more of the units synchronized to the grid respond accordingly. When there is an Isoch unit on the grid, its job is to 'respond accordingly.'