EGD in MARK 6e

J

Thread Starter

jay

Hi
What is the purpose of EGD is mark6e, when the complete network is handled by switches. Please help me in understanding this concept

jay
 
Yes I have wondered the same thing when the HMI polls data via OPC DA. So is there truly a EGD exchange between CRM1_SVR and the cores?
 
EGD is simply the protocol used to transfer data on the ethernet networks in the Mark VI and Mark VIe systems. It is quite different than OPCDA; EGD is based on a multicast UDP instead of TCP, and is designed to send all possible data all of the time. This allows network load and Controller CPU time to be predictable. EGD is also relatively fast, allowing controller to controller update rates of up to 10ms.
 
Demigrog,

Which Ethernet network(s)?

The IONET network?

The UDH network?

The PDH network?

And why, if you are referring to the UDH (which is what this post is primarily referring to) is it necessary to add signals desired to be displayed on the HMI to EGD pages in Toolbox or ToolboxST? If EGD is only used on the internal IONET network(s), why do signals have to be added to or listed on EGD Pages in Toolbox or ToolboxST in order for them to be used in CIMPLICITY displays?

Inquiring minds want to know. All of the specific details. You have made a very broad statement, which needs clarification.
 
I don't think EGD is used on the IONET Ethernet. I know it is used on the UDH and PDH. And, in addition to what has previously been stated, it is also used to pass signals among the different controllers (on the UDH). While there is not too much of this in simple cycle applications, it is done quite a bit in combined cycle applications - mainly for startup and shutdown sequencing.
 
Hi

CSA you are right
why do signals have to be added to or listed on EGD Pages in Toolbox or ToolboxST. If class C IP address is provided to all devices connected in the network it is more than enough to transfer data from and to the controllers and controllers to controllers.

WHY do you need a separate EGD server instead you can even add IP address and other details in system data base.

thanks
jay
 
EGD is used on IONet between the Mark VIe and the I/O packs, and also on the UDH between controllers and from controllers to the Workstations (HMIs, Historians, OPCDA server, etc).

EGD on IONet is not user-configurable, as the data being sent is hard-coded for the specific I/O pack and firmware.

On the UDH, it'd be easy to use up the entire network bandwidth with EGD data in large systems (BOP especially), so application code designates which variables will be on EGD, and how fast. These days it seems like almost everything is on EGD except the intermediates between function blocks, but most of the data is being sent at a relatively slow rate (320ms, 1s, etc). The faster rates are still available, however, and used in some places.

The EGD spec (which is actually open, though hard to find) also defines data types and a common XML schema for configuration data.

I should be more clear that EGD isn't the only protocol in use in a Mark VIe. There is also CMP, which is layered on EGD and is how HMIs send commands and setpoint values; SDI, which is used for session-oriented communications like alarm data to the HMI and configuration and downloads from Toolbox/ToolboxST; and ADL for configuration and downloads to I/O packs.

The PDH is a different world; all communications is aggregated through the WorkstationST (or TCI in the "legacy" tools) services, and re-packaged as OPCDA, SDI (between GE servers), GSM, HSE, etc. New protocols are added to WorkstationST every now and then.

The I/O packs themselves can also act as bridges to other networks and protocols; that is probably the Mark VIe's greatest strength. It can already support its own custom I/O, HART, CanOpen, Profibus, FOUNDATION Fieldbus, Modbus, etc. Adding more buses simply means plugging in a new I/O pack.
 
I should have mentioned the role of the EGD configuration server. All it does is store the EGD configuration from every device so tools can get the list of variables published and consumed by each device. It is similar to the SDB server in the Mark VI world, except it is a little more dynamic (no manual Post and Bind steps, it uploads the latest EGD exchanges from controllers automatically). It is different than an OPCDA server, where the server is actually providing the data; the EGD Config server is merely providing the schema for the data.
 
Great questions, all.

I believe in versions of Mark VI- and Mark VIe HMIs with CIMPLICITY that use TCI, it's the way that TCI gets information to and from the Speedtronic. Because, in those HMIs it's my understanding that CIMPLICITY does not communicate directly with the Speedtronic; it does so through TCI.

GE is now supplying ControlST on WorkstationST HMIs (running CIMPLICITY) instead of TCI. I believe the whole underlying communication scheme, utilizing OPC elements, is in a state of flux at GE as they are changing their HMIs, and seem to be headed away from full-blown CIMPLICITY projects and implementations. But, I haven't seen any documentation that really outlines the scheme very well.

We have to remember, that as an OEM, GE has two basic interests with regards to communications with turbine control panels (and DCS/BOP panels using Mark VI and Mark VIe hardware). First, they want to limit external access to prevent any "us versus them" operating problems or catastrophic failures. One can certainly envision someone not properly implementing a control signal and causing a turbine to fail catastrophically, possibly injuring or even killing people. That would be a very difficult situation for everyone, and could lead to lots of litigation and all manner of problems. We're not talking about simple equipment here when we're talking about turbines, and combustible fuels, and hydrogen-cooled generators, etc.

So, in the interest of making things "simpler" for everyone, both now and in the future, and to prevent huge litigation costs and terrible corporate relations (the GE brand is very valuable and important) they necessarily need to limit access to devices which they "certify" and which run their proprietary software and protocols.

Second, they also want to protect the intellectual property they have developed in the course of making these control systems and operator interfaces. It's not cheap to develop these protected interfaces and protocols, and they need to ensure they can continue to develop future generations, as well.

Yeah, there's all this wonderful, utopian talk about open architectures and OPC, but the interests of the first point generally far outweigh any other points.

Case in point, just look at how many "flavors" of MODBUS there are! It's insane. And some devices which claim to talk MODBUS don't talk to other devices that claim to talk MODBUS. It's a really good example of how something so simple can go astray.

But, these are mostly just personal observations as well as information I gleaned from years of trying to understand why things had to be so complicated and why a more open architecture couldn't be adopted. Just imagine how difficult it would be for GE service personnel to troubleshoot turbines and driven devices if every one had a unique operator interface (HMI)! It would also require that GE develop huge manuals documenting operating sequences and methods, and we all know that's not going to happen any time this century.

Perhaps demigrog, who seems to have his finger more directly on the pulse of GE HMI technology could provide more information or direct us to some documentation where we could find some information.
 
Demigrog,

Thanks very much for the information! It's good clarification.

Is any of this available in Mark VIe Documentation? GEHs? GEHTs? GEIs?

Thanks again!
 
P

Process Value

EGD Protocol

i am providing supplementary data to what demigorg has already said about the EGD protocol. EGD is a open protocol, spec is given in the GE document "GEI100604" "GEI100503". i cannot find the copy at the present site. i will upload the docs once i return to my refiner what i now have is this

http://www.2shared.com/document/-3xiTSol/egd.html

this is part of a manual i published in the refinery detailing the mark vi software configuration. this will provide the details regarding the EGD exchanges, egd points, internal architecture of the pages, EGD service and the EGD devcom. most of the stuff is taken from the manuals, but i have added bits and pieces of my own explanation and drawings.

EGD protocol is used both in mark vi and mark vie but in varied capacities.

in mark vi the EGD is primarily used in the UDH network. the pages are configured in "broadcase mode" for single machines and "multicast or unicast" is more than one machine is present in the same UDH. the EGD is also used in the "IONET" for communication bewtween the processors is the ethernet link is down for a processor. this is the only use of EGD in a mark vi system. if you feel compelled to test this, pull out the ethernet cable from the any of the processors take up a EDG write point "eg manual rise / lower" and give a manual rise lower from the cimplicity screen and check the signal the pre-vote data. it will reflect on all the three processors even though one of the processors do not have a ethernet communication. this is done through the EGD via ionet.

in mark vie EGD plays a more important role. It is the primary mode of communication in the UDH. it is also extensively used in the IONET. in the io net , the controllers "broadcast" the data to the IOboards while the IOboards "multicast" the data to the processors. in other words, a processor broadcasts all the data (output) to all the IO boards and processors, and it is up to the IO boards to use the data relevant to the board. the IO boards on the other hand sends the data only to the controllers "multicast" ie the data is not sent to the other IO boards.

i think i have given a head start here, further discussion is always welcome.
 
For Mark VI/VIe, EGD is the link between the controllers and TCI as well as WorkstationST. Mark V and older, obviously, have different protocols for the arcnet network.

It is important to realize that EGD is solving a different problem than OPC; OPC is trying to be a universal communications protocol, and it has made tradeoffs to support that that limit its speed. OPC is also a “session” based protocol, and frequently the sessions are temporary; EGD is an "always on" protocol, so the network traffic is predictable. So, OPC isn't necessarily appropriate for high speed controller-controller communications, and many DCS vendors have an equivalent to EGD for that reason. Also, OPC is based on DCOM, which is very ugly to implement on a non-windows platform; OPCUA has solved that problem, but adds a whole lot of overhead in its XML schema that actually makes it even worse for high-speed, high volumes of data.

I doubt the controllers will ever talk OPC/OPCUA directly; by routing supervisor-level communications through the WorkstationST, there is a single point for aggregating communications, providing security, and load balancing (ie not kicking the Controller's idle time below 50% just because somebody opened an HMI screen with 6,500 points on it).

The CIMPLICITY architecture has changed fairly recently for the Mark VIe. In the legacy (TCI) tools and versions of ControlST prior to (I think) V3.3, the contents of the SDB or EGD Config server had to be “built” into a CIMPLICITY project, a time consuming step that made it difficult to add a point to an HMI screen. Now, with CIMPLICITY 7.5+, there is no project; WorkstationST has an OPCDA server that CIMPLICITY uses to browse for variables and access live data. So, to get something onto an HMI screen all you have to do is add a variable in ToolboxST, put it on an EGD page, build and download the controller (online, usually). The new variable immediately shows up in CIMEDIT for use on screens (or historian software, 3rd party software, etc). At the same time, GE added lots of improvements to the interaction between CIMPLICITY and ToolboxST (right-click “Go to logic” on screen objects, drag-drop of blocks from ToolboxST logic to CIMPLICITY automatically creating screen objects, etc).

As for direct 3rd party access to unit data, I haven't seen nearly as much activity in the Mark VI/VIe world as for the Mark V, probably because so many customers are still under warranty and WorkstationST already provides OPC (actually, it can for Mark V as well). No doubt there will be lots of 3rd party access to Mark VIe via OPC, but it isn't going to make much sense for a 3rd party to try to talk directly to the controllers. Certainly there are 3rd party EGD->OPC services out there already, though I have not seen one that updates dynamically like the WorkstationST implementation; most of them were designed to talk to GE Fanuc PLCs, and can't talk to the EGD config server in the Mark VIe system to get exchange configurations. Every Mark VIe I've seen with a non-GE DCS system is going through WorkstationST for OPC access. I don't think I've seen a Mark VIe with a non-GE HMI, though I'm sure they exist. It'd obviously be up to the 3rd party or site themselves to write an operator's manual in that case. :)

GE also has non-CIMPLICITY SCADA systems for wind turbines that go through WorkstationST, and a few specialty products that do talk EGD directly or use the http server built into the Mark VIe (which is usually disabled in turbine control applications). On a Mark VIe controlled Wind Turbine for example, they actually have a gorgeous operator web page served directly out of the controller.
 
> Is any of this available in Mark VIe
> Documentation? GEHs? GEHTs? GEIs?

It is nearly impossible to find GE's documentation online; I have access to all of it, but I'm not sure what I can legally share.
The best general overview document I know of that is public is GEI-100600 (http://www.ge-energy.com/content/multimedia/_files/downloads/markvie_desc.pdf).

If you've got ControlST installed (well, one new enough that the document exists), the documentation folder in the start menu should include these:

GEH-6721, Ch. 1 & 2, IONet: Very general overview
GEH-6721, Ch. 3, EGD: Very general overview
GEI-100622, EGD Configuration Server
GEH-6700, ToolboxST for Mark VIe: various sections on EGD
GEI-100621: WorkstationST OPCDA Server
GEI-100697: WorkstationST/CIMPLICTY Advanced Viewer Integration

There are also some interesting (but brief) fact sheets, and I don't know how to get them other than asking your GE rep:
GEA-S1220: Mark VIe ICS Networks and Communications
GEA-S1267: ControlST 4.2 new features
GEA-S1270: ControlST 4.3 new features
 
Hi

demigrog and process value

Thanks for sparing your time to explain \EGD/, can you please help me in simple way.

I am not able to download file from 2shared web site

thanks

jay
 
I would receive a more detail explanation on how to write successfully data to Mark VI via EGD, with a GE PLC.

Right now I can receive data to the PLC, but the PLC is still not able to write register to the Mark VI.

What could be the cause?

thank you!
 
Hi,

It would be great if we could get a solution to the below stated issues. Even i'm facing similar situation, can READ from Mark VI in GE VMax PLC but cannot WRITE register to Mark VI either through EGD or SRTP from PLC.

Any pointers as to why its not possible and what could be a probable solution for this?

Thanks!! :)

> I would receive a more detail explanation on how to write
> successfully data to Mark VI via EGD, with a GE PLC.

> Right now I can receive data to the PLC, but the PLC is
> still not able to write register to the Mark VI.

> What could be the cause?
 
The short answer is that EGD is not a two-way protocol. If you want to write data from the PLC into the controller, you'd create an EGD page from the PLC and consume it in the controller.

There is a second protocol called CMP (command message protocol) that layers on top of the EGD configuration to perform setpoints from HMIs. it handles the somewhat complex details of command replication to redundant controllers, and uses the EGD address to identify the variable. For CMP to work, the EGD point must be configured as Read/Write, and you have to write application code to expect setpoints (ie don't drive the variable from logic, maybe ramp or clamp the values, etc). I don't know whether or not you can send a CMP message from the PLC. I don't think you can even do it from another Mark VI, as CMP was not intended for controller to controller communication.
 
P
Hi,

Pls try the following steps and you should be good.

1. Export the complete EGD as a tree file, like EGD.tre

2. Open the tree file in notepad.

3. At the Vmax WRITE page to Mark VI, change the producer ID as Vmax or its IP.

4. Add EGD Link for Vmax and Mark VI unit ID, under the links

5. Delete the old EGD from the Mark VI, import the new tree file.

After compilation & downloading, you should be able to read signals from Vmax.

Success!!
 
Top