Today is...
Wednesday, September 19, 2018
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
Mark VIe integration with DCS HMI
Possible solutions to integrate the turbo generator control and protection system (Mark VIe) with existing Delta V DCS and HMI.

Hi, everyone.

We currently have a Mark VI PLC for one of our turbo generator control and protection (frame 6B) which uses a Cimplicity HMI (supervisory) for the monitoring and operation.

However, this is the only Cimplicity supervisory of our entire site, which means we need to have a dedicated HMI for it, it is not integrated with our Delta V DCS, operators have to learn and deal with two different systems and also Automation has to support this different system.

We will migrate Mark VI to Mark VIe in 2 years (next major), and we would like to verify the possibilities of communicating it with our Delta V system. Do you have similar experience with that? What would be available from Mark VIe to establish this communication? Modbus TCP? What do you think?

We consulted GE about it, but they are terrible in providing answers. Also, it seems they are not interested in not selling the Cimplicity application as a turn key, so it is clearly a lack of interest of them to help us in this solution.

Thank you very much for any help you may provide.

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


These are good questions. I wish I could say that GE is better at support than your experience.

Mark VI/VIe supports a whole heap of protocols....In reality it is the software. I would recommend doing the communication through the HMI. This allows for more diagnostic testing and flexibility. Although, you can go through the Mark VIe controller. The controlST software will get you most of the way there. It supports, OPC-UA, OPC-DA, GSM, EGD & Modbus. If you want to get more protocols for specific PLCs (i.e. AB, ovation, ABB, etc) you can add on the IGS kepware software that can seamlessly sit on ControlST.

Cimplicity can also do the integration between systems, but I am not a big fan. It takes 'custom' configuration on both sides to get it to talk. Since you are using mark VI or mark VIe, ControlST automatically takes care of the configuration on one side.

There are still numerous questions that you may want to ask: redundancy, speed/latency, auto-reconfiguration, robustness. This will help you get a better idea for the architecture.

I happy to dig into more detail and discuss if you have more questions.

In summary, any integration can be done to fit your sites needs. You just need the expertise.

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

Thanks, ME42, for the information!

There really aren’t that many options that don't involve "going through the HMI." GE intended it to be that way, because they don't want "just anyone" communicating with--and sending commands to--the Mark* controller(s).

There was a very recent case where a DCS that was improperly configured was BOMBARDING a Mark V with commands and requests for data through an HMI, no less, at a very fast rate and it was ultimately determined that it lead to a very serious loss of lube oil and damage to the bearings and the unit. (It should be noted that the site was aware of communication issues between their DCS and the Mark* through the HMI, but chose to run the unit without resolving the issue(s). This was erroneously attributed to the Mark* control system, but was, in fact, caused by DCS communication link problems.) So, even with communication limited to going through the HMI there can still be unwanted consequences if not properly configured--and there's just about no way around that, unfortunately.

Since you will be going to Mark VIe from Mark VI, if you can't wait for the Mark VIe "upgrade," it would probably be best to consider using MODBUS over TCP. But, that has to be done through the HMI for the Mark VI. I believe the Mark VIe has a module that can be used to pass data as well as commands over MODBUS directly to the Mark VIe. (I don't have access to GEH-6721 at this writing, so I can't check to be sure. I think the module/pack is the PSCA , but I don't know this for certain. Look in Vol. II of GEH-6721 for the communications module, and then check the capabilities of the module to see if it can actually accept commands via MODBUS.)

The thing about using MODBUS with the Mark VI and then the Mark VIe (presuming the PSCA module can handle commands) is that one would have to configure the Mark VI HMI to handle commands via MODBUS, then there would have to be a change when the Mark VIe and PSCA were added. Both are likely going to require GE or a control systems integrator, such as CSE Engineering, Ind,, or, SISO Engineering, LLC,, to implement.

I don't think GE generally advertises this capability for control, and, again, I'm not sure the PSCA is fully capable of unit control (commands such as START, STOP, etc.). And, it would most likely be non-redundant control, also.

The "things" (issues) with MODBUS communications are that one doesn't get all alarms (NO Diagnostic Alarm information, except the presence of one or more Diagnostic Alarms), and no time-stamped data or alarms. Those are really pretty big issues for people who want to all their control and troubleshooting (data storage and retrieval) via a separate HMI.

You will always still need a PC configured with Toolbox or ToolboxST to do any real troubleshooting, LVDT calibration, changing I/O cards, any downloads, etc. It doesn't have to be running CIMPLICITY to do that. And, with the advent of ControlST (WorkstationST), there is a new alarm display and sorting/filtering capability: WorkstationST Alarm Viewer. It is VERY powerful, but it does take some getting used to and configuration. It would be a very great loss not to have that capability when troubleshooting alarms for many unknown trips or problems.

Your choices if you have to have something now, and can change later, are a little more open--but still need to go through a GE HMI. GSM (GE Standard Message protocol) is available on the Mark VI HMIs that run TCI (a proprietary background service), and it uses Ethernet cabling. I don't know if GSM is still available via Mark VIe. But, GSM would have to run through a GE HMI. It has time-stamping and alarms, but it's not always user-friendly. And, as will all things GE there is a "limit" to how many signals can be transmitted (and that limit is usually "determined" when communication issues are encountered--meaning, GE doesn't even really know what the "limit" is).

You can use some OPC software for some communications, but it's my understanding that no OPC implementation can handle GE alarms and events. So, no Process- or Diagnostic Alarms can be transmitted over OPC from a GE HMI. Best to ask any OPC vendor who claims to be able to communicate with a Mark*--because "communication" can mean different things to different people. (As in, data communication can be different from data AND alarm communication! All communications are NOT equal!!!)

Hope this helps! It's best to delineate exactly what you want your operators to be able to do from their DCS HMI when operating or monitoring the operation of the GE Mark* controlled turbine(s) (for example: monitor turbine operation; send commands to START, STOP RAISE- or LOWER SPEED/LOAD; respond to Process- and/or Diagnostic Alarms; retrieve archived data; etc.). And, then start asking different vendors and control system integrators what the capabilities of their systems are, and then get references where they've done this before, and check the references. (This last part is the hardest, but I can tell you--many people didn't do this, and then discovered in conversations with other sites who used the same equipment/supplier after the installation and commissioning that they have similar unresolved issues. It's NOT the equipment--it's the supplier. It's really the experience level of the supplier or integrator with GE turbine control equipment. A lot of people can do some really AMAZING things with various PLCs and control systems, but when it comes to integrating them with GE turbine control equipment they just don't have the expertise to do the job. Check references--it might be hard, but in the end, it will probably be well worth it.)

Please write back to let us know how you proceed, and what you learn. A LOT of people read these threads and follow them, and the information you can provide might be very valuable to them. Myself, I'm always interested to understand people's decision-making process, and to learn from other's experience(s).

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

Frequently with a Mark VIe turbine control system the plant DCS isn't from GE (though obviously GE would love to sell you the plant DCS as well, they most typically do that with new plants) so this isn't an unusual situation, so I'm surprised you're not getting good answers. It probably has to do with which branch of GE/BHGE you're talking to, as there are some groups only doing new units and some groups only doing retrofits.

Anyway, the communications with the DCS is usually through WorkstationST, a server that (among many other functions) acts as a gateway. This role was filled by the TCI software in the Mark V and early Mark VI era. WorkstationST communicates with the Mark VIes via its native EGD and Alarm protocols, and can provide data to the DCS via OPC DA, OPC UA, Modbus, or a number of other standard protocols.

Communication from the DCS to the Mark VIe can also be done via 3rd party gateways from companies like Triangle Microworks, usually EGD to OPC DA. I've also seen Modbus TCP slave configured on a Mark VIe to get data to the DCS more directly, but don't know how common it is. I don't like that approach as you have to touch the Mark VIe configuration to set it up, but it takes a Windows box out of the loop.

Hope that helps!

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

All Good Stuff.

If I can summarize some of the comments and rank in my preference order

* OPC-UA communication through the HMI (ControlST)

* Modbus Communication through the HMI (ControlsT) need to hand code status bits

* OPC-DA communication through the HMI (ControlST w/ added Tunnelling software) can use OPC-AE which carries alarms

* Modbus communication through Mark VIe & PCSA - need to hand code status bits

* GSM Communication through the HMI (ControlST)

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

Your question is very specific. You asked about communication between the DeltaV and MK-6e. We have six MK-6e 7FA combustion turbines (Migrated from MK-5) - they are in isolated 1x1 combined cycle blocks.

For all 6 of these blocks we are using redundant TCP Modbus directly between the MK-6e controllers and the DeltaV using the DeltaV "M-series Virtual I/O Module 2".

The specific setup is 2 of the DeltaV modules for each unit talking to the <R> and <S> MK-6e controllers, DeltaV is the master with the MK-6e the slave. The DeltaV is setup to switch between the slaves if one ceases to be present and testing showed it works very well. The network connection is to the PDH, yes the MK-6e controllers are connected to both the UDH and the PDH.

TCP Modbus to the MK-6e controller is very easy to setup in toolbox and it has been very robust - has been in service since Fall, 2016. However, the GE sales people are selling a system they do not understand the capabilities of - there are plenty of technical people within GE that know of the capability but you will be hard pressed to get GE to quote it unless you already know it can be done easily and demand it persistently - or do it yourself.

The GE sales force wants to force you to use GSM or Modbus through the HMI which is not a robust communication path. Ours were implemented by GE as part of the migration - the specific person who did the configuration works in the Longmont facility.

Additionally, we are using the same arrangement for 3 1x1 blocks with an ABB DCS at another plant.

Well, I couldn't be happier about all answers and contributions. Thank you all VERY much for this!

As I mentioned, we are on this project to migrate Mark VI to Mark VIe and we expect to finish everything (including the migration and start up itself) in 2 years. The schedule is because GE requests 18 months for manufacturing and supplying a new Mark VIe, as they informed us.

But I will for sure update this post here as the project goes by, and I hope it can help others also.

Thank you very much again for your time.

I am shocked that GE would take 18 months to do all the upgrade work. Make sure you keep pushing them. I would imagine the timeline to be closer to 10 months. And even then, that is giving them a long long time. Also, I am assuming your plant is <3 GTs.

Also, keep in mind that you can still do any integration work with an HMI (& ControlST). Even if you still have Mark VI only. GE will probably charge a lot of money for that HMI work, but it is not very technical. The integration work can be done in a few weeks. The longest lead time is ordering the PC hardware.

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

I have to agree with ME42--18 months seems ... abnormally long. There must be something we're not knowing about this. I know of recent Mark VI-Mark VIe platform upgrades (not a full-blown rip-and-replace--and I'm not sure exactly what you're getting: a platform upgrade or a rip-and-replace) that were done in less than six months. Maybe they are having sourcing/lead time issues with some of the platform upgrade components....

Just a couple more things to note here, RRA. A "platform upgrade" is what GE is really pushing for Mark VI to Mark VIe. It's not a rip-and-replace upgrade, where all the field wiring is determinated from the Mark VI, the Mark VI is removed from the PEECC/enclosure, a new Mark VIe turbine panel/enclosure is installed, and all the field wiring is re-terminated. This requires full loop-checking, also. It can be done in a couple of weeks, if coordinated properly.

A platform upgrade removes the processor racks and the <P> core from the middle panel of the Mark VI, removes all of the black cables that connect the I/O terminal boards to the processor/<P> racks, and installs a few new I/O terminal boards, Mark VIe I/O packs on the I/O terminal boards, and new processor and <P> components and IONET switches and Ethernet cables to tie everything together. It can be done fairly quickly (the "conversion" to the Mark VIe hardware and software), and only requires spot-checks of critical I/O.

Some Customers have been VERY surprised to learn what they actually bought when they see the platform upgrade being installed. The salesperson said they were getting a "full-blow Mark VIe"--and while what they got is Mark VIe-compatible, it's not exactly the same as a "full-blown Mark VIe." And, it wasn't cheap, either (though I hear GE is pricing rip-and-replace upgrades at ridiculous prices which "persuade" Customers to do the platform upgrade--if the Customer knows enough to ask for the rip-and-replace).

I don't have much experience with the Mark VI-to-Mark VIe platform upgrade, but I know people who have spoken highly of it. I think it all hinges on the caliber of the people doing the upgrade and commissioning.

About "operating" a unit from a third-party DCS HMI, a LOT of people make a LOT of assumptions about this. The biggest assumption is that communications is communications--meaning that if they can see operating values and send commands that they can get alarms on the DCS over whatever link is being used. And, that's just not always so. GE uses proprietary protocols and methods for alarm and event transmission between turbine control panels and HMIs. The data/command part of communications is pretty simple; it's the alarms that are not.

So, be really specific about what it is you want to do--don't make any assumptions when talking with GE or any vendor about this "communication link." There are lots of ways of getting data from and sending commands to a Mark*, but it's the alarms/events that isn't so easy or common. People, again, ass-u-me that it's all the same communication thing, but it's not.

demigrog2 and ME42 and mhwest seem to have some insight about alarms that I haven't heard before--for Mark VIe. I'm pretty sure there are only a couple of non-GE suppliers/integrators that can do Mark V or Mark VI alarm/event handling/display. And Mark VIe is even more "proprietary" than Mark V or Mark VI. I hope demigrog2 and ME42 and mhwest can provide more information about alarm/event handling for Mark VI and Mark VIe with third-party HMIs/DCSs.


I think you must have misunderstood something along the way. I don't believe you will find any post from me that indicates I am aware of anyone in the industry who has develeoped a non-GE interface to MK-6e which can get alarms and events from a MK-6e.

The orginal post that began this tread was simply asking about interfaces between the MK-6e and the DeltaV DCS, and I described the GE implemented modbus links directly between the MK-6e controllers and the DeltaV at 2 of our plants as well as ABB Inf90 at another plant.

We have used extensively a non-GE OPC server supplied by Prism Systems for MK-6 and MK-6e which does get alarms and events for MK-6, but it of course does not work for alarms/events from the modern MK-6e systems. We are using it as a historian gateway for all of our MK-6 and MK-6e fleet. We started using it long before the more recent Kepware products came into existance. Those may work better I don't know - but as far as i know the kepware products are EGD only and will not get alarms/events either of course. Since we are not yet using 3rd party HMI's on our MK-6e units there has been no reason to try to see if there is a way to do it - I expect there is and somebody will figure it out and if so there will be a market for it.

Again, to be clear I am not aware of a 3rd party communication interface to the modern MK-6e that will provide alarms and events.

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


As I near retirement I am more and more aware of slight communication issues that have--and do--cause serious misunderstandings, and a lot of wasted time, effort and money. I'm 1000% certain the original poster assumes if data and commands can be communicated between the Mark* and the Delta V then certainly alarms, events and time-stamps are included. I'm only trying to clarify--for myself, and anyone reading this thread--what is currently available, both from GE and third-party vendors and control system integrators. I didn't misunderstand anything; I just want clarity. Thank you.

GE is doing their level best to make at least the alarms, events and time-stamps as proprietary as possible. It's understandable, if shortsighted to many. When one really considers how catastrophically wrong things can go with a single bit out of order or the wrong vslue, and how much it would cost to test and certify every control system interface every Customer and EPC and integrator wanted to implement in place of the GE Mark* HMI, it would become clear that it's not as simple or as inexpensive as it seems at first glance.

I'd contact Delta V integrators to see what they have and haven't had success with, and one or both of the firms mentioned above, and then start working towards what has been done understanding what is and isn't possible.

Signing off this thread.


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

The main issue is what protocol could the Mark VIe (or any control platform) support that would allow alarms and events to a 3rd party? Up until recently, there was only OPC AE, which being COM based, isn't a great option for a non-Windows based controller (which, by golly, better be all DCS or turbine controls!). OPC UA Alarms and Events is now available, and may someday be available directly from controllers, but has its own issues (adoption, bloat, and no standardization of many features required by process controls and standards like ISA 18.2).

GE's design decision was to have a rich embedded alarm process and protocol on the controller and leave the translation of the proprietary protocol for TCI or WorkstationST services. The designers of the Mark VIe system considered TCI/WorkstationST to be a required component, even when the HMI isn't Cimplicity. The disconnect is that many people don't separate Cimplicity from WorkstationST in their minds, as they so often run together on a PC.