I have problème and i need help please

@Shihabe3400,

The Mark* turbine control systems have a "feature" that allows trip conditions which occur AFTER a previous trip condition resulted in the actual tripping of the turbine. From the display you provided there are several trip conditions; the Status of the one that is highlighted is already NORMAL. Prior to that alarm there is a 'BZALL561 LOSS OF FLAME TRIP' which has also returned to NORMAL Status. And AFTER the highlighted alarm there at least one more trip condition 'UZA517 IGV CONTROL TROUBLE TRIP.'

So, from the display it's almost impossible to tell when--precisely--the turbine was initially tripped and which conditions were detected and alarmed AFTER the initial trip condition.

Again, this is a pretty serious fault of the Mark* turbine control system, and it has existed for decades. It sometimes makes troubleshooting trips very difficult. The BEST way to troubleshoot a trip is to quickly grab the Alarm printer's output very shortly after a trip, and start by finding the OLDEST trip condition and working from that one. One can also open the Trip History function and make a copy of the alarms which were stored in the memory and, again, finding the oldest trip condition and working from that one. (This presumes there were not dithering alarms (alarms going from ALARM to NORMAL to ALARM to NORMAL prior to the trip, because these will fill up the limited buffer of the Trip History display function.)

At least for me, it's impossible to tell what tripped the machine and when from the information/photo provided. I know well that most everyone who works on or operates a Mark* turbine control loathes and despises the "old technology" dot matrix alarm printer, and having to change ribbons or fix the paper when it gets twisted or put a fresh box of paper and feed it through the printer. BUT, there is no "new technology" printer that prints alarms as they are annunciated (and cleared) one line at a time. You could use a laser printer as an alarm printer, but it would either spit out a sheet of paper for EVERY SINGLE alarm, OR it wouldn't issue a sheet of paper until it was full of alarms (usually 80 lines or so). Dot matrix printers are fine--when they are properly maintained and operated. They are STILL the best line printer option for this particular application (alarm printing). They are inexpensive, they last decades (yes, decades, with good care and maintenance), and they are the perfect printer for this particular application (printing alarms one at a time as they occur (and are resolved) for high-speed rotating equipment). Believe it or not. If you had sent us a clear photo of the alarm printout at the time the trip occurred, we could have told you what happened in very short order.

What have you done to try to resolve the problem?

And, specifically, what is the problem? An inability to re-start the machine? A loss of LP speed indication? If it's the latter, there should be multiple, redundant passive speed pick-ups monitoring the turbine LP speed and providing the indication to the Mark*. (If the Mark* is a TMR (Triple Modular Redundant) panel there should be AT LEAST three (3) speed pick-ups, and sometimes six (6) monitoting the LP turbine speed, AND it's pretty unlikely all the speed pick-ups failed at the same time. (They should all be connected to the PTBA terminal board of the <P> core (that houses the TCEA cards, three of them) and each one should be jumpered to the respective control processor (<R>, <S>, <T>) if there aren't six speed pick-ups on the LP turbine. The I/O Report will tell you which terminals the LP turbine speed pick-ups are connected to.) There would also be Diagnostic Alarms indicating loss of the LP turbine speed pick-ups, so looking at the Diagnostic Alarms (you know--those nuisance alarms which nobody every pays attention to) can also help with understanding what happened when the turbine tripped, if there are sensors which were lost or failed.

That's all the help I can provide based on the information you provided.
 
Top