Today is...
Saturday, May 27, 2017
Welcome to, the global online
community of automation professionals.
Featured Video...
Featured Video
Wiring and programming your servos and I/O just got a lot easier...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Exhaust Thermocouple
Open exhaust thermocouple.

I have seen exhaust thermocouples open while GTG is in service and on load, most of the production companies does not want to shutdown the unit for replacing exhaust thermocouple. They parallel the open thermocouple with the good ones in Junction box in the field or in MK V control panel. The opened TC will be replaced during the shutdown.

Is this advised to do or shutdown the GTG and replace it with good one on the same day. If this is allowed which thermocouple has to be paralled (the TC which is adjacent to the open TC or exactly the diagonal TC) please can anybody explain what is the reason to parallel with TC which is in diagonal to the opened TC.

thanks in advance


2 out of 2 members thought this post was helpful...

It's quite common to jumper good exhaust T/Cs to bad ones when the unit is running to avoid shutting the unit down. It's also quite common to jumper the wrong good T/C.

If an exhaust has 18 T/Cs and the Mark V is a TMR, then there are six "areas" being monitored, with three T/Cs in each area, one connected to <R>, one connected to <S>, and one connected to <T>. When jumpering good exhaust T/Cs to "replace" a failed one, one needs to choose an exhaust T/C which is in the same "area" as the one that has failed.

So, if the <R> T/C input of an area has failed, one should choose the *exhaust* T/C directly on either side of the one that's failed (the <S> for that area or the <T> for the area "upstream" of the one where <R>'s input failed). Choosing a T/C "diagonally" opposite is not correct. The T/C terminated on the TBQA on <R> just to the left or right of the failed T/C input is *not necessarily* the T/C which is immediately next to the failed T/C in the exhaust.

The first group of 15 T/C inputs to the TBQA on <R> are for <R>; the second group of 15 T/C inputs on the TBQA on <R> are for <S>; and the third group of 15 T/C inputs are for <T>. So, TBQA-1 & -2 are TTXD-1 which is connected to <R>; TBQA-31 & -32 are TTXD-2 which is connected to <S>; and TBQA-61 & -62 are TTXD-3 which is connected to <T>. TBQA-3 & -4 are for TTXD-4 which is connected to <R>; TBQA-33 & -34 are TTXD-5 which is connected to <S>; and TBQA-63- & -64 are TTXD-6 which is connected to <T>. And so on, continuing around the exhaust area.

For example, if the input TTXD-4 at TBQA-3 and -4 failed, the input at TBQA-61 & -62 (TTXD-3) or the input at TBQA-33 & 34 (TTXD-5) should be jumpered to TBQA-3 & -4. If one jumpered the input at TBQA-1 & -2 to TBQA-3 & -4 they would be jumpering TTXD-1, which is three T/Cs upstream of TTXD-4. Or, if one jumpered the input at TBQA-5 & -6 to TBQA-3 & -4 they would be jumpering TTXD-7, which is three T/Cs downstream of TXD-4.

If a good T/C in a different area of the exhaust is jumpered to a failed input, then the Combustion Monitor will not be sensing the temperatures in the proper "sequence" and a false trip could occcur. The worst effect of a false trip is that when the failed T/C is replaced during the shutdown and the jumper is removed and the unit is restarted, there could still be a high spread which "miraculously" appears to have moved to a different area of the unit. This can be maddening for troubleshooting exhaust temperature spreads, and has caused more than one very heated argument and lot of finger-pointing ("blame shifting").

AK, the GE-design heavy duty gas turbine control community here at like to receive feedback about the replies posted to requests for information or help. The biggest reason is that other people can read the threads later using the 'Search' feature of and can see if the information provided was helpful or not.

Another reason is so that those responding can determine if the information they've provided was useful or not. "Feedback is the most important contribution" (c) here at It's what makes the posts helpful to many people around the world, knowing what works and what doesn't.

Please, let us know if you find the information useful, or a complete miss. If you have a few minutes to write to ask for information or help, please find a few minutes to write back to let others know if the information was useful or not.

Dear CSA

Thank you very much for clarifying my doubts on exhaust thermocouples, your answers to the questions on this site makes many people like me to learn and build confidence.

Thanks a lot again


By Vimal Gupta on 10 May, 2017 - 7:01 am

Dear Sir,
I am little bit confused about frame-V machine Exhaust Thermocouples (Total 13 No). Details of T/C connected to controller as below:

<R> <S> <T>
TTXD_12 TT-XD-10 TT-XD-11

I tried for grouping of T/C, but i am confused.
And for 13 No T/C looping with which number has to be looped.

Kindly suggest.

2 out of 2 members thought this post was helpful...

Vimal Gupta,

The concept is that one-third of the available T/Cs are connected to <R>, one-third to <S> and the remaining third to <T>. When the number of T/Cs is not evenly divisible by three, the remaining exhaust T/Cs have to be connected to one or two processors. Typically, in the case of thirteen exhaust T/Cs, five are connected to <R>, four are connected to <S> and four to <T>. The connection you provided is unusual, but would function as well as the typical connection scheme.

The connection is done as it is so as to be able to monitor areas of the exhaust with all three processors. It's difficult to draw on, and we can't (yet) attach sketches or pictures, but I'll try. With 13 exhaust T/Cs, there will be four (4) areas "created" in the exhaust by the way the T/Cs are connected to the three control processors. My representation is for the typical assignment for thirteen exhaust T/Cs (five to <R>, four to <S>, and four to <T>); you can redraw it for your assignment--it's functionally still the same in the control system.

<R> |
13 | <R>
<T> | 1
12 | <S>
<S> | 2
11 | <T>
<R> | 3
10 |
<T> | <R>
9 | 4
<S> | <S>
8 | 5
<R> | <T>
7 | 6
(View Looking UPSTREAM)

While the above sketch is not perfectly symmetrical, it does show that in each "area"/quadrant there is at least one T/C from each controller. In the event that any controller fails or has to be powered-down, the remaining two controllers can still have a relatively good sense of the exhaust temperatures in that area--and thereby still fairly reliably perform the Combustion Monitor function, which is what this arrangement is all about: being able to detect combustion problems and trip the unit to prevent serious or even catastrophic damage to the turbine.

The processors are configured to know the number of exhaust T/Cs connected to them, and the combustion monitor can accommodate the loss of the exhaust T/Cs associated with one controller and still detect cold spots or hot spots which are the mark of combustion trouble which could lead to damage.

So, I'm not quite sure I understood the question(s) you posed. (I'm certainly surprised at the way the exhaust T/Cs were assigned to the control processors, but, again, functionally it's the same whether five exhaust T/Cs are connected to <R> or <S>.)

Again, in the Frame 5 exhaust with thirteen exhaust T/Cs and a TMR control system there are four "areas" (quadrants) that are "created" by the assignment of the exhaust T/Cs to the three controllers. If there were 18 exhaust T/Cs, there would be six "areas"; 27 exhaust T/Cs would create nine "areas". Each area is a segment of a circle which are roughly equal in size. (I think 13 exhaust T/Cs were used because it provided a little more "precision" when trying to detect cold- or hot-spots downstream of ten combustors. But, it did complicate things when the TMR system was introduced. It should be noted that early digital TMR control systems (Mark IVs and some Mark Vs) did NOT have combustion monitors in the turbine control systems. The turbines were fairly robust and it was felt that well-trained and conscious operators would be monitoring turbine operation and would take appropriate action to protect the turbine should cold- or hot-spots in the turbine exhaust develop.)

I hope this helps! There is a method to the madness, even if it's very poorly documented sometimes.

By vimal gupta on 11 May, 2017 - 5:48 am

Dear CSA,

Thanks for prompt reply. I have understand clearly for grouping of exhaust thermocouple from your reply.
I have again checked & confirmed in our machine, Exhaust Thermocouples grouping was found unusual.
This sketch may not be proper in preview.

It is like as below:-

<R> |
12 | <R>
<T> | 13
11 | <S>
<S> | 1
10 | <T>
<R> | 2
9 |
<T> | <R>
8 | 3
<S> | <S>
7 | 4
<R> | <T>
6 | 5

Kindly guide us, this configuration is ok or we have to change this configuration as per standard configuration as mentioned in your reply?

Existing configuration termination details as below:

TTXD-3 1D3A-JA1-1,2 1
TTXD-6 1D3A-JA1-3,4 1
TTXD-9 1D3A-JA1-5,6 1
TTXD-12 1D3A-JA1-7,8 1

TTXD-1 1D1A-JA1-1,2 2
TTXD-4 1D1A-JA1-3,4 2
TTXD-7 1D1A-JA1-5,6 2
TTXD-10 1D1A-JA1-7,8 2
TTXD-13 1D1A-JA1-9,10 2

TTXD-2 1D2A-JA1-1,2 3
TTXD-5 1D2A-JA1-3,4 3
TTXD-8 1D2A-JA1-5,6 3
TTXD-11 1D2A-JA1-7,8 3

We also faced thrmocouple failure problem as below:

1. TTXD-11 failed, We provided jumper with TTXD-8.

2. After few days, TTXD-12 also failed, again we provided jumper with TTXD-2.

We know that these jumper provided are wrong. How to do proper jumper to avoid any tripping due to wrong jumper.

Kindly guide us for this.

2 out of 2 members thought this post was helpful...

Dear Vimal Gupta,

The philosophy when jumpering failed T/Cs is to jumper one that is adjacent to the one that has failed. It doesn't matter if it's in the same artificially created "area" because the Combustion Monitor just checks for adjacency.

For example, if TTXD_12 failed the EASIEST thing to do would be to jumper TTXD_9 to TTXD_12 (because that's the closest T/C to TTXD_12 on the terminal board). BUT, TTXD_9 is NOT the closest T/C to 12--which would be TTXD_11 OR TTXD_13, and which are both on different terminal boards.

You said that at your site TTXD_11 failed, and you jumpered it with TTXD_8. That's not in the same "area" as TTXD_11. So, when the Combustion monitor is checking for adjacency this would cause a problem which could result in a possible alarm/trip. You should have jumpered TTXD_10 or TTXD_12 to the TTXD_11 input.

And, if TTXD_12 then failed, that--to me--says there is something amiss with the exhaust T/Cs and/or there is a real combustion problem causing the T/Cs to fail and jumpering is NOT the proper solution. Rather, the proper solution would be to shut the machine down, wait for it to cool, then go into the exhaust and investigate what could be the possible cause (because I have seen insulation get blown onto the radiation shield which blocked the hot exhaust gases and made the feedback from the T/C APPEAR to have gone low, and led to the perception that the T/C had failed. I've seen multiple T/Cs in the same area blocked by insulation causing just the issue you have described.

As the turbine is cooling, the exhaust T/C data should be reviewed to determine if it would also be prudent to examine one or more fuel nozzles/combustors to determine if there might be a problem should the exhaust duct investigation not reveal anything concrete.

The philosophy is NOT to jumper the closest good T/C to the failed T/C based on terminal board assignments, but to jumper the T/C physically closest to the failed T/C in the exhaust to the failed T/C input--which could be on the T/B furthest away from the one with the failed input.

And, if two adjacent T/Cs fail--well, that's not really a good thing, is it? There was a plant once that kept "jumpering" failed T/Cs because they just believed that the T/Cs must have come from a bad batch--but the T/Cs that were failing were adjacent to each other in the exhaust and there was a REAL combustion problem, and USD2.9 million and four months later the unit was back on line. And, the owner blamed GE for allowing T/Cs to be "jumpered" for the failure.

Again, it's not easy to draw on, and as was written--the drawing wasn't perfect, but it did show four artificially created "areas", three with three T/Cs, and one with four T/Cs. If T/Cs fail and need to be jumpered the important concept is to jumper the T/C physically closest to the failed T/C in the exhaust to the Mark VIe input--NOT the closest T/C to the failed input on the same terminal board as the failed input.

The exception--and there's always an exception--would be if TTXD_1 failed; TTXD_13 is one of the two closest T/Cs in the exhaust to TTXD_1 (the other is TTXD_2). Or, if TTXD_13 failed, TTXD_1 is one of the closest T/Cs in the exhaust which is also on the same TB.

It's about the closest T/C in the exhaust to the failed T/C, NOT the closest T/C on the terminal board to the failed T/C.

And, NO, you should NOT make any changes to the wiring/assignment of the T/Cs. If it's been working fine, leave it. It's unusual--not wrong.

Hope this helps!

By vimal gupta on 12 May, 2017 - 6:13 am
1 out of 1 members thought this post was helpful...

Dear CSA,

We have shut down the machine to inspect the exhaust duct. After cool down, we will inspect the exhaust duct and will inform to you in case of any abnormality.

I understood about jumper from your reply that jumper should provide with good closest T/C to failed T/C within same exhaust area (NOT in same terminal board).

In case of TTXD_11 failed, jumpered TTXD_10 or TTXD_12 to the TTXD_11 input. In all cases, FAILED T/C WILL BE JUMPERED WITH ADJACENT GOOD T/C. Again i have some doubt on tripping of turbine on exhaust T/C failure interlock.

I read in manual for tripping on Exhaust T/C that If any two adjacent T/C failed, Machine will trip. If it is true, then how we can provide jumper on closest T/C which may be adjacent?

Kindly share the knowledge of tripping on exhaust T/C.

2 out of 2 members thought this post was helpful...

Vimal Gupta,

When jumpering thermocouples one is essentially trying to fool the turbine control system and that has risk associated with it. One is gambling by taking a short-cut by not shutting the unit down to replace the failed T/C. And if the T/C that you choose to jumper to the failed T/C then fails--your ("calculated") gamble fails.

Again, if the adjacent T/C one chose to jumper to a failed T/C fails that says (to my way of thinking about the situation) there is some problem in that area of the exhaust, or with the T/Cs wires/leads from that area of the exhaust that is causing the failures.

Or, worse, there may be a combustion trouble condition that can, left undetected, cause serious, catastrophic failure of the turbine. And the cost of repairs may far exceed the cost to shut the unit down to check for the cause of the failures of adjacent T/Cs. FAR exceed the shutdown/lost generation..

Just because a working T/C can be jumpered to a failed T/C does NOT mean that is the proper solution to the problem. And, certainly, if an adjacent T/C fails to one that has already failed--that absolutely does not mean the proper solution is to jumper another working T/C to the failed T/Cs (to my way of thinking about the situation).

One cannot--and should not--expect the turbine control system to detect jumpered T/Cs and take appropriate action to keep the turbine running. The fact that two adjacent T/Cs failed is, itself, an indication of some kind of real problem.

What I'm about to say is extremely unpopular, but it's the truth. One has to be EXTREMELY careful about what one reads in some written document about GE-design heavy duty gas turbine (or steam turbine) control or protection. The ONLY completely accurate description of what happens in any GE-design turbine control is what's programmed and downloaded to that particular turbine control system. Full stop. Period. NOT what's written in some document.

A former colleague used to say, "Unless you wrote that description for that particular machine [based on your review of the running sequencing/application code], or you know the person who wrote that description of the running sequencing/application code for that particular machine based on his/her review--you should not believe that is how that particular turbine control system will control and protect that particular unit."

Not all written descriptions are specific to any particular unit, or can be generically applied to any unit. Any written description (unless you wrote it or you know who wrote it, based on a review of that particular turbine control system's sequencing/application code) should be considered to be someone's belief of the intent for some unit at some point in time. GE DOES NOT rewrite written descriptions for every specific unit, and, in fact, supplies many generic and outdated descriptions in most manuals provided with the units they sell, and the turbine control system upgrades they sell.

It's a very good idea to read the provided system descriptions for intent--but for actual control and protection of any specific unit one MUST refer to the actual downloaded, running sequencing/application code. Many a manager , technician and operator has been lulled into a false sense of security by what they've read (or been told) and been surprised by the actual sequencing/application code.

Hope this helps! Looking forward to hearing what you discover in your examination!

Hi Guys,

CSA, thank you for detailed explanation.It always helps, more than manuals.

We used to jumper failed TC (Thermocouple) to nearest available TC TB wise, which you quite convincingly pointed is wrong practice. Will take care of that now.

One thing i want to add for Frame V Heavy duty Gas Turbine 13 Exhaust TC arrangement. I fully agree that, when one of the controller fails then machine does not trip, it will simply not consider failed controller TC inputs. Machine will be kept running.

Vimal Gupta has correctly pointed that there is trip provided when two adjacent TC fails. If you consider this, then TC No: 13 and TC No:1, are adjacent and both belongs to same controller R. (I am referring TC arrangement displayed by CSA, on 11-May-2017). So in this case, if R controller fails then machine would trip on adjacent TC Open trip. (I do not remember the exact wording of the alarm). For S and T controller fail, machine is safe (of course one at a time). But for R controller, machine would be tripped.

To correct this problem, OEM has issued TIL (Technical Information Letter) for customer asking them to change arrangement slightly. Instead of Connecting TC N0:1 and TC N0:13 at the same controller (Usually R) TC No:13 is connected S. Again (I am referring TC arrangement displayed by CSA, on 11-May-2017).

This way even if R controller fails, machine would not trip on adjacent TC open trip.

Vimal, as per your TC arrangement, TC No:1 and TC No:13 must not be connected to same S controller. As pointed earlier, in case your S controller fails it will trip machine. Contact OEM, and get this fixed.

Do let me know your feedback.

By vimal Gupta on 25 May, 2017 - 6:26 am

Dear CSA,

We have checked exhaust duct and found everything ok inside duct.
We checked faulty exhaust T/C and found sheath was cut. Both T/C TTXD_11 & 12 replaced with new one.

Frame-V machine with Mark-Vie control system supplied by BHEL & GE.
Machine was started yesterday 24.05.2017 after completed all checks. Load taken 3.6 MW as usual running load.

Today 25.05.2017 at 8:23 AM, we increased load 0.5MW and observed that at 8:26AM, TNR is reducing from 100.3 to 98.1 % gradually by auto L70L command actuation, machine speed was in decreasing trend, Generator frequency also went up to 48.7Hz.

Inter stage FPG2, SRV, GCV hunting observed during speed variation.

All that we started we started another GTG-2 for avoiding blackout. Mean while We given speed raise command L70R in GTG-1 and TNR reached up 100.3%. Now machine is stable, all parameters are normal. GTG-2 stopped after checking stability of all parameters in GTG-1. But we could not trace fluctuation of machine TNR & other parameters.

I checked all events, SOE & alarms and found only L70L active or normal alarms. No any other alarms observed. It is very difficult to paste trend record here to understand all phenomena.

1 out of 1 members thought this post was helpful...

vimal gupta,

Good news about the exhaust duct; and glad to hear you found the problem with the failed exhaust T/Cs.

TNR is the Turbine Speed Reference. You didn't say if you were operating with Pre-Selected Load Control active or not--makes a HUGE difference. On grids with unstable frequency it is NOT a good idea to operate with Pre-Selected Load Control--unless one has the Primary Frequency Response option from GE Response option in the turbine control system. When a unit is operating in Droop Speed Control (and most all units do when at Part Load (less than Base Load), the governor function of the turbine control system controls the amount of fuel going into the turbine based on the error between the Turbine Speed Reference and the actual turbine speed (TNH). When a turbine and its generator is synchronized (a VERY important word!) to a grid with other prime movers and generators the speed of ALL generators (and their prime movers) is a function of the grid frequency. (The formula is F=(P*N)120.) When the grid frequency is at or near design/normal, the speeds of all the generators (and their prime movers) synchronized to the grid will be very stable. When the grid frequency decreases, the speeds of all the generators synchronized to the grid (and their prime movers) will decrease, and when the grid frequency increases the speeds of all the generators synchronized to the grid (and their prime movers) will increase. And, when the grid frequency is unstable the speeds of all the generators synchronized to the grid (and their prime movers) will be unstable. That's how AC (Alternating Current) synchronous generators work when synchronized to a grid with other generators. And since the prime movers are usually directly coupled, or coupled through a reduction gear (but still physically coupled), to their generators the speeds of both the generators and prime movers are controlled (yes--controlled) by the frequency of the grid they are synchronized to. No single generator and its prime mover can run at a frequency (speed) that is higher or lower than the frequency of the grid it is synchronized to. Under normal conditions, no group of generators can run at frequencies (speeds) that are higher or lower than the frequency of the grid they are synchronized to. Yes--during starting and acceleration and synchronization the speeds of the generators and their prime movers can be higher or lower than the speed correlating to grid frequency--but once they are synchronized to the grid their frequency, and hence, their speed, is a function of grid frequency.

When Pre-selected Load Control is NOT active and the unit is at Part Load on Droop Speed Control and the unit load is table (meaning TNR is stable) and grid frequency is stable (meaning TNH is stable), the error between TNR and TNH is not changing--so the fuel flow-rate into the turbine is not changing (which is what's keeping the load of the generator stable). When an operator wants to increase load, even though he's watching the MW meter as he's clicking on RAISE SPEED/LOAD, what he's really doing is increasing TNR--which increases the error between TNR and TNH, and that increases the fuel flow-rate into the turbine which increases the load of the generator. When he clicks on LOWER SPEED/LOAD, he is decreasing TNR--which decreases the error between TNR and TNH which decreases the fuel flow-rate into the turbine which decreases the load of the generator.

The frequency of a grid is a function of the amount of generation and the amount of load (the number of motors and lights and televisions and computers and computer monitors). When the amount of generation equals the amount of the load--the grid frequency is stable and at rated. However, if a generator trips off line or a group of generators trips off line then amount of generation is less (or much less) than the load (the number of motors and lights and televisions and computers and computer monitors) and the grid frequency goes down.

If a block of load is separated from a grid (at some substation because some breaker or switch opens) then the load of the grid decreases with respect the amount of generation--which causes the grid frequency to increase.

When TNR is stable (and the load of the generator is stable) and the grid frequency changes, then TNH changes which changes the error between TNR and TNH which changes the fuel flow-rate into the turbine which changes the load of the generators. When this happens the turbine-generator is trying help support grid stability--because, when frequency goes down, TNH goes down, the error between TNR and TNH increases which increases the fuel flow-rate into the turbine which increases the load of the generator. That's what's supposed to happen. Contrary to popular (and false) belief--when grid frequency changes the loads of all machines operating on Droop Speed Control which are synchronized to the grid are supposed to change to support grid stability. Operators and Operations Supervisors and Plant Managers and Instrumentation & Control Technicians all believe their unit should remain at a constant load when the grid frequency is changing--and that's not true. The grid regulators rely on the fact that Droop Speed Control will operate to help support grid stability during frequency excursions. That's the way transmission and distribution systems are designed.

BUT, when a unit is being operated in Pre-Selected Load Control the turbine control system sees the change in load and says, "Oh NO! The load is supposed to remain constant, and I'm going to change TNR to return the load to the Pre-Selected Load Setpoint. I don't care about grid frequency or stability--my charge is to control load!" And, that's the OPPOSITE of what's supposed to happen. And, in fact, when the grid frequency is not at rated and a unit is operating in Pre-Selected Load Control, it is actually fighting itself and the load is even more unstable--which is affecting the rest of the grid.

Now, think about how many other machines are synchronized to the grid and operating on Pre-Selected Load Control when the grid frequency decreases (or increases)--and they become unstable, too. Well, that just contributes to the grid frequency instability--which affects ALL the generators (and their prime movers) synchronized to the grid.

Pre-Selected Load Control is GREAT for stable grids; it's BAD for unstable grids.

You mentioned TNR--but you didn't mention TNH. And, you can look in ToolboxST and see the "rung" (Function Block--in ToolboxST-speak) for L70L to see what's causing it to change. I would suspect, it's the change in grid frequency and that the unit is being operated in Pre-Selected Load Control.

P2 pressure (FPG2) is a function of turbine speed; the formula is: FPRG = (FPKGNG*TNH)+FPKGNO, where FPRG is P2 Pressure Reference; FKPGNG is the P2 Pressure Reference Gain, and FPKGNO is the P2 Pressure Reference Offset, and TNH is actual turbine speed--which is a function of grid frequency when synchronized to a grid. The Mark VIe controls the position of the SRV to make the actual P2 pressure (FPG2) equal to FPRG. So, if TNH is unstable (because grid frequency is unstable) then FPRG will be unstable and FPRG will be unstable and the SRV will be unstable. (FPKGNG and FPKGNO are Control Constants in the Mark VIe.)

The GCV position is a function of the error between TNR and TNH. And when both TNR and TNH are unstable, well, then both the SRV and GCV will be unstable.

This is only my guess, based on the lack of information provided about what was happening to the actual turbine speed (TNH) and the unit load (DW), and what mode the unit was operating in, AND, if there is any external load control which could be affecting the unit load--which is controlled by L70L and L70R.

L70L and L70R is how TNR is changed; L70L decreases TNR, and L70R increases TNR. One of the functions that controls L70R is the RAISE SPEED/LOAD button on the HMI. The LOWER SPEED/LOAD button on the HMI is one of the functions that controls L70L. If the unit is operating in Pre-Selected Load Control, that will also affect L70R and L70L. If there is some kind of external load control signal from some other control system that will ultimately affect L70L and L70R. You need to use ToolboxST to monitor both L70R and L70L to see what is making them go to logic "1"--because that's what causes TNR to increase or decrease.

By Chiranjeevi on 26 May, 2017 - 3:29 am

In MARK VIe system, 5, 4, 4 thermocouples are connected to PCAA R, S, T respectively. But each PCAA inputs will go to all three processors through IONET-R, S, T. If one PCAA card has failed, then it rejects those values for calculation of TTXM. But if two PCAA card failed TCs are failed. then what can be the value of TTXM? and four or more bad thermocouple alarm will come but will not initiate shutdown of GT, as link status of PCAA's to OK for SD initiation. So how each processor will calculate ttXM?


There has been LOTS written on about the exhaust temperature algorithm (block) and how many failed T/Cs will result in a trip. You are over-thinking the situation. (And usually, only Frame 5's and a few Frame 6B GE-design heavy duty gas turbines will have only 13 exhaust T/Cs; most units have more (18, 24, 27, and more).)

If one PCAA fails, I can assure you there will be LOTS of Diagnostic Alarms, and probably Process Alarms. All those thermocouples will be ignored by the microprocessor of the failed PCAA and by the other processors, as well. TTXM will be the result of the remaining exhaust T/Cs.

If a second PCAA fails, the unit will most likely trip. Critical I/O (like servo-valves and exhaust T/Cs and LVDTs and the like) are connected to each PCAA card. I doubt, except under very rare circumstances, a unit could survive and continue to run with a single PCAA card.

I believe it has been established in this--and other-thread(s) that if two adjacent exhaust T/Cs were to fail, then the unit will trip. And, if three non-adjacent T/Cs fail, on the failure of the third T/C the unit will trip.

As shown in the diagrams above in this thread, exhaust T/Cs terminated to the same PCAA card are NOT adjacent in the exhaust--even when they are terminated right next to each other on the same terminal board, or, adjacent to each other on the same terminal board. This is by design, as stated above, also. So, if two exhaust T/Cs fail, and they happen to be terminated adjacent to each other on the same PCAA, the unit will not trip.

The Exhaust Temperature Calculation block (usually TTXMVn ('n' refers to a whole number, like 4, or 3, etc.), you can find it in the application code using ToolboxST by finding where the signal TTXM is written to) has a 'Help' screen associated with it--right-click on the block and click on 'Item Help' in the pop-up window, and a description of the block will be shown in a separate window. You can print the 'Help' window (any 'Help' window can be printed), you can make a screen capture and save it to a MS-Wordpad file, and print the file later from MS-Wordpad.

If you want to understand how TTXM is calculated, you need to study the block's 'Help' file. Understanding "rungs" (Function Blocks) or algorithm blocks, like TTXMVn, is NOT difficult. It's really a matter of following a signal "through" the block as the various operations on the signal are performed. No; you can't see the operations or the results of most internal operations when ToolboxST is connected to the Mark VIe, BUT using your print of the internal signals you can decipher what's happening. It's really quite fun, and even easy, after you've practiced it a few times. And, if you have questions--we can always try to answer them (questions; not doubts).

No explanation from someone else is going to be as satisfying, nor remain with you, as solving the "riddle" yourself, and with the help of others. Using a print of the 'Help' screen you can make your own notes on the paper copy, and things will become infinitely clearer. Once you "solve" (learn how to read) this block, you are well-prepared to read others and understand them.

Unfortunately, we can't post text files or screen captures or .pdf files here on But, many people have used one of many different, free file-sharing services (including, and even to post files with relevant information and then post the URL (link) to the file so that we can open the files and see the information. You can use a .pdf file editor to mark up .pdf files with highlights or arrows or circles. You can MS-Windows Snipping Tool to capture a portion of a desktop or window or screen, highlight areas, save the file, and the post it to a file-sharing service and post the link in a response or thread here on Where there's a will, there's a way. So, if you have questions about what you see on a screen, there are ways to get them to us--just not directly via (yet; we are ever-hopeful!).

Finally, each processor calculates its own TTXM; I have never seen TTXM be different for different processors, but come to think of it, I've never looked to see if each processor could have a different TTXM. And, if I did see one or two or even three processors with a slightly different TTXM on a running turbine, I would expect that was simply due to the time lag in getting the data to the HMI and on the monitor. But because each processor uses the exhaust T/Cs (the valid values) from its PCAA card and from the other processors' PCAA cards (non-failed PCAA cards, of course) when calculating TTXM each processor should calculate exactly the same TTXM. The three processors in the Mark VIe are very tightly synchronized. They all read their inputs at the same instant in time, they share their inputs over the IONETs; they all perform the calculations and sequencing at the same instant in time, and they all write to their outputs at the same instant in time. (This is called a "scan"; and it's all VERY tightly synchronized in a TMR Mark VIe.) I would not ever expect TTXM to be different for any processor--UNLESS there were Diagnostic Alarms to indicate a problem with the processor(s) or the IONET(s) or some related card/signal.

Hope this helps--please get a copy of the 'Help' screen (the Item Help) for the TTXMVn block running in the application code of the Mark VIe at your site. (Right-clicking on Item Help when the unit is running WILL NOT trip the machine. Printing the 'Help' screen WILL NOT trip a running machine.) Make notes on your print-out. (In fact, make several copies of the print-out, and save them for later, for other notes or for colleagues.) Ask questions. We answer questions; doubts we don't do so well with.

1 out of 1 members thought this post was helpful...

We have 7FA's, each having 27 exhaust TC's with Mark V's as the control system. We've had numerous exhaust TC failures and generally do the following:

If the unit is running and cannot be shut down, we will replace the bad TC online, preferably during a non-peak time in case of a trip. Due to the possibility of disconnecting the wrong TC which would cause a trip (it will run with 1 bad TC, not 2), we'll have a control operator force the logic to prevent all exhaust TC trips. Then we'll replace the bad TC. (Note that we have had a CO force L4POST to a 1 instead of a zero, which initiated a trip so there is always the risk of a trip when doing online replacements.)

The earlier TCs which we call "the round heads" snap off when you try to remove them at the rate of about 3 out of 4. We have yet to be successful drilling them out of the "radiation shields" from outside the machine, so in that case we'll jumper the TC's using the protocol CSA described. Of course to do this online, we must force the logic to prevent a trip.

Note that the Mark Ve's have enough memory to run the more advanced exhaust TC failure detection software which GE says is a lot more fault tolerant than the existing algorithm. That would be nice to have.