FactoryTalk vs MarkVIe

I am evaluating a technology right now that would require utilization of a FactoryTalk HMI system for turbine controls other than MarkVIe, to which my operators and engineers are accustom to.

Does anyone here have direct experience operating these systems that can provide some input on the pro/cons of this system, what you like, what you dont like, certain options we should exercise that we might not know about, etc?

Thanks in advance!
 
GilbertGrape87,

Congratulations, you are embarking on a journey MANY have started, and few have successfully completed. Can a PLC (Programmable Logic Controller), also known sometimes as a PAC (Programmable Action Controller) be successfully used as a turbine control system or a DCS (Distributed Control System) instead a GE Mark* control system and GE Mark* HMI? Hell yes!

All you need is at least one person who is very knowledgeable in controlling and protecting turbines, auxiliaries and driven devices (generators; centrifugal compressors; pumps) AND is also knowledgeable in configuring and programming the desired PLC/PAC and desired HMI. That person (or persons) needs to also know how the inputs to the control system work—and are wired to the existing control system, as well as how the outputs of the control system work and are wired to the control system. That includes understanding how to successfully interface the existing I/O (Inputs and Outputs) to the desired PLC/PAC, which may require signal converters and/or outright replacement.

If this is a team, the person or persons who has this knowledge must be capable of communicating with the other members of the team and coordinating their efforts. (Many engineers know what they know, but aren’t very good at communicating that to others. What’s obvious to them isn’t always obvious to others, and things fall through the proverbial cracks.)

Finally, if the application the control system will be used on includes—or may possibly ever include—emissions reduction combustion systems that requires a very detailed degree of understanding and knowledge to be able to reproduce. And, many OEMs simply WILL NOT write a program for emissions reduction equipment in a non-OEM control system—forcing the newly installed and commissioned control system to be removed and replaced. (Ask me how I know this. From painful, personal experience.)

The electrical wiring drawings for such a replacement will consume many unexpected days and weeks of effort. That’s even if the site has the original drawings and they have been kept up to date over the years.

This is not impossible, and it has been done with varying degrees of success. If all you want is a more user-friendly operator interface—there are ways to achieve that. If someone thinks that by replacing the GE Mark* with an OTS (“off-the-shelf”) control system that is more familiar for site personnel than the GE Mark*—and therefore will be easier to troubleshoot and maintain, well that’s just faulty thinking. Because regardless of the control system the people who have to use it to maintain and troubleshoot the turbine or plant STILL have to know how the equipment works, and what’s supposed to happen when and what’s not supposed to happen when. And an OTS control system isn’t going to make that happen overnight. Or over a fortnight. Or even six months. And if the equipment being controlled and protected isn’t properly maintained (or isn’t maintained at all—until something breaks), a new, more familiar control system is not going to improve a lack of maintenance or no maintenance.

A LOT of sites go through this process and end up being over-ridden by upper management who end up buying OEM stuff in the end. Why? They have deep pockets and, usually, somehow, eventually the project gets “finished .” Not always to everyone’s satisfaction or on schedule or to budget or even correctly—but no one in upper management ever lost their job buying OEM equipment. They might if they choose a newcomer to the scene who makes a bad, unintentional mistake and craters a machine (or worse). If the OEM does that (and it’s come very close on multiple occasions), they can fix the problem with their insurance and parts availability.

Best of luck in your endeavour. Again, it’s possible, but very often the results are not very good. And, sad to say, more often than not, upper management makes the final decision and opt for the OEM solution in the end. Which is very bad for plant morale.
 
Thanks for the thoughtful response!

Fortunately, I've got some good news: this is not a retrofit, but rather a new construction. As such, many of those obstacles go away as the division of responsibility is such that the EPC would be responsible for control system integration. So if I were to assume that the system is commissioned appropriately, I was hoping to determine what the day-to-day differences are within the interface. Stuff such as:

- Is the FactoryTalk HMI laggy or less responsive than Mk*?
- If thin clients are used do they have poor monitor support in terms of refresh rate/resolution/# of monitors/etc
- Are there networking limitations that Mk* doesn't have?
- Are SOE/DDR systems user friendly and do they have appropriate capture rate resolution?
- Does AllenBradley/FactoryTalk utilize OPC to communicate with PI historian systems?
- How do scan rates compare?

Just looking for an overall qualitative review from people that have operated and/or maintained both systems.

Thanks again for your thorough response, I really appreciate it.
 
gilbertgrape87,

I knew it was going to be something like this. And, I also knew the information provided was going to be ... thin. To say the least. We don't know if you're talking about a DCS or a turbine control system (but I presume DCS, since it's EXTREMELY doubtful GE would warrant their turbine(s) without a GE Mark* turbine control system).

Even if you wanted a seamless integration between turbine controls and the DCS, you wouldn't get it with GE Mark* controls. Why? Because the GT engineering group configures/programs the gas turbine controls using one method, the ST engineering group uses a slightly different method, and while they both predominantly use FBDs (Function Block Diagrams) they use different naming conventions and some slightly different philosophies. AND, the DCS group uses an ENTIRELY different method altogether (SPC (Sequential Programming Charts, I think it is)) and very different naming conventions and controls philosophies. It's a real kludge of a system, and sorting it during commissioning can be a real rough job for even experienced personnel.

And you want to try to make the plant operation "easier" by using FactoryTalk as the operator interface on the HMIs and for the DCS? Good luck with that. You do know that GE doesn't allow ANY control system to communicate directly with the Mark*, right? (Yes, there are some MODBUS interfaces that bypass the HMI, but MODBUS has huge limitations--and NO ONE, in their right mind, anyway, would try to use MODBUS interfaces between a DCS and digital turbine controls to operate a plant of any sophistication (Combined Cycle; LNG compressor(s); etc.). To begin with, MODBUS doesn't have controller time-stamped data/alarms/events.

I'm not even going to try to answer your questions about thick/thin clients (GE's implementation of them is obtuse, complicated, and poorly documented--no surprise; instead of simplifying their control system networks they are complicating them, and while some of that is understandable, it's just poor engineering in so many ways). The newest GE Mark* HMI displays are pretty fast (because they basically run a "reduced" version of PROFICY Machine Edition "viewer", I think). As far as networking limitations, just about anything is possible if you have a good IT department and follow safe networking practices. I DO NOT suggest using the World Wide Web/Internet for remote operation--especially with what's going on in the world at this instant. The SOE that GE uses is good to 1 msec (for discrete inputs). If you want to know what FactoryTalk can do, you need to consult their documentation. They probably use OPC for communication, but if you want to use a PI system, best of luck. That's another whole can of worms that I refuse to open. Scan rate comparison? I don't know what A-B software can do. GE Mark VIe can easily do 40 msec, faster for some specialized turbine applications.

Hopefully you can get more definitive information from others on this forum. Me? You haven't provided enough information for me. I do not recommend trying to use a PLC/PAC for turbine control--ever. Just because it's programmable doesn't mean it's well suited for turbine control (high speed rotating equipment). Would you use a GE Mark* in a warehouse setting? Or a chicken processing plant? (I wouldn't--even though it could probably be made to work properly, it isn't the right controller for the applications. And a PLC/PAC isn't really the right controller for a turbine control application, either--no matter what the salesperson says.) DCS? Sure; why not?

Best of luck!
 
There are undoubtedly some strong opinions on your end, which you are certaily entitled to, however I have seen successful PLC turbomachinery control implementation before on various machines (various models Solar Turbines immediately come to mind) and satisfactory PI system integration across PLCs, Foxboro, Ovation, Mk*, T3K, and other systems. Also important to note that I'm not suggesting or expressing any opinion of whether the FactoryTalk HMI is better than the GE system. In fact the whole reason for my post was because I have no practical experience with the FactoryTalk HMI system and therefore no way of having an opinion. (For the record, I am discussing PLC TCS implementation.)

I was simply looking for some antedoctal information from someone who has real world experience operating or maintaining both to get a sense of what they liked and didnt like about each and its perfectly OK if you dont have the requisite experience to comment on that.

Since were on the topic however, what philosophical issues do you have with PLC control of turbomachinery? I admittedly didnt have huge involvement with it, but I did at one point in my career have direct access with SLC500-controlled gas turbines (later upgraded to Contrologix), and those involved did not appear to have complaints with it.

Thanks again for your input.
 
I wouldn't normally comment on GE Mark* control systems as not my area - but would take issue with CSA [as
gilbertgrape87 has done] that PLC's are unsuitable for turbine control. I would however agree with most of his other sentiments.

Siemens Turbomachinery [UK] has been using both Rockwell and Siemens PLC's for decades without major issue; and if there were there is always a 'workaround'.
Personally I believe there is very little difference between the 'high end' [expensive big name] control systems, PLC or DCS.

For Rockwell the mention of FactoryTalk HMI isn't particularly relevent since you can use other HMI's, in the same way Siemens doesn't have to use WinCC HMI.

It's not a point of what they liked and didnt like about each, rather what the end user requests; and generally that depends where the end user is in the world.
 
gilbertgrape87,

SOLAR's implementation of A-B PLC hardware is really NOT a good example of PLC for turbine control. SOLAR have developed special modules for their units to use with the PLC. This negates one of the big reasons for using "off-the-shelf" PLC hardware--there are proprietary modules for almost every PLC implementation for turbine control. Some of the modules SOLAR developed are NOT available on the open market--only from SOLAR and occasionally from A-B.

Even the Siemens turbine control is really just a STEP-7 PLC with a special module for servo-operated devices that requires special software that ONLY Siemens can provide--and they won't sell it to a control system integrator.

Configuring and setting up a PI system is very time-consuming. Usually it requires one or two people dedicated to the task, and those people end up being the ones everyone goes to for getting data from, which makes the system unavailable for some personnel. It's a very powerful system--but it's so complicated and, again, requires training and experience, usually a lot of both to get to even basic usefulness. Yes, it's customizable, but again that takes knowledge and experience. And, generally I find PI-based systems not to be very good at high-speed data gathering--which can be very important for turbines and auxiliaries.

Most implementations of PLCs/PACs end up using lots of signal converters--because most PLCs/PACs aren't built for I/O like LVDTs and bi-polar servos and Geiger-Mueller flame detectors and velocity vibration sensors. And, even speed pick-ups--these are the sensors which usually require proprietary cards for PLCs/PACs.

I have seen some critical PLC programming on turbine controls that was barely adequate--especially for important things like transitions from Droop Speed Control to CPD-biased exhaust temperature control and back. This resulted in machines that weren't producing as much power as they could have. I've seen machines that would start when someone initiated a MASTER RESET when the unit was at rest, or would trip if a MASTER REST was initiated when the unit was running. I've seen redundant Low-Low L.O. Pressure switches replaced with a single L.O. Pressure transmitter (introducing a single point of failure). And I've seen A-B dual redundant systems that wouldn't handle control switching properly, resulting in turbine trips and failures to be available for start/operation. I've seen multiple over-writes probably done to try to correct previous poor programming, leaving a lot of clunky and confusing programming to try to sort through--by control system integrators who weren't welcome back on the site or had gone out of business.

Having said all of that, I've seen some very questionable programming on GE Mark* turbine control systems which resulted from trying to put every bell and whistle in the program causing some weird combinations and odd alarms and trips. And, the GE Mark* HMIs are getting worse and worse with every iteration--LOTS and LOTS of buttons that don't work after commissioning, and buttons that just aren't on the displays, or mistakes in animation.

GE is a mere shell of its former self, and its disappearing before our eyes. They use more and more contractors and less and less employees--for just about every aspect of the equipment, including controls. The Mark VIe--while a fine product--is getting old. And, as with just about any microprocessor-based controller as the chips that were used in the original designs are phased out by the manufacturers GE has to scramble to develop new modules based on new chips--and sometimes these are incompatible with older equipment.

My dislike for using PLCs/PACs for turbine control applications is that the GE Mark* is a purpose-built controller--it's specifically built for one thing: high-speed rotating equipment control and protection. It can perform generator synchronization, primary- and back-up overspeed protection (electronically), centrifugal compressor control and protection, as well as turbine auxiliary control, including NOx emissions reduction systems. Any other controller being used for high-speed rotating equipment control l and protection is going to require additional, in some cases, third-party, modules and signal converters. And, while that's all just hardware and not impossible--it adds to the complexity of the system. The GE Mark* does it all in one system--hardware and software.

And, therein lies the real reason for using GE Mark* for GE turbine control and protection: GE knows how to program their control systems to properly control and protect the turbines, including Droop- and Isochronous Speed Control, CPR-biased exhaust temperature control, fuel control, steam control, etc. Unless the people programming the PLCs/PACs are familiar with all of these things, they might be more than capable of replicating the sequencing of pumps and fans and solenoids and such in the controller. But do they know how to write code for bumpless transfers between operating modes and emissions controls and IGV controls and steam turbine control and bypass valves and intercept valves? I have seen some REALLY EXCELLENT PLC programming--but it wasn't done with the correct idea in mind for optimal turbine control and protection. It's NOT about the hardware, or even the software--one MUST know what's supposed to happen when, what's NOT supposed to happen when, and understand how to make multiple systems operate as one. It's that experience that differentiates the GE Mark* from PLCs/PACs. Again, it can be done--it HAS been done. But, is it really proper control and protection? Does it allow for optimal operation of the unit, and optimal parts life? How many systems have to be cobbed together to make one turbine control system? (The PLC; a third-party overspeed protection system; interfacing the PLC and and the overspeed protection system; a synchronizer (automatic and probably a synch check relay as well); the flame detectors; the vibration sensors (velocity and probably proximity type as well).) It all depends on what the control system integrator decides to use--but there's NOT a single turbine control system anywhere like the GE Mark*.

And, lots of nay-sayers say, "The GE Mark* is a "closed" system!" And that's just hogwash. Are they making it more difficult with macros and ARES (Adaptive Real-time Engine Simulation)? Yes, but it's not impossible. It just takes rolling your sleeves up and digging and making an effort. And most people just don't want to do that. They want YouTube videos and self-healing alarms, and what they really want is someone else to do the troubleshooting for them. Sure; the GE documentation could be a LOT better. But, you're not going to get anything better from a control system integrator--who's probably having to figure out how it's all supposed to work to put the controls in the new system, and may or may not understand all of it. And, GE's not going to give anyone a hand.

You said "TCS"--did you mean DCS (Distributed Control System) or TCS (Turbine Control System)? If you were going to buy a GE Mark VIe DCS system, I'd say you would be better off not. For the reasons I've already outlined in a previous response. Sure, you might have similar hardware which might mean fewer spares, but it doesn't usually work out that way very well. The DCS people use different modules and different programming, so that's not a good reason. Again, I'd say don't do it (a GE Mark VIe DCS).

If you're talking about convincing GE to let you (or anyone) put a PLC/PAC on a new turbine instead of a GE Mark* system--that's probably NOT going to happen. Again--because of the warranty issues if for no other reason. You want to provide your own warranty? I'm sure they'd let you do it then. Will the banks and insurance company like you providing your own warranty? Probably not.

Anyway, I've wasted too much time on this. Best of luck. Everyone has an opinion. (Everyone has an anus, too. Very few are perfect; most have hemorrhoids.)
 
Top