Hello All,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
Gopinath, CSA,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.
THANKS DEAR,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.)
OkTHANKS 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.
Okay,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.
Hey there,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.
CSA hello,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!
HiHi All frendz ,
kindly send me ppt or pdf file regarding markvi signal forcing and unforcing .
Via this email
[email protected]
Very thank full to all frendz
Thread starter | Similar threads | Forum | Replies | Date |
---|---|---|---|---|
I | MarkVI UDH/PDH Switch Confguration | Power Generation | 3 | |
R | MarkVI-e, PFR ON an PFR OFF | Power Generation | 5 | |
D | Modbus TCP HW C300 - MarkVI | Modbus | 1 | |
D | GE Control System Toolbox for MarkVI Speedtronic Gas Turbine | Power Generation | 11 | |
K | MarkVI cannot get to control/equal state | Power Generation | 2 |