GE Mark-II control upgrading


Thread Starter


We are planning to upgrade the Mark_II control system of GE gas turbine Frame 5 with latest and most reliable control system. I came to know that some PLC manufacturers are also offering their PLCs as a gas turbine control system and Triconex PLC is one of them.

Could you please share your experience in this regard?
I have one question: Would you use a Mark II to control the equipment in a plant which manufactured cement blocks?

If you answered, "No," then I ask, "Why would you use a control system which could be used to control the equipment in a plant manufacturing cement blocks to control your turbine-generator and its auxiliaries?"

This question has been asked many times on To apply a PLC as a turbine-generator control system requires many types of
converters: converters used to monitor speed signals (VERY important
in turbine-generator control; not so important when manufacturing cement blocks, so PLC manufacturers don't have high-speed frequency sampling so some kind of high-speed sensing converter is usually necessary. Flame detectors usually operate at 335 VDC; most PLCs can deal with these voltatges (either to generate them or to read them), hence another converter is required. LVDT excitation requires approximately 7.0 VAC RMS, and the ability to read approximately 3.5 VAC RMS from the feedback; most PLCs can't generate or read these signals, hence yet another converter. And, very importantly, the electrohydraulic servo-valves used to position the fuel control valves and IGVs require -10 to +10 mA signals, and most PLCs can only output 0-20 mA or 4-20 mA or 0-200 mA, so still another converter is required.

And that's just the hardware concerns. Don't forget: You have to have those converters in your spare parts, and some manufacturers have proprietary converters. So, while you think you'll be getting a control system that you can buy parts for from many different sources, some special converters possibly from a single source. So, your spare parts inventory will need to include more than PLC parts, and some may only be available from one source.

Several people have responded to these queries to say that the software written to control turbine-generators is less than optimal and fraught with problems. There are some very bright PLC programmers who have little or no experience with heavy-duty gas turbine generator and auxiliary control. Many people just don't understand Droop speed control, or CPD-biased exhaust temperature control, much less how to transition smoothly between the two. Sure, writing relay ladder logic to control auxiliaries is fairly simple, but it's the governor modes (Isoch and Droop), and turbine exhaust temperature control, and IGV control if so equipped. It's the combustion monitor and exhaust overtemperature protection algorithms that are difficult to duplicate and program in PLCs when the programmers aren't very familiar with turbine control, protection, and operation.

Triconex has many years of experience and has some hardware that is more well-suited to turbine control than many control system integrators who use PLCs for turbine control have; they also have some people who have done this before, which some control system integrators don't.

Before you buy any control system, spend a little time investigating how the supplier will handling the I/O peculiar to the turbine (servos, LVDT, flame detectors, speed pick-ups, etc.). Spend even more time asking questions about the software they will be providing, asking to see examples. And, most importantly, spend some time investigating references the supplier gives you. No; it's not pleasant calling around and asking pointed questions about equipment and service and support, but it's time well spent and if you don't you may be sorry you didn't. Even the OEM has some bad jobs many people know about, but their product is more suited to the application than most others. Implementation is important, just as suitability of equipment to the application.

There are many factors to consider, and it's not always an easy decision. All to often, the decisions are made solely on price, and that can prove to be a very costly decision over the long haul.

We'd like to know how you fare with your search; vendors you talk to, things you learn, etc. We can all benefit from this; that's a reason these forums work so well: many can benefit from the experience of one.

Bob Johnston

Yes, I have been involved with both MKII & MKIV upgrades using Triconex as a replacement and it works very well. What more do you need to know
I have noted your interest in the upgrade of MARK II control system for GE Frame 5 gas turbine and would like to inform you that Siemens is already in the midst of completing such an ugrade with the latest state of the art control system, Siemens SPPA-T3000.

It is categorised under Turbine Control System solutions R3000. The Siemens R3000
is offered at a very competitive price range.
Hi Bob,

We are planning for an upgrade from Mark IV to Mark VIe.

Appreciate if you could provide some more details in this regard

- How did the upgrade solution with triconex went
- How did you handle the software conversion
- Any warrantly issues from GE
- Any contact from triconex who supported you with the solution.

Thanks and best regards,
I believe that the MK I and the MK II are upgraded because no one wants to work on them.

I believe the MK I and all of the following Speedtronic systems are the ONLY turbine control systems for GE heavy duty turbines.

GE Knows how to build them and they Know how to Control them.

Everything else is a VERY POOR COPY!!!!!

Just an opinion.
We converted from Mark II to ABB/Bailey INFI90 DCS control of our 7EA STAG units (one common shaft for the CT, generator, and steam turbine). The nice thing about that arrangement is all turbine, HRSG and BOP systems are controlled by a single DCS using INFI90 function code. The down side, as CSA mentioned, was compatibility issues between INFI90 input modules and the existing LVDTs, which was never properly addressed. The units run, and that's all that matters.

Servo control was actually not a problem as there are INFI90 Hydraulic Servo Slaves that drive the Moogs (although the HSS's we have do have a nagging tendency to "amber lite" and quit working after unit shutdown requiring a hard boot before a unit can start).

ABB also has "universal" speed and vibration monitor modules that work well with just about anybodys probes/proximiters. Integrating the Bentley Nevada speed and vibration probes was straight forward.

The old Mark II used Edison UV-tube flame scanners, which provide both relay outputs and flame strength voltage outputs. The DCS looks at the relay outputs only. Our newer 7FA's use 4-20mA Reuter-Stokes silicon carbide photo diode scanners which the Mark V and Marak Ve convert to a count. Unfortunately, they require water cooling which has been their Achilles heal.

Note on flame scanners: ABB has a new photo diode flame detector that uses a remote fiber optic cable, allowing the 4-20mA detector/transmitter to be mounted up to 50 feet away, keeping the electronics out of the heat. At first glance, they might eliminate the need to water cool the detectors, which would be nice for our 7FA's. But GE is averse to any changes and as long as we have an LTSA with them it's not going to happen.

One disasterous consequence of using the INFI90 for total control was that our familiarity with the INFI90 gave us unfettered access to things that should not have been messed with. Mark V's cryptic nature and complexity tends to keep people out of trouble.

For example on one STAG unit, it was taking too long to establish flame causing the DCS logic to abort the start. To overcome this problem and give ample time to establish flame, the failure to flame trip timer was extended, keeping the ignitors on and the gas control valves enabled for a much longer period of time. (Whatever it took start the unit on schedule and unit availability were the driving forces, not safety.)

Unfortunately, the day came when the heavily contaminated Fyerquel lube/hydraulic oil fouled the SRV servo so badly that it could not move and would not open the SRV, so the CT tripped on failure to establish flame in spite of the timer extension. We changed servos two times but they quickly fouled. Rather then fix the underlying problem (contamined oil), we changed out one more servo and tried starting the unit one more time.

Naturally, the loop wound up in an attempt to move the SRV but the servo was stuck. The ignitors stayed on and the GCVs were enabled so long that when the SRV servo suddenly popped the SRV slammed wide open, flooding the unit with gas which, of course, exploded. The sides of the HRSG buckled out about 18 inches, catwalks were bent in an arc, access to the load tunnel became very tight, all of this costing big bucks in damage and downtime. Fortunately no one was injured, they just had the crap scared out of them. So much for unit availability and saving money on oil reconditioning.

In hindsight, the bad Fyrequel/sticking servo scenario had occurred in the past when the Mark II controlled the turbines, but there were no gas explosions because nobody had messed with the safety settings. As it turns out, the excessively long time it took to establish flame was actually the result of well intentioned "detuning" of the SRV PID loop, which had been been done in an attempt to smooth out SRV oscillations. (Detuning didn't get rid of the oscillations, by the way.)

When we employed some good loop tuning software, tuning the loop more optimally, flame was established within about 10 seconds. However, good loop tuning did not mitigate the SRV oscillations because the root cause of that problem was mechanical in nature, not something that can be tuned away.

The moral of this story is if you're going to break from the Mark X heard, make damn sure whatever control system you buy is from a company with proven success stories as told by real customers, not just salesmen. And keep the well intentioned, but uninformed tweekers away from turbine control safety settings because more often then not, they don't know as much about combustion turbines as they think they do.

As a result of the gas explosion, a new safety standard was implemented that requires root cause analysis of startup failures and unit trips, correction of the root cause(s), and management approval of any software parameter changes or setpoint changes which are now regarded as last resort measures. As Ben Franklin said so long ago, "Experience keeps a dear school, but a word to the wise is sufficient."


BTW, guys, GE now offer standard Mark II to Mark-VIe migration (or replacements, which would be the best way of putting it) packages with optimized cost and schedule.

So, talk to your local GE Rep, you might get surprized, since you can theoretically get the whole job done at the price of someone else's garage-made PLC solution.

Welcome, TurboYankee!

You've highlighted several good points about non-OEM turbine control systems, the most important being the ease with which people can manipulate things they shouldn't be because they can.

Changing Control Constants (which are adjustable parameters like timer setpoints and alarm limits, etc.) can be done on Speedtronic panels (Mark IV, Mark V, Mark VI, and Mark VIe) but it's interesting that more people don't do it more often. I think this is a sentiment which was also expressed by CTTech. People just seem so intimidated by the Speedtronic control systems that they just won't or don't want to make even simple changes to improve operability and reduce alarms.

But, when it's a PLC being used as a turbine control "system" there doesn't seem to be much hesitance for changing values without fully understanding the consequences in all circumstances. Even though had they changed the same value on the Speedtronic they would have had the same results.

It's not clear what results in people changing operations so cavalierly on a PLC-based turbine control system, and yet those same people who previously had Speedtronic turbine control systems wouldn't do anything remotely similar. Why not? For fear the wrath of GE would come down on them? (Their bark is much worse than their bite!)

The HSS modules you are referring to are really just proprietary interface modules to allow the DCS to handle polarity-sensitive servos that not many OEMs use. It's another source of potential problems, and another part to stock in the warehouse for spares. The LVDT compatibility issue is one of the most common problem areas for a lot of PLC-based offerings.

In reality, there are a multitude of concerns when choosing a vendor and product for retrofitting a turbine control system, or any process-oriented control system for that matter, especially those that control multiple systems and various types of instruments and sensors and even more critical when speed sensing is involved for overspeed and/or rate-of-change of speed sensing is required. If there was a spreadsheet or evaluation form we could download with weighted values for a multitude of variables that we could use to pick the *right* product and vendor, well, wouldn't that be great. Just like the one we use to choose our major purchases, like an automobile (a car, or a scooter for that matter; or a house or apartment). Oh, there aren't spreadsheets for choosing them are there? And if there were, wouldn't every manufacturer and sales representative be touting some option or feature that wasn't included on the evaluation or spreadsheet, or discounting the weight applied to this or that particular criteria or option or feature?

It all boils down to (drum roll, please): Personal preference, influenced greatly by cost and familiarity. There are lots of threads on on this topic (choosing control systems) and the sage advice from everyone has always been that the hardware and software from just about any manufacturer will suffice. The *real* intangible and one of the areas where the hidden costs are so unknown are the implementation and the service: Does the control system integrator have the knowledge and experience of the process and its variables and instruments to properly program the software to work with the hardware to reliably and safely (can't forget safety) achieve the desired goal of process availability, production, reliability, and maintainability? Will the control system integrator (which might be the OEM) provide the necessary drawings and materials for the plant personnel to understand, troubleshoot, and maintain the control system (since in this case, a control system retrofit, they should already be familiar with the process and the plant).

Best to spend your time investigating and coming to know the customers of the integrator/OEM who have experience with systems you are considering, since most can be made to do just about any job with some effort (some require more effort, and money, and time than others).

It would be interesting to know how many people ask, "Who makes the best control system?" or, "Of these three manufacturers, who's got the best control system?" and get these responses, and just feel like nobody really answered their question. I'd venture most, and yet the questions they should have been asking were answered, but nobody wants to put the effort into asking the hard questions of others who were in a similar situation at one point and now have the experience and knowledge which could be beneficial.

It really would be interesting to hear from some of the people who have originated these threads, to get their responses to the feedback they've received, and see how many have actually consulted other people who have been through a similar retrofit and received useful information for their decision-making. And how many just chose their supplier based on cost or equipment manufacturer?

At any rate, TurboYankee, welcome and we look forward to more of your insights and experience as we build our community here on
This sounds interesting, to say the least.

Do you have more details on "replacements"? What are they? I've heard of the Mark IV to Mark VIe Migration; and they re-use the plug-in portion of the Mark IV terminal boards and field wires and Mark IV control panel enclosure, and put Mark VIe components inside the enclosure. No need to determinate wires or remove the old enclosure and install a new control panel and enclosure and then reterminate field wires. Sounds very appealing for Mark IV-equipped units.

But the Mark II terminal boards aren't two-piece like the Mark IV terminal boards were, at least not the ones I've seen. They're going to have to determinate those field wires and then reterminate them.

It sure would be nice if we knew what "replacements" were, and other details you could spare. But thanks for the heads-up!


From the bitter experience of "downgrading" around 20 Mark II Speedtronic panels on 5002A,B and C turbines with Trisen (Tricon) I am telling you: "DON'T GO FOR IT!". You are asking for trouble.

Tricon is a TMR system designed primarily plant Emergency Shutdown applications. It is not a turbine controller. GE has Mark VI and lately Mark VIe Speedtronic controller which can provide the best protection for your turbines.

One of the nicest features about the GE systems is the direct interface to the turbine. When you use third-party systems, for many I/Os converters have to be used.

The algorithms available in the GE systems are created for turbine applications. If you use a Tricon for turbine control, it will be a rudimentary control. Creating all those advanced algorithms, if at all you succeed, available in Speedtronic systems will require immense work, resulting in a much higher scan time.
We upgraded one of our Mark Vs running a 7FA to Mark Ve (e for ethernet) in order to run the casing management software and associated blower, dampers, the multitude of casing temp sensors, etc. Mark V lacks the capacity.

Initially we had phantom CT trips that initially appeared to be related to transients in the DC power supply. We monitored the supply with a Dataq recorder and found no problems. It turned out to be a software issue that GE diagnosed and fixed. Beyond that, it's worked well.

The HMI software is a big improvement over the HMI software over the Mark V HMI from the standpoint of maintenance and troubleshooting. Processor downloads are much easier, IGV and GCV calibration is more advanced and still easy to use, and the rung display now incorporates tag descriptors. What a concept!

GE is finally offering a continuous engine tuning software upgrade that also requires the Mark Ve (or Mark VI) to run. (Siemens Westinghouse has had a third party continuous tuning package running on TXP for years that has worked well on our 501Fs. They really needed, too.)

Presently, engine tuning is done by GE remotely on a periodic basis for a fee. But combustor dynamics is still a problem with DLN 2.6, especially during our frequent startups. The high amplitude "shudder" that occurs during startup tears up the HRSG and duct burners and the no. 2 bearing tunnel sensors, conduit, mounting brackets, and so on. At $1,000,000 a copy, (talk about pride!) it had better work really well. The performance improvement may actually be worth it though, when you're spending 1/4 billion on gas each year and having to constantly repair the damage.
I have been away from Speedtronics for a while, and have become a bit rusty. I wonder if anyone may be able to tell me the difference/s between Mark VI and Mark VIe?
I have yet to see one, but have seen some drawings and have had a few minutes to look at the manuals. It appears the Mark VIe is a Mark VI which uses Ethernet for communicating with some kind of controller (called an I/O Pack) on the terminal boards. The large processor racks of the Mark VI (the 18- or 21-slot VME racks, one for <R>, one for <S>, and one for <T>) are gone, replaced by single board computers connected to Ethernet switches which are connected to the I/O Packs. The Packs seem to do the scaling of inputs and outputs and signal transmission to the microprocessors.

The terminal boards appear to be very similar to those used in the Mark VI. Instead of the large cables which connected the terminal boards to various VME cards in the processor racks, the packs plug into the terminal boards where the cables previously did and do all the I/O scaling and configuration instead of the VME cards and communicate with the processors via Ethernet (I think they call it the IONET).

Another interesting thing is that the processors and I/O packs run on 28 VDC (not 125 VDC or 24 VDC, but 28 VDC).

The processors are programmed and accessed using a new software application called ToolboxST, which is only slightly like Toolbox. It's more like CIMPLICITY/Proficy Machine Edition in its look and feel, which may or may not be better.

Why did they do this? My personal guess (and that's all it is since why GE does things is usually a mystery even to most GE employees) is that this is going to allow the I/O terminal boards (with the I/O Packs) to be placed just about anywhere the environment (temperature and humidity and vibration) will allow and all that's needed is an Ethernet connection (either UTP or Fiber Optic) to connect the terminal boards and packs to the processors (and 28 VDC power for the packs). In the future, we may see terminal boards and I/O packs in the skids, with Ethernet cables (UTP or Fiber Optic) connecting them to the processors instead of multiconductor cables, reducing installation time and cost. My concern would be the environmental considerations, primarily how temperatures will be controlled in some skids in some regions of the world. It would seem that some kind of "air conditioner" will be necessary, be it a typical compressor-driven system with evaporator and condenser (which will require maintenance on a very regular basis) or some kind of compressed-air vortex cooler (which will require dry instrument air and also regular maintenance).

Oh, and the <P> processor appears to have been replaced with something much smaller, which appears to be another benefit of this "e" suffix: since the racks are infinitely smaller and there's no <P> core (which was yet another VME-type rack with cards) the footprint of the control system can be reduced. (I'm sure we'll be hearing something about ecomagination and greening of the Speedtronic by using smaller components which require less power.)

There also appears to be some "new" HMI application to communicate with the processors, but they still use CIMPLICITY for the graphical interface (no improvement there most people will say).
>Pack) on the terminal boards. The large
>processor racks of the Mark VI (the 18-
>or 21-slot VME racks, one for <R>, one
>for <S>, and one for <T>) are gone, <

The original Mark VIe has a Compact PCI rack—only used for power. The latest Mark VIe (the UCSA) is a rackless, 5”x5”x1” box. :)

>The terminal boards appear to be very
>similar to those used in the Mark VI. <

Identical, actually. The I/O pack plugs in where the Mark VI cable used to go.

>The processors are programmed and
>accessed using a new software
>application called ToolboxST, which is
>only slightly like Toolbox. It's more
>like CIMPLICITY/Proficy Machine Edition
>in its look and feel, which may or may
>not be better. <

Ugh, comparing ToolboxST to CIMPLICITY Machine Edition? That’s a bit mean. :) ToolboxST is not all that different than Toolbox, it just does a lot more. The familiar parts of Toolbox are nested a few layers deeper in ToolboxST. There are less dialog boxes and more tables, which makes changes a lot easier and faster. There are more reports, and there are a lot of behind the scenes enhancements to the Mark VIe runtime.

ToolboxST and the Mark VIe were designed to be more DCS-like than prior generations, as the role of the Mark VIe has been greatly expanded from being a “black box” turbine control. The Mark VIe is being used for BOP in many plants, and is even used to control wind turbines and oil pipelines. GE’s goal is to be able to provide the entire DCS to customers that would prefer a single control system platform. There is also a SIL rated version of the Mark VIe system and a windows PC based Mark VIe Simulator.

>Why did they do this? My personal guess
>(and that's all it is since why GE does
>things is usually a mystery even to
>most GE employees) is that this is
>going to allow the I/O terminal boards
>(with the I/O Packs) to be placed just
>about anywhere <

Exactly right; if the plant is designed well, there is tremendous savings in wiring costs. Plus, pre-wiring a skid saves time on site and allows more in-factory testing coverage. Environmentally, there are a wide range of enclosures for different needs; it helps that the environmental specs on the I/O packs are wider than the controls themselves.

>reduced. (I'm sure we'll be hearing
>something about ecomagination and
>greening of the Speedtronic by using
>smaller components which require less
>power.) <

Probably with some cute animated elephant or something walking through a jungle hugging trees.

>There also appears to be some "new" HMI
>application to communicate with the
>processors, but they still use
>CIMPLICITY for the graphical interface
>(no improvement there most people will
>say). <

The HMI is based on CIMPLICITY, but the integration has been improved a lot over the Mark VI tools. There is a new software package (replacing TCI) called WorkstationST that provides OPC data to CIMPLICITY (or other non-GE provided software), as well as historical data collection, alarm viewing, time sync, and a bunch of other services.
Is your application a Generator application or a compressor application?

We have a lot of data on Control panel retrofit replacing old obsolete GE Controllers.
Hello everybody,

I'm new here and I hope someone can provide some input on Mark Ve (perhaps TurboYankee).

We currently have 2 Mark V panels, i.e. 1 for GT + 1 for ST.

From my reading, I understand that what Mark Ve does is actually a "brain transplant", i.e. you'll have the processing power of Mark VIe family.

Being a "half" Mark VIe product, Mark Ve can utilize one nice feature of Mark VIe - distributable I/O.

1. Does that mean we can "extend" our I/O (if need be) by having new panel and then link it up to the controller via Eth/Fiber?

2. I was told that Mark Ve cannot be deployed to a single-shaft CCGT machine. Is that so? Any specific reason for that?

3. Anybody here has any experience deploying OPC for Mark Ve/VI/VIe for the purpose of 3rd party historian system ie. PI system?

Can someone shed some light...
Dear dimster,

So many questions in such a short period of time.

1. Yes.

2. Don't believe everything you're told. Did you hear that from a GE representative? I've been told there's not yet a steam turbine version of the Mark Ve.

3. Matrikon claims all manner of things about GE Speedtronic turbine controls and HMIs. Use the search feature of; it's very powerful and can accept multi-word queries.
1. Yes. The even the Mark V I/O is accessed through a distributed I/O pack, so additional I/O is pretty simple to add.

2. I’d ask GE directly.

3. For the Mark Ve and VIe (and VI if you’re using ControlST to configure it and not Toolbox “classic”) you would configure WorkstationST for PI data collection. WorkstationST manages a number of services, including an OPC server and PI configuration. All you really have to do is turn on the Historian feature, select PI as the historian, and add the variables you’re interested in to a list (along with deadbands, etc). WorkstationST configures PI automatically. If you can get it, GEI-100628 is the instructions for the Historian feature in WorkstationST.
Control system is about a small CPU on your M Benz CPU controlling all panel and machine. As long as you still can control your M Benz why should you change your control system? It is just wasting the money for such capital investment. Nowadays there are some companies still supporting and servicing the cards, repairing the cards, also selling the parts. And if you have have any problem on this web site you can seek the information for the trouble you have.

Just visit for example.
Don't just think after the salesman of the latest control system, they only know to sell.