In markvi control system, i forced 3 of the p2 pressure transmitter with the live value, after few minutes machine tripped on under speed,

immediately reset all the alarm and unit started,
i have noticed the first alarm was FSR Ref.saactive
second was EGT Spread high,
third under speed and tripped the unit.
my question if it is forcing the analogue value, why it is happend? please advise
 
immediately reset all the alarm and unit started,
i have noticed the first alarm was FSR Ref.saactive
second was EGT Spread high,
third under speed and tripped the unit.
my question if it is forcing the analogue value, why it is happend? please advise
Hello All,

Gopinath,

First could you tell us, the reason why you forced these signals.

Did you get the P2 pressure, behaviour trended ??

Are you listed on your post all "alarms /trips" messages?

We can try to support, you if you tell us more details on this issue.

By better event description we can get better overview !

ControlsGuy25.

ControlsGuy25.
 
As ControlsGuy25 writes, it would be pretty highly unusual for any need for forcing the P2 pressure input signals.

AND, you didn't tell what else was going on when this happened. Where you starting the unit? Loading the unit? ???

The SRV uses the P2 pressure inputs as feedback to the control loop that regulates the P2 pressure as a function of speed. Most people believe that means that when the speed is 100% (or thereabouts in some parts of the world) that the SRV will be at a steady position because the speed is (relatively) stable. NOT TRUE. As the GCV opens and closes, if the SRV stays at the same position the P2 pressure will decrease or increase, respectively. So, if you were loading the machine, for example, the P2 pressure would drop--and depending on the gas fuel supply pressure and flow that could mean the flame would be extinguished in one or more combustors (causing a high exhaust temp spread) which could trip the unit before the flame was extinguished.

You have to tell us more--much more--about what was going on when the signals were forced. (It would be nice to understand why you felt the need to force the signals, but, I'm beyond that at this point. You had a reason, or a request, and because the Mark VI allows forcing of analog signals you did it. Was it the right thing to do? We'll never know, but it certainly doesn't sound like it was, does it?

Do you have the Trip Log or Trip History from the event you could share with us (by posting it as an attachment to this thread)?

Other than telling what was happening and sharing the chronological list of alarms, we can't be of much more help. In my opinion, based on the (little) information provided, the unit "protected" itself as best it could against what was probably a poor choice to force the signals. (Forcing logic--or analog-signals is a useful feature, but it is highly discouraged unless one knows what he/she is doing and what the knock-on effects are and what the risks are. Too many people are quick to say, "Force [that]!" because they think that will solve the problem, which usually isn't understood very well to begin with. To most people, a "good" START is anyone that results in synchronization and loading--regardless of alarms and other things which might be indicating a larger, more serious problem. Alarms be damned! Just force [something] and if it works, well, that's good, right? (Not always, though.)

More information=more help.
 
Thanks for the valuable feedback,
As you asked more information, i would like to share as below
Operation raised the work order on priority to attend the P2 Pressure transmitter differential Alarm in propane compressor Fuel gas transmitter-96FG a/b/c
2. The fuel gas transmitter A/B/C was forced in Mark VI at 9:54:34 at 180 PS1.
3. The Machine was running at 105% load in APC control with Remote (suction pressure controller).
4. At 10:05:42 (L 60TRF-ALM) FSR Temp. Ref Active Alarm appeared in TCS, following with Stage 1 Anti-surge detection 7 under speed Alarm appeared which is caused the machine tripped.
5. The main cause suspected was due to high load and CDP (High Ambient).
6. The FSR logic was referring to the parameters , the machine with last value to deviation with estimated (median value) and actual forced pressure value, the FSR block triggered the trip signal (protection) and tripped the unit.
7. The machine was then started back at 10:16:38 and loaded successfully.

As i understand ,with high load, we could not force the P2 transmitter to attend any job, unless to reduce the load with less ambient. if you have more clarification please share .
see the attached DCS trend and Alarm for your ref

 

Attachments

Gopinath,

Thank you for the quick response and information. If I understand correctly, you said you forced the P2 pressure transmitters, which would be GE device number 96FG-2A, 96FG-2b and 96FG-2C (usually; I don't know what your device numbering system is, probably some perversion of KKS). If I understand the work order correctly, it was for "96FG" on the propane compressor, which would not be 96FG-2A, -2B or -2C. It would probably be something like GE device number 96FG-11 or 96FG-31 or something like that.... The work order was most likely referring to the propane supply pressure transmitter, NOT the P2 pressure transmitter. If the propane system uses its own set of SRV and GCV then usually the GE device numbers would be 96FG-21A, -21B and 21C--or something like that (to indicate a second set of P2 pressure transmitters). And you didn't say what fuel the unit was running on when this occurred, either (not that I recall).

So, if you forced the wrong transmitter(s), well, that would certainly result in unwanted problems, and even trips....

A high ambient temperature means a LOW CPD (Compressor Pressure - Discharge), not a high CPD (sometimes called CDP, from the "old days" of Speedtronic turbine control systems). (Unless the inlet air is cooled using an evaporative cooler or some other means of inlet cooling.)

I don't have the ability to look at the .pdf files at the moment, but from your description it would seem you forced the wrong transmitter(s).

And, you are correct--I would NOT recommend EVER forcing P2 pressure transmitter input signals, especially not all three at the same time (inclluding at full speed and full load!). If you have to force all three P2 pressure transmitter inputs, then something is seriously wrong with the unit. This is a critical parameter--P2 pressure; that's why it has three, redundant transmitters! It should never be necessary to force any more than one P2 pressure transmitter input, say for replacing one while the unit is running--and then ONLY if you were 1000% ABSOLUTELY POSITIVE the speed would not be changing, and on a compressor drive (mechanical drive) turbine application this is hardly ever the case.

When I can get to a place where I have time and a larger screen than on my smarter-than-me-phone I will try to look at the .pdf files--but from the information provided I think the wrong transmitters were forced--transmitter inputs which should almost NEVER be forced.

Again, forcing of logic or analog signals is not recommended unless one is sure of the signal and its uses in the control and protection of the turbine AND the knock-on effects (if any, and there are usually some--especially for a critical analog signal like this one) AND one is aware of the risks (such as tripping a unit).

Hope this helps! I'm sure ControlsGuy25 will have time to analyze the .pdf files and provide additional insight.
 
Gopinath,

Thank you for the quick response and information. If I understand correctly, you said you forced the P2 pressure transmitters, which would be GE device number 96FG-2A, 96FG-2b and 96FG-2C (usually; I don't know what your device numbering system is, probably some perversion of KKS). If I understand the work order correctly, it was for "96FG" on the propane compressor, which would not be 96FG-2A, -2B or -2C. It would probably be something like GE device number 96FG-11 or 96FG-31 or something like that.... The work order was most likely referring to the propane supply pressure transmitter, NOT the P2 pressure transmitter. If the propane system uses its own set of SRV and GCV then usually the GE device numbers would be 96FG-21A, -21B and 21C--or something like that (to indicate a second set of P2 pressure transmitters). And you didn't say what fuel the unit was running on when this occurred, either (not that I recall).

So, if you forced the wrong transmitter(s), well, that would certainly result in unwanted problems, and even trips....

A high ambient temperature means a LOW CPD (Compressor Pressure - Discharge), not a high CPD (sometimes called CDP, from the "old days" of Speedtronic turbine control systems). (Unless the inlet air is cooled using an evaporative cooler or some other means of inlet cooling.)

I don't have the ability to look at the .pdf files at the moment, but from your description it would seem you forced the wrong transmitter(s).

And, you are correct--I would NOT recommend EVER forcing P2 pressure transmitter input signals, especially not all three at the same time (inclluding at full speed and full load!). If you have to force all three P2 pressure transmitter inputs, then something is seriously wrong with the unit. This is a critical parameter--P2 pressure; that's why it has three, redundant transmitters! It should never be necessary to force any more than one P2 pressure transmitter input, say for replacing one while the unit is running--and then ONLY if you were 1000% ABSOLUTELY POSITIVE the speed would not be changing, and on a compressor drive (mechanical drive) turbine application this is hardly ever the case.

When I can get to a place where I have time and a larger screen than on my smarter-than-me-phone I will try to look at the .pdf files--but from the information provided I think the wrong transmitters were forced--transmitter inputs which should almost NEVER be forced.

Again, forcing of logic or analog signals is not recommended unless one is sure of the signal and its uses in the control and protection of the turbine AND the knock-on effects (if any, and there are usually some--especially for a critical analog signal like this one) AND one is aware of the risks (such as tripping a unit).

Hope this helps! I'm sure ControlsGuy25 will have time to analyze the .pdf files and provide additional insight.
Gopinath, CSA,

CSA have pointed a good thing, about an eventual mistake on pressure transmitter designation.

Gopinath,

Thank you for the datas you added here.


My first impression after seen trends and trip/alarm log list is that 2 FSR REFER TEMP ACTIVE are shown in the list at 10:03:56 written slightly differents but looks same signal??? can you confirm that ?


On the trends you have posted , one can see both controls Valves SRV/GCV behaviour.

And it doesnt looks great! They were like cycling for maintening pressure reference but with that forced values you putted one cannot have a statement without seen the pressures transmitters trends.

I cannot state about CPD as you mentioned, as I don't see any CPD alarm dispalyed on the trip log .

Can you tell us, the value you forced ( both nominal value and forced value to get such behaviour of the unit?)

Did you notice any alarm on SRV/GCV position ?? The event is not showing anything on these Valves.

Also what about "OPERATION POINT AT SURGE SURGE " ? is compressor getting near or operated at line surge in this event?

One more thing, some alarms could be clarified :

"TEMP SPREAD LOW TRIP " getting "LOW" can you explain this
"PROPANE SRG DET ON SPV" - ALARM
"PROPANE SRG DET ON FLW"-ALARM
"PROPANE 1 SRG A/S DET"- ALARM
"STAGE 1 MAXIMAL FLOW DERIVATIVE" -RSI is that thresold/setpoint?


I may have another reviewing, on the files and put some comments .

I am quiet sure that CSA, will put some notes after have read the pdf files.


One more question:
Did you ever make this "test " earlier and did you get the result you were looking for?


As CSA mentioned above, THATS NOT GOOD AT ALL TO DO SUCH SIMULATION, moreover with unit online and loaded.

Regards,
ControlsGuy25.
 
Gopinath,

I have probably misunderstood, thinking that the unit burns natural gas AND propane.... After looking at the data, and without any information, when you mentioned 96FG I presumed that was a gas fuel supply transmitter, one for propane being used as a fuel and that there was a compressor which was supplying the propane under pressure to an SRV/GCV. After a re-read and a re-re-read it appears the gas turbine drives a propane compressor.?.?.?

If the unit has a Mark VI, why didn't you provide the Trip Log file, and the Alarm Log file? Instead, you seem to be using some DCS which mimics (duplicates) the information it gets from the Mark VI--which may or may not have the correct date/time tags when the signals were actually changing in the Mark VI and the alarms were actually being annunciated and cleared/reset--and expecting the reader to understand that, without providing any information except "...DCS..." (and some people, believe it or not, quite often call the Mark* "the DCS").

From the alarm list, I surmise that PROP or PROPANE refers to the gas turbine that drives a propane compressor. Is that correct? Please confirm or clarify.

We also don't know if all of the "alarms" listed on the alarm list are actually Process Alarms generated by the application code running in the Mark VI, or a combination of Events and SOE's configured in the Mark VI and Process Alarms. AND, there's something about a Field Flashing Speed Relay.?.?.?!!!??? Why would a propane compressor have field flashing, which is something for a synchronous generator during starting (this is what makes me believe the "alarm list" is a combination of Process Alarms and Events and SOE's--not just Process Alarms).

Anyway, your original question was: "my question if it is forcing the analogue value, why it is happend? please advise "

Well, with the information provided it's extremely difficult to do so--but I can say that forcing the three, redundant P2 pressure transmitters was probably a huge contributing factor to the problem. We can't see the application code running in the Mark VI so we don't know what's going on with the 96FG transmitter which the work order was about--because I maintain you forced 96FG-2A, -2B & -2C, instead of 96FG-1 or 96FG-3 or whatever the device the work order was really written for. AND, forcing 96FG-2A, -2B & -2C is really a pretty big no-no for a machine that's not a generator drive (because the machine runs in a speed range while a generator drive (should) run at a fairly constant speed in order to be producing a fairly constant frequency. It still would not be recommended for a generator drive application, either (forcing all three redundant P2 pressure transmitter inputs).

Anyway, I doubt given the information you have provided (and not provided, too) that we are going to be able to say anything more definite. Forcing signals--logic or analog--is risky business unless all the knock-on effects are known AND all the risks are understood. Also, sometimes the presence of some Diagnostic Alarms could indicate other problems that forcing might make worse, resulting a trip or damage to the unit. Just because forcing is a tool available for troubleshooting and temporarily getting past known, understood issues means it should always be used whenever there is a problem that is attributed to the Mark*.

Best of luck! (I would appreciate it you would confirm or clarify about the gas turbine driving the propane compressor. It might also burn propane if it produces propane, but we don't know that unless you tell us.)
 
Gopinath,

I have probably misunderstood, thinking that the unit burns natural gas AND propane.... After looking at the data, and without any information, when you mentioned 96FG I presumed that was a gas fuel supply transmitter, one for propane being used as a fuel and that there was a compressor which was supplying the propane under pressure to an SRV/GCV. After a re-read and a re-re-read it appears the gas turbine drives a propane compressor.?.?.?

If the unit has a Mark VI, why didn't you provide the Trip Log file, and the Alarm Log file? Instead, you seem to be using some DCS which mimics (duplicates) the information it gets from the Mark VI--which may or may not have the correct date/time tags when the signals were actually changing in the Mark VI and the alarms were actually being annunciated and cleared/reset--and expecting the reader to understand that, without providing any information except "...DCS..." (and some people, believe it or not, quite often call the Mark* "the DCS").

From the alarm list, I surmise that PROP or PROPANE refers to the gas turbine that drives a propane compressor. Is that correct? Please confirm or clarify.

We also don't know if all of the "alarms" listed on the alarm list are actually Process Alarms generated by the application code running in the Mark VI, or a combination of Events and SOE's configured in the Mark VI and Process Alarms. AND, there's something about a Field Flashing Speed Relay.?.?.?!!!??? Why would a propane compressor have field flashing, which is something for a synchronous generator during starting (this is what makes me believe the "alarm list" is a combination of Process Alarms and Events and SOE's--not just Process Alarms).

Anyway, your original question was: "my question if it is forcing the analogue value, why it is happend? please advise "

Well, with the information provided it's extremely difficult to do so--but I can say that forcing the three, redundant P2 pressure transmitters was probably a huge contributing factor to the problem. We can't see the application code running in the Mark VI so we don't know what's going on with the 96FG transmitter which the work order was about--because I maintain you forced 96FG-2A, -2B & -2C, instead of 96FG-1 or 96FG-3 or whatever the device the work order was really written for. AND, forcing 96FG-2A, -2B & -2C is really a pretty big no-no for a machine that's not a generator drive (because the machine runs in a speed range while a generator drive (should) run at a fairly constant speed in order to be producing a fairly constant frequency. It still would not be recommended for a generator drive application, either (forcing all three redundant P2 pressure transmitter inputs).

Anyway, I doubt given the information you have provided (and not provided, too) that we are going to be able to say anything more definite. Forcing signals--logic or analog--is risky business unless all the knock-on effects are known AND all the risks are understood. Also, sometimes the presence of some Diagnostic Alarms could indicate other problems that forcing might make worse, resulting a trip or damage to the unit. Just because forcing is a tool available for troubleshooting and temporarily getting past known, understood issues means it should always be used whenever there is a problem that is attributed to the Mark*.

Best of luck! (I would appreciate it you would confirm or clarify about the gas turbine driving the propane compressor. It might also burn propane if it produces propane, but we don't know that unless you tell us.)
THANKS DEAR,
APPRECIATED YOUR FEED BACK, I HAVE LEARN THE LESSON FROM THE MISTAKE AND I WILL not do any P2 Transmitters forcing during the machine running.,i will postponed the job during shutdown.
 
THANKS DEAR,
APPRECIATED YOUR FEED BACK, I HAVE LEARN THE LESSON FROM THE MISTAKE AND I WILL not do any P2 Transmitters forcing during the machine running.,i will postponed the job during shutdown.
Ok

BUT you could at least by "courtoisy" try to reply to my post ??
I make effort for supporting people here and some of them are just stonish §!!!

Controls Guy25
 
i do respect , and i have limitation to collect the trip log and event summary from markvi, it is not allowed to use USB as it is against company policy, what ever feed back has given, really great and i went through the logic, and understand the median value is the major role of SRV set point ref, and with peak load, i should not force 3 of the transmitter, i learn the lesson from the mistake and i am very grateful for your feedback given.
 
i do respect , and i have limitation to collect the trip log and event summary from markvi, it is not allowed to use USB as it is against company policy, what ever feed back has given, really great and i went through the logic, and understand the median value is the major role of SRV set point ref, and with peak load, i should not force 3 of the transmitter, i learn the lesson from the mistake and i am very grateful for your feedback given.
Okay,

Let's close this thread , even I asked some questions regarding unit operation ( see my last post ) , ( no matter ).

I guess I know what happened in this event .

Thank you for your feeback.

I do respect too.
 
Okay,

Let's close this thread , even I asked some questions regarding unit operation ( see my last post ) , ( no matter ).

I guess I know what happened in this event .

Thank you for your feeback.

I do respect too.
Hey there,
I am pleased to read your replies and understand your attitude to our problems which related with facilities and units, may be
next time You should not spend time for this person.
This dialogue has to go like question and answer, as result We will be able to solve problems.
And here I have seen total indifference.
 
ControlEng999,

I think you follow the threads on Control.com fairly regularly, but I may be wrong. In any case, MANY people write to ask for help or information and many people spend time (some more than others) providing help and information. The cost to the original poster is the same as what the responders earn: Nothing. Zip. Zilch. Zero. Nada. Niente. Meaning: It's free for everyone.

I realize in some parts of the world and in some cultures there is no direct translation for the word "please" and we get LOTS of requests for help and information which do not include any type of polite solicitation, more like demands. (Again, I get it that some cultures and some parts of the world don't use such niceties, and none are expected in return, either.) BUT, we have tried to encourage people who may, or may not, have asked politely for help or information to provide feedback of some sort. In many (most) cases, the information provided when requesting (demanding) help or information is very, very lacking. And so, naturally, responders will ask for additional information. Many times, the original posters will deem the additional information irrelevant or difficult to obtain or just don't know the answer--and they don't respond. They asked for help; we try to provide it; sometimes we need additional information--which, if you're asking for free help and information, is a reasonable request to provide useful and pertinent help and information.

Go to some other forums on the World Wide Web (for any area of interest) and you will see all manner of wild and brief and terse and even unintelligible responses to original posts, some (many, actually) which don't appear to have any relevancy at all to the original question(s), or only address one portion of the original post.

We here at Control.com have tried very hard to answer the questions asked (however nicely, or not) and provide requested information--again, all for free. All we ask in return (since we're not getting paid for our time and effort and knowledge) is some acknowledgement that the help and information provided was useful or not, and when we ask for additional information to be as concise as possible that the original poster respond with the requested information.

Look--they wrote asking for help. If they could have solved their problem or found the information without writing to this forum they would have. So, if they wrote then they need help. And when the don't provide enough information to be able to drill down and provide timely and concise answers and information, well, then, we ask for more information. And, since they couldn't solve the issue on their own they should respect the request of someone who is trying to help them and respond in some manner--even if it's to say, "We investigated that, and we did [this] and [that] during the investigation, and [these] were the results; so we have eliminated that as a cause."

Many people also write to forums like these thinking that the problem they are writing about is common to every similar piece of equipment that shares the same name (like Frame 5 or Frame 9E). And, that's simply NOT the case. NOT AT ALL. Many problems are falsely attributed to [this] or [that], and so we have to get more information.

So, all we're asking for is some kind of response to our attempts to provide more useful and concise help and information. That's it. Often, we're simply ignored--and we understand that; people are busy and on to the next "burning" issue (real or perceived). Or off to their vacation or weekend of shift change. All understandable.

But, I think, ControlEng999, since you seem to keep returning to Control.com, that you will agree: The information provided here is useful and concise (as can be), and the feedback (when provided) is also very helpful to see what worked and what didn't for others with the problem. That's all part of the process here--and we sometimes become a little bothered when people don't respect the time and effort we put in to our responses.

We will learn as some posters continue to ask for help and information and don't provide requested information or don't provide necessary details that we won't spend as much time on their posts as we have in the past.

Hope this helps!
 
ControlEng999,

I think you follow the threads on Control.com fairly regularly, but I may be wrong. In any case, MANY people write to ask for help or information and many people spend time (some more than others) providing help and information. The cost to the original poster is the same as what the responders earn: Nothing. Zip. Zilch. Zero. Nada. Niente. Meaning: It's free for everyone.

I realize in some parts of the world and in some cultures there is no direct translation for the word "please" and we get LOTS of requests for help and information which do not include any type of polite solicitation, more like demands. (Again, I get it that some cultures and some parts of the world don't use such niceties, and none are expected in return, either.) BUT, we have tried to encourage people who may, or may not, have asked politely for help or information to provide feedback of some sort. In many (most) cases, the information provided when requesting (demanding) help or information is very, very lacking. And so, naturally, responders will ask for additional information. Many times, the original posters will deem the additional information irrelevant or difficult to obtain or just don't know the answer--and they don't respond. They asked for help; we try to provide it; sometimes we need additional information--which, if you're asking for free help and information, is a reasonable request to provide useful and pertinent help and information.

Go to some other forums on the World Wide Web (for any area of interest) and you will see all manner of wild and brief and terse and even unintelligible responses to original posts, some (many, actually) which don't appear to have any relevancy at all to the original question(s), or only address one portion of the original post.

We here at Control.com have tried very hard to answer the questions asked (however nicely, or not) and provide requested information--again, all for free. All we ask in return (since we're not getting paid for our time and effort and knowledge) is some acknowledgement that the help and information provided was useful or not, and when we ask for additional information to be as concise as possible that the original poster respond with the requested information.

Look--they wrote asking for help. If they could have solved their problem or found the information without writing to this forum they would have. So, if they wrote then they need help. And when the don't provide enough information to be able to drill down and provide timely and concise answers and information, well, then, we ask for more information. And, since they couldn't solve the issue on their own they should respect the request of someone who is trying to help them and respond in some manner--even if it's to say, "We investigated that, and we did [this] and [that] during the investigation, and [these] were the results; so we have eliminated that as a cause."

Many people also write to forums like these thinking that the problem they are writing about is common to every similar piece of equipment that shares the same name (like Frame 5 or Frame 9E). And, that's simply NOT the case. NOT AT ALL. Many problems are falsely attributed to [this] or [that], and so we have to get more information.

So, all we're asking for is some kind of response to our attempts to provide more useful and concise help and information. That's it. Often, we're simply ignored--and we understand that; people are busy and on to the next "burning" issue (real or perceived). Or off to their vacation or weekend of shift change. All understandable.

But, I think, ControlEng999, since you seem to keep returning to Control.com, that you will agree: The information provided here is useful and concise (as can be), and the feedback (when provided) is also very helpful to see what worked and what didn't for others with the problem. That's all part of the process here--and we sometimes become a little bothered when people don't respect the time and effort we put in to our responses.

We will learn as some posters continue to ask for help and information and don't provide requested information or don't provide necessary details that we won't spend as much time on their posts as we have in the past.

Hope this helps!
CSA hello,
Yeah, you have explained me it most detailed, I am happy that there are high qualified professionals who can help us
Best wishes CSA
 
Top