I am a controls system engineer and I am rather new to turbine controls, particularly the GE Mark VI and VIe DCS software. I am studying this system for future work on a company client's system and am using a VMWare image to train with on the software. I have gleaned over a number of the manuals pertaining to the various features of the system and have gone over a number of topics already on this website over the system, and while I like to say I have a decent rudimentary understanding of the architecture and functionality of the system, there are still some areas I would like information on (made blatantly aware by my boss's thorough questioning). My questions on the Mark VI and VIe are as listed:
1) I understand that the controllers communicate through the EGD Network and that the HMI reads data via UDP and sends commands via CMP through the EGD. Is the EGD Network supported on the EGD Server on the OPC DA Server for both VIe and VI or just VIe? If not how do they differ?
2) Is CIMPLICITY the only GE supplied HMI? If so how does it relate to the graphics editing functionality on Toolbox for Mark VI? (I do not have CIMPLICITY on the VMWare image I possess.)
3) Is the HMI built from a singular data source or do all operator workstations require to have the same HMI graphics individually installed? If the former, how is this done?
4) Is WorkstationST and ToolboxST separate applications or is WorkstationST nested in ToolboxST? (I cannot access ToolboxST as I do not have the USB dongle.)
5) Is OPC necessary for multiple operator workstations? Can the operator HMIs simply interface with just the EGD?
I'm sure I'll come up with more questions, but for now these are what I have. I appreciate any time being taken to answer these.
Welcome to the world of Speedtronic turbine control systems in the age of Mark VI and Mark VIe. Good on you for reading the available documentation as you begin your learning.
It's not really clear what your job will be working with the Mark VI/Mark VIe....
1) I'm not quite sure I understand this statement, or what you're trying to ascertain. In my understanding, "controllers" refers to the controllers in the turbine control panel--usually called <R>, <S> and <T> (in a TMR control system). I tend to disassociate the HMI from the controllers for a couple of reasons. The HMI is first and foremost a device that is not supposed to perform any turbine control or protection functions. It's primarily a way for humans to send commands to a turbine control, graphically view operation, and manage alarms. GE chooses to put Toolbox (or ToolboxST) on the HMI, and Toolbox can be used to configure the turbine control panel and for more detailed troubleshooting and data-gathering (using Trend Recorder, Dynamic Data Recorders, Watch Windows, and dynamic "rung" display). The HMI, in its current form, can be used with Mark V, Mark VI and Mark VIe. (There were some HMIs which were used with some Mark IV turbine control panels, but GE doesn't really support--nor do they want to support--them.)
There were some Mark V operator interfaces which actually did some control of multiple turbines (load control) but that was rare and really was a special case, again, because the operator interface ("HMI") isn't supposed to perform any control or protection functions (in the GE way of controlling turbines)--and sending commands isn't really considered "control." Commands could be sent by discrete and/or analog inputs, so the HMI could be "bypassed" (though it would be difficult).
The designated controller (usually <R> in a healthy TMR control panel) broadcasts information onto the UDH Unit Data Highway), which is then picked up by appropriately configured HMIs, also on the UDH, and displays that data (or alarms). It's my understanding that both the Mark VI and the Mark VIe must have any data points to be displayed via CIMPLICITY (including commands) configured on one or more EGD "pages", and then TCI (for a Mark VI HMI) or WorkstationST (for a Mark VIe HMI) can then make the information available to CIMPLICITY (via a CIMPLICITY Project for Mark VI HMIs, and via OPC for Mark VIe HMIs).
As for how the controllers communicate between themselves--that's some version of an Ethernet-based network, called the IONET. The HMI does not have access to the IONET (directly), and must make requests for information of the designated controller via EGD over the UDH. I'm not sure if UDP is the method by which information is transferred between the HMIs and the designated controller (for sending commands and managing alarms and viewing data); that's generally all background stuff (for me, anyway).
A Mark VI HMI uses a proprietary MS-Windows service, TCI, to allow communication over the UDH with Mark VI turbine controls (specifically, the designated controller). A Mark VIe HMI uses WorkstationST (also proprietary) to allow communication over the UDH with Mark VIe turbine controls (again, via the designated controller). In my opinion, this is done to prevent third-party controls from directly communicating with Mark VI controllers. GE doesn't want to have to test and qualify and certify a multitude of control systems and methods--one can only imagine how expensive that would be, because every person believes their method would be best for their application and it would just be a never-ending job. (It would be easier if GE had a published standard they adhered to, but, then that would make their system "open" and they really don't want others to supplant their HMIs).
Now, a LOT of people are reading this and saying, "BUT!!! But," because they are going to confuse how Toolbox and ToolboxST communicate with the Mark VI controllers with how the HMI (TCI or WorkstationST) communicate with controllers. While both (HMI and Toolbox/ToolboxST) communicate over the UDH, they are not the same methods of communicating. When Toolbox/ToolboxST are on line with a Mark VI, they are not using EGD--they are communicating at a more direct ("lower") level.
So, I hope you are getting the idea now--it's a very tangled and intricate network and there's not a single answer. And, to complicate matters even further, there are some early Mark VIe HMIs that a mix of TCI and WorkstationST--sort of a "hybrid" HMI, if you will. Makes for a lot of fun for Customers and field service personnel.
The good news is: Once it's all set up and communicating correctly (sometimes easier said than done), it all works--and works very well. It's usually humans that screw up the works!
And here's another CRITICALLY important fact you need to know: Alarms and Events are handled by TCI for Mark VI HMIs, and by WorkstationST for Mark VIe HMIs. So, if you're thinking you can implement EGD on some control platform/equipment and communicate with the designated controller of a Mark VI or Mark VIe--you can, BUT you can't get Alarms and Events because they are NOT handled via EGD. (Isn't this fun?)
2) If we're talking about heavy duty gas turbines and steam turbines--yes, the only HMIs GE supplies are those with CIMPLICITY. Again, because data has to be transmitted via EGD between the designated Mark VI controller and the HMI (for TCI or WorkstationST to then pass to the CIMPLICITY Project (for Mark VI) or CIMPLICITY Viewer (via OPC for Mark VIe), data points and commands for CIMPLICITY have to be handled through EGD. Toolbox's graphics capability is entirely different from CIMPLICITY, because Toolbox communicates more directly with the Mark VI than via EGD. I'm not sure of the graphics capability of ToolboxST these days; a lot was intended to be done with graphics capabilities in ToolboxST, but it never seemed to come to fruition.
3) This is one of the HUGE problems with GE HMIs using CIMPLICITY: each HMI has its own display files, and changes made on any HMI have to be manually transferred to other HMIs. I have been to sites where every display on every HMI is different--because people mistakenly thought that a change on one HMI would automatically be "populated" to every other HMI--and as implemented on Speedtronic HMIs CIMPLICITY doesn't do that. It can really be quite a mess.
4) WorkstationST and ToolboxST are two separate applications. An HMI can have only WorkstationST and CIMPLICITY installed on it and can be used to operate a turbine and auxiliaries. A properly configured PC can only have ToolboxST installed on it and be capable of communicating via the UDH with Mark VI controllers--without WorkstationST.
5) Not quite sure I understand your question, or the intent of the question. GE supplies HMIs that are either "servers" or "viewers". And then there's the whole OPC thing, and again, for me anyway, that's all background stuff. GE seems to be using OPC for Mark VIe HMIs because they don't have to pay for a "full" license of CIMPLICITY, using just the "viewer" option via OPC. I have heard that some sites actually have other control systems capable of getting data via OPC from the Mark VIe HMI running WorkstationST--but the data points have to be configured in ToolboxST to be on the EGD pages for WorkstationST to pass to OPC. (Again, isn't this fun?)
Myself, I consider GE HMIs to be a necessary EVIL (in cap's). They are HORRIBLY, horribly documented, and the methods by which they can be modified (points added) have changed multiple times without any documentation--ever. Also, there is usually a hodge-podge of different types of command types on any CIMPLICITY display, from SRTP pushbuttons to SmartObjects to scripts--and it can be absolutely maddening trying to figure out how to make them work (because many times they come from the factory improperly configured). In my career with GE I spent more time (by several multiples) trying to fix non-working HMIs than I ever spent fixing broken or incorrect turbine control logic or parameters. They look "cool", but they are a mess, pure and simple.
And, all the background stuff is just that--background stuff. If I understand the gist of your questions it sounds like you or somebody wants to try to integrate Mark VI and/or Mark VIe control systems into some other plant control network--or some other HMI application/software. And, that, my friend, is not as easy as it seems. Not at all. There are a couple of OPC companies who advertise they can communicate with Mark V, Mark VI and Mark VIe--but I don't think any of them can handle Alarms and Events. And there is only one company I know of that can fully replace the functionality of a GE Mark V HMI/<I> (an <I> is the command-line driven operator interface provided with early Mark V turbine control systems) without using CIMPLICITY, and also handle Alarms and Events from Mark IV, Mark V, and Mark VI (soon, also, Mark VIe): CSE Engineering, Inc. (www.itc-info-us) Again, there are several vendors who can display information and provide command capability, but only one that can do it without CIMPLICITY.
So, if you have more questions along these lines ("background stuff") please try to be more specific about what you are wanting or intending to do and perhaps we can provide some suggestions, or experience. To my way of thinking, as "important" as HMIs are--they don't do anything to control or protect the turbine, which is another reason I think they aren't very well documented or supported by GE. They are just a necessary EVIL, with the real "work" done by the Mark VI/Mark VIe. And from personal experience, I can tell you: A LOT of people have spent a great deal of time and money trying to "bypass" GE HMIs with varying degrees of success, and a lot of failure--because a lot of reverse engineering has to be done. And, there's really only one company that's done that and stands behind their product (and I'm referring to being able to completely supplant/replace a GE Mark V HMI/<I>--not just display data and provide a command interface).
Thanks for answering my questions with such depth. I've noted your presence on this subject prior and am glad to have your attention. I can definitely use guidance as I venture into this system.
Frankly I do not specifically know what I myself will be involved with on the Mark VI/VIe, but I do know that my company will be involved on programming a BMS and performing alarm management for a combined cycle plant. From what I am aware, we are not trying to integrate the Mark VI/VIe control system with a third-party HMI application. What I hope to learn is the architecture and structure of a GE Mark VI/VIe control system and how it works within the intended scope of its design. (Basically, a diagram and description of a Mark VI/VIe control system layout would most likely answer most of my questions.)
Your answers to my questions lights up some areas but it also presents more questions. Note that I have neither TCI nor WorkstationST on my image so I have no tangible feel to them, so forgive me if I seem to have the wrong understanding of their function.
1) So TCI and WorkstationST (which are separate applications) are the services that relay the commands and inputs to and from the TMR controllers via EGD over the UDH (from what I read using UDP and CMP for reading and writing, respectively). However, alarms are not transmitted likewise. Are they transmitted on the same UDH just without EGD?
2) Is TCI and WorkstationST a part of the CIMPLICITY HMI? Where would alarms typically be displayed?
3) I have a project file from the plant that shows all alarm points being defined on the EGD. What would be the reason for this if EGD is not used for transmitting alarms to TCI/WorkstationST?
4) Does it matter to CIMPLICITY whether the Alarm check box is checked for alarms? Or is it merely useful for referencing?
5) Am I correct in saying that communication over the IONet is performed with EGD?
6) I understand for Mark VIe, you can have viewers on multiple operator workstations that communicate via OPC to WorkstationST. Does that mean in this setup you can just have an OPC client and the viewer HMI (CIMPLICITY?) on an operator workstation, and WorkstationST and OPC server on a server?
7) Is it possible for the HMI graphics to be located on a server and all other operator workstations access the same graphic files via TCP/IP? That way any changes made can be translated to all workstations.
8) Is there an intermediary module/server between the TMR controllers and the TCIs/WorkstationSTs that data must flow through? From reading the documentation on OPC DA Server, it appeared as if there was an EGD Server that the Mark VIe and any OPC client (e.g. HMI) communicated with on a WorkstationST computer. Also, whether or not OPC is used, is there a EGD server/service on every TCI/WorkstationST computer?
Again, thank you for your previous answers and for the time you take to answer all these.
As I've said, I'm not really an expert by any stretch of the imagination on all the "background" stuff for HMIs. While it can be a real struggle to get all the communications between HMIs and Mark VIs/Mark VIes working correctly, when it does work it works very well. I've been to quite a few sites where it's "just working" but not properly--meaning some HMIs are properly configured and others are configured completely differently and both of the experience periods of intermittent operation, but because there is virtually no written documentation about how everything should be configured on any given job people are actually reluctant to make any changes even though they are dissatisfied with the way things operate! (I know someone or some people are not pleased when I say these things, but it's sadly true. And, GE should be held accountable for this--but almost never is. My fervent hope is that someone in GE will read this and enough people in GE will see this and things will actually get fixed--a dream, but everyone is allowed to dream, even if it's a virtual impossibility.)
1) Yes; alarms and events are transmitted via broadcast on the same UDH (there's only one UDH, though there may be redundant paths (cables and switches). And, it's my understanding they are NOT transmitted using EGD.
2) TCI and WorkstationST are separate "applications" (services) which are installed separately on the HMI, and which are necessary primarily for alarm/event handling and for passing information from EGD to CIMPLICITY in the way that GE Salem implements EGD and CIMPLICITY (which is many times different from the way other divisions of GE implement CIMPLICITY).
3) The Alarm Window in CIMPLICITY implementations for Mark IV, Mark V and Mark VI are special CIMPLICITY AMV objects. I believe that somehow text messages get into the Project file for association with and display in the Alarm Window and to the alarm printer. Again, it's one of the background things that works, or it doesn't.
4) Not sure about that, but I believe that's what tells Toolbox how to associate alarms and text messages. There is another Toolbox "device" called an HMB device, and somehow alarm and event information gets into the HMB device (which is for the HMIs) and then it gets pulled into the CIMPLICITY project. That's my understanding, and it may or may not be correct.
5) I do NOT believe IONET communication is done using EGD. I believe it's a proprietary TCP/IP implementation over Ethernet. There's a LOT that goes on over the IONET, even more on Mark VIes than Mark VIs. I don't think EGD is sophisticated enough to be able to do that--and I doubt very seriously that GE would make it that "easy" for others to see what's going on on the IONET.
6) I believe that's also possible for Mark VI (Viewers using OPC), but, again, I'm not an expert on HMIs and CIMPLICITY. But I don't think what you're suggesting with a separate PC running WorkstationST and an OPC server. I think WorkstationST is an OPC server of sorts for CIMPLICITY Viewer. And I believe one needs a dongle (UPD) for WorkstationST.
7) I don't believe CIMPLICITY can work that way. That may be true for some of the newer versions of CIMPLICITY or PROFICY Machine Edition, but I've never seen it--and I would have made note of it if I had. That's one of the most maddening things about CIMPLICITY--every HMI can have different displays, and while they can be copied between HMIs, they have to be edited to make them specific to an HMI, and that can be very difficult since there is/was no standard about how CIMVIEW display files were made specific to any HMI. There are multiple ways and even GE engineers in the factory don't know all of the ways, nor the "proper" way as each version of TCI and WorkstationST and CIMPLICITY and CIMPLICITY Service Pack is rolled out (and the "proper" way can change significantly, or minorly, with any of those programs). If one could go through every display on one HMI and convert them all to the same configuration for being able to easily make them specific on any HMI, that would be great. But, from painful personal experience, that's extremely difficult and time-consuming and one has to have contacts in GE to help with some of the configurations.
8) No. Again, I believe that is all handled by TCI/CIMPLICITY on Mark VI, and WorkstationST on Mark VIe. I may be wrong, but that's my understanding. I believe that CIMPLICITY (on GE Mark VI HMIs) has a user-configurable OPC server, but I'm not sure if every version of CIMPLICITY does. I don't know how "open" the OPC server is on WorkstationST, but I imagine since OPC is supposed to be an open-source communication means that one could use another OPC "device" to get/send information to WorkstationST.
Again, I am probably taking some liberties with my understandings here, but that's how I envision it. I spent a good deal of time avoiding CIMPLICITY and all of this background stuff--somewhat to my detriment, but every time I thought I had learned how this or that part of the HMI and CIMPLICITY worked the next job I went to would be different--sometimes completely, sometimes only enough to cause fits. So, I just documented what worked and what didn't, sent the information back to "the factory" and in a day or so (sometimes sooner) I would get back a working configuration. Much easier than trying to learn everything all over again several times a year.
I would be much more comfortable answering questions about Mark VI or Mark VIe than about HMIs--which, again, I deem a necessary EVIL. I'm probably only about two-thirds right with some of the low-level details, but I'm hoping that someone will correct me--and help you (and others!). There seems to be a GE employee or two lurking here from time to time who offers useful information and corrections.
The Mark VIe is being considered for a combined cycle power plant I work for. 2 GTs 1 ST and 2 HRSGs. The system would replace our current plant wide DCS including GTs, ST, HRSGs, switchgear, MCCs, water treatment, everything. The current system is an old ABB Procontrol P13 DCS.
1) Have your thoughts and experience with the Mark VIe changed since 2014?
2) Has the HMI improved?
3) Do you think the Mark VIe is a good system for the entire plant or is it better suited for GT control only?
4) Does the Mark VIe allow online logic or configuration changes?
5) Can equipment be added to the network and displayed on the HMI? Can this be done online?
6) How difficult is it to configure control logic and the HMI?
Thanks for any information you can give
1) I believe the Mark VIe is a fine, robust, purpose-built control system very suitable for turbine control and plant-wide DCS control. The issue for me is that it's very likely there will be at least two groups that will be providing equipment--one for the turbines, and one for the balance-of-plant/DCS. And, sometimes these two groups don't work well together, which can lead to some small problems which can become big problems.
But that has nothing to do with the Mark VIe--it's the application (the programming and configuration).
2) Well, yes and no. The method for getting signals/values onto an HMI display is markedly improved--though it's STILL not properly documented. The basic CIMPLICITY displays provided with a system are just that: basic and little more than adequate. There are many things which can be done to improve the CIMPLICITY graphics, but the biggest thing which can muck things up is the inconsistent use of button types for various functions.
The Alarm Window is handled by a separate application running on the HMI (separate from CIMPLICITY) and it's NOT well integrated into the HMI. The Alarm Window is VERY powerful and can be very helpful--if properly configured, and properly used by the operators, technicians and operations managers.
If you're considering buying a "Historian" think long and hard about that decision. The "Historians" provided with Mark VIe can be very powerful, but usually are extremely ... EXTREMELY ... poorly configured. And, it takes a dedicated person, preferably two, on a site to get familiar with the "Historian" and properly configure it and be able to use it when there's a problem and historical data is desired. You have been warned.
3) The Mark VIe was specifically designed to encompass an entire plant, including turbines and all associated equipment. This was done for the H- and HA-class turbines which heavily integrate the HRSG and plant auxiliaries into the turbine control and protection. There are many I/O packs and printed circuit cards & terminal boards which were developed specifically for balance-of-plant I/O.
The fly in the ointment with many Mark VIe systems is that the packagers of the equipment vastly over-estimated the ambient temperature ratings of the components. The designer of the equipment overstated the ambient temperatures in which the equipment could be operated, and this lead to siting equipment in remote locations without proper cooling and ventilation. Further, when combining the modules into systems many times the temperature of modules mounted lower in the cabinets would contribute to very high temperatures experienced by modules mounted above them. This has been a real, serious problem for many sites. (There have been several threads on control.com about this.) In my experience, a lot of I/O packs have been replaced which were found to be in fine condition when tested in a laboratory environment, and if there had been proper ventilation and air circulation in the cabinet the modules would not have "failed."
4) Yes. Most configuration changes and some simple programming modifications can be done when the equipment is running. But, some modifications do require a re-boot, which, on a properly configured TMR control system, can be done while the equipment is running. (It's risky, but it has bee done many times.)
5) If by "equipment" you mean can new I/O modules/packs be added on-line, no. If you mean can spare I/O channels on existing I/O modules be configured and used and the value of the signal from the new I/O displayed on an HMI, then, yes, I would say that a good technician could wire in new I/O, configure spare channels on existing modules, and add the values to HMI displays without having to shut down the equipment.
6) That depends on your background, and your tolerance for learning new things. Every control system has its quirks of programming, but the application used to make programming changes, ToolboxST, is pretty powerful. Configuration and troubleshooting--very detailed troubleshooting involving trends and various data capture methods--can all be done with a single application, ToolboxST. Is it "user-friendly"? It's no iPhone or video game controller, but in my personal opinion it is powerful without being too detailed or obtuse. As with MANY programming/configuration software tool packages these days, there can be many nested levels of configuration, but that isn't peculiar to ToolboxST. The documentation is getting better, but it still has a way to go--particularly when it comes to the HMI.
Properly configured, properly programmed and properly commissioned the Mark VIe is a fine control system.
CSA... Thank you for your reply.
The question "Can equipment be added to the network and displayed on the HMI?" was not meant for GE or Mark VIe equipment it was meant for other manufactures. Example: I have an online DGA monitor that can provide data via an ethernet connection. I want to put this on the Mark VIe HMI. Can the monitor be connected to one of the Mark VIe network switches and the data be displayed on the Mark VIe HMI? If I can't use the Mark VIe network how can I bring in this data and display it on the HMI?
Thanks for the clarification. I don't know what a DGA monitor is and what communication methods it is capable of (MODBUS; OPC; etc.). CIMPLICITY (or PROFICY, or whatever they're calling it these days) has some pretty good native communication capabilities, meaning that it can talk directly with lots of other devices, including devices capable of OPC.
I suggest you research CIMPLICITY/PROFICY and learn what it's communication capabilities are to determine what it can do.
The GE network includes a PDH (Plant Data Highway--see how easy it is to explain abbreviations to others that probably aren't familiar with them) which is an Ethernet-based system which is designed to allow other devices to communicate with HMIs to share data. And, there's always everyone's favorite, MODBUS, which can even be done using TCP/IP over Ethernet.
You seem very proficient in the GE world of turbine controls and i'm a new controls engineer with a lot to learn. i'm hoping you might be able to help with a project i'm working on. We are attempting to connect a Fogg skid (Allen Bradley PLC) to the HMI using a MVI69-EGD card and having much difficulty. Would you happen to have any experience with connecting a 3rd party controller not to the Mark VI but to the toolbox?
CSA covered a lot of ground, I'll just fill in a few gaps and correct a few details. I highly recommend joining the GE Connect website as soon as you can; there is a lot more detail on there.
1) EGD is a UDP based protocol that is used for controller to controller, controller to HMI, and controller to distributed I/O communications on the Mark VI and Mark VIe. It is actually an open protocol, though only GE and partners generally use it-it is available on Mark VI, Mark VIe, GE PLCs, and a number of Drives products. EGD sends data at a set rate, so network traffic is predictable and consistent. Since it is a sessionless protocol that is broadcast or multicast, it can be very efficient for fanning data out to multiple clients. The EGD spec also defines the concept of an EGD Configuration Server (included in WorkstationST for the Mark VIe) that contains the definition of all of the EGD produced and consumed in the system; this allows consumers of data (ie HMIs) to know when the server changes (ie someone added a point to a Mark VIe), and potentially do dynamic binding and use the changes immediately. CMP is a separate UDP protocol for sending commands (with replication for redundancy) and is layered on top of the EGD exchanges. The EGD protocol is also used for Mark VIe communications to its I/O packs, but with hard-coded exchanges specific to the pack type. From the Controller configuration in ToolboxST, it is easy to setup EGD data; usually you just select a variable and in its properties set its EGD Page. (Pages are simply collections of points with a particular update rate and multicast address.) Consuming an EGD point simply requires "referencing" a device in ToolboxST, after which its EGD points are simply available.
2) CIMPLICITY is the official HMI for many of the products based on the Mark VIe, including all of the heavy duty turbine products. Some GE businesses use iFIX, and a few like Wind have their own SCADA system. All of them communicate with the Mark VI/VIe control system through an aggregating layer, either TCI or WorkstationST. Since WorkstationST provides OPC DA, OPC UA, and OPC AE support, third party HMIs are not uncommon for DCS systems, though rarely for turbine control. The OPC AE protocol does allow third parties to access alarm data, albeit in an imperfect way, as there is no open protocol for alarms that is fully featured enough to implement, say, the ISA 18.2 alarm standard. CIMPLICITY has its pros and cons, and a lot of the issues have more to do with how the screens were developed. For example, most of the DCS screens for Mark VIe use lots of scripts to automatically configure screen objects when the screens open. This makes it easier to produce standard screens quickly, but complicates customization-there is a lot of tribal knowledge involved.
3) As CSA mentioned, there is a lot of variability from site to site, particularly retrofit sites (new units are a lot more consistent). I've seen networked file shares as the source of a common configuration, but at this point the best solution (IMO) is to use GE's Configuration Management Server and the WorkstationST HMI feature. The CMS server (part of ControlST) handles version control and provides the "master copy", while the HMI feature automatically keeps HMI screens on all workstations up to date.
4) ControlST is the name of the whole package, of which ToolboxST and WorkstationST are components. WorkstationST is a management platform for a collection of Windows Services performing a bunch of different jobs. ToolboxST is the engineering and configuration tool for the Mark VIe, but also is used to configure specific instances of WorkstationST running on PCs in the control system. Not all WorkstationST instances are HMIs, though every HMI must have a local instance of WorkstationST. For example, you might have a PC with a time card setup running WorkstationST as an NTP server. There are a lot of features of WorkstationST that can be turned on for any particular server, like protocol gateways, alarm scanners, HMI screen synchronization, etc. WorkstationST also includes the Alarm Viewer tool, which it sounds like you will probably know very well soon. :)
5) CIMPLICITY comes in two flavors at the moment: project based, and advanced viewer. Since about 2008, GE's HMIs use advanced viewer, because it uses OPC DA to collect data, which has advantages in that there is no "import" step for getting points into CIMPLICITY. Project mode has a "DevCOM" that lets CIMPLICITY's point manager natively read EGD data. Other HMIs could potentially read EGD directly (the old "COI" for Mark VI/EX2100 did that), but there is a big advantage to using an aggregator like WorkstationST or CIMPLICITY's point manager: it can combine data from multiple sources, and abstracts the details of the communications interfaces.
1A) Alarms are transmitted from the Mark VIe to the Alarm Server component of WorkstationST via a proprietary TCP/IP protocol. Because it is a Session based protocol, it uses up a little CPU on the controller per client, which is one of the reasons for having an aggregating layer like WorkstationST's alarm server rather than a connection from each HMI to the controller. The Mark VI was a little different; it had another UDP based protocol for alarms, but the alarm server on TCI or WorkstationST is still the aggregator.
2B) Alarms in a Mark VIe are best displayed in the stand along Alarm Viewer tool. However, there is also an ActiveX control version of it that is sometimes embedded into CIMPLICITY screens. Generally, CIMPLICITY's native alarm viewer isn't used with the Mark VIe, as it doesn't support some of the features needed for standards like ISA 18.2.
3B) It isn't uncommon for alarms to also be EGD points, largely to drive indicators on HMI screens. Not a requirement, however.
Hope that helps. This is a very deep topic.
I'm Student of Electrical Engineering, Just reached on the end of our course. I want to work on GE Mark VIe ICS. Can you provide me the GE Mark VIe installed on VMware Machine or on VirtualBox Image? I'll be really thankful to you, in this manner I can do some practice.
My Email is firstname.lastname@example.org
ToolboxST requires a UPD (USB Protective Device). Without a UPD you can't open the Mark VIe configuration application. The only way I know of to get a dongle is to buy a copy of ToolboxST from GE or one of its packagers.
People need to remember that just because something can be transmitted electronically doesn't mean it's not protected by copyright laws and IP (Intellectual Property) laws. GE employees earn a living by writing software for GE. They have families and lives they support by writing software and that software is protected property which is illegal to pirate or steal--even for academic purposes.
How would you feel if an application you wrote, invested your time, knowledge and creative talents that you were using to support your family, pay for food, housing, clothing and savings, was made available for free by others just because they thought it should be freely available--or, more likely, "just because they could distribute it freely"?
Can you post your contact information:
Do these dongles work with Mark V and Mark VI, also?
Provide your e-mail id as well
Moderator's note: Just to clarify, it is the vendor who must provide contact information.
>I sell USB dongles for markVie HMI. cost is 1000 USD.
>please let me know if anybody require it
I just want to point out Control.com's policy on buying and selling in the forum. On http://control.com/guidelns.php, item 4, it says the following:
"Currently, Control.com doesn't allow buying and selling items via our forum. If you are looking for something in particular, such as an item of used equipment, you might word your post to ask for recommendations on reputable vendors of such items."
If the poster offering these dongles (Five) is a reputable vendor, he or she should post contact information.
One of the Control.com moderators
>Any recommendation where to get the ToolboxST dongle and
>Visupro dongle from?
You're talking about the hardware dongle enforcing the product license for ControlST; logically, you'd order it from GE. Granted finding the right place can be tricky; fortunately the google search for "GE ControlST License" came up with the right link on the first result. Minor miracle, that.
The workflow itself is a little uglier than I'd like, because the hardware dongles changed for ControlST V5 and later. At least now there is only one dongle needed for ControlST and CIMPLICITY, plus GE's Proficy products.
Hope that helps!
I'm in the similar situation like you in this case. I was in a Mark VI training more than 15 years ago and am needing to asist a client that uses Mark VIe. I would like to review my training previous to assist him, but I don't have a simulator or something like this in order to review this control system previously. Could you share with me your VMWare images just for personal training uses? I will appreciate a lot your support.
My email: email@example.com
Thank you very much in advance.