Cimplicity with Mark V - integers for command buttons


I'm working on a steam turbine control with a Mark V and a Cimplicity HMI. There are two things that are confusing me in Cimplicity:

1. Command buttons are using the AbsoluteSetpoint action to set a point's value to 16. These points are associated with contacts in the Mark V ladder logic. I was expecting to see the point set to 1 for a contact, not 16. Apparently the Mark V does not support a Boolean data type, so an 8-bit integer is used in Cimplicity. Any idea why this integer is set to 16?

2. I don't see a command button that sets the point back to 0. It looks like the point gets set to 16 once and then holds that value forever. I'd like to know how the command button's point gets set back to 0 so it can be used again. I've looked through the Mark V logic and I don't see it setting any of these command values back to 0 either.

Hopefully someone with more Cimplicity / Mark V experience than me can shed some light on this. Thanks for your help.

Did you read the right technical GE manual called CIMPLICITY HMI PLANT EDITION CIMDEDIT ,,OPERATION MANUAL?

If yes can you describe more precisely what you intending to do ? I mean is that a command button that you looking toi insert or something else

Please note that there are signed & unsigned integer 16...

With more clarification teh better we can support from here..


Appreciate the quick response. I've reviewed the GE manual you referenced, as well as Cimplicity's built-in help info. I think I understand the concepts around Events, Procedures, Points, etc. Most likely I am missing some specific info on how Cimplicity interfaces with the Mark V.

What I intend to do - nothing yet. Just need to understand how the existing system works. Here's a more detailed description of what I am seeing:

-There is a button on the main screen labeled Turbine Shutdown.
-Turbine Shutdown button has an event defined for Mouse Up.
-Mouse Up calls procedure Ctrl_Turb_Shut.
-Ctrl_Turb_Shut uses the AbsoluteSetpoint action to set the point S1_L52T_CPB to 16.
-S1_L52T_CPB has data type USINT.
-These is a contact in the Mark V logic called L52T_CPB that should be closed by this button.

If you need more details let me know.

And to reiterate my questions:
-Why set the point to 16? Wouldn't 1 make more sense?
-I haven't found any buttons or procedures that will set S1_L52T_CPB back to 0 (or whatever value is needed to open the contact in the Mark V). For the logic to work, the Mark V contact has to be pulsed closed, not maintained closed. Would Cimplicity do something behind the scenes to set S1_L52T_CPB back to 0?


Thank you for this reply and clarifications...

I would ask if you talking about this procedure :


If so I would suggest you to look for what is called "Cimbridge " and Cimplicity workbench documentations ...I had it once a time but now need to search on my archives if i can get it...

Will have a search and come back here for more details to add..

Why the number 16 instead of the number 1? It all depends on how the number 16 (decimal) is interpreted in the program.

I have no familiarity with any turbine/Mark control system, but would assume that the single bit 1 in the integer 16 (binary 00010000 in an 8 bit unsigned integer) in its given bit location is the needed bit to trigger the action you mention. Maybe other other bits in the word are used for other actions?
"Why the number 16 instead of the number 1? It all depends on how the number 16 (decimal) is interpreted in the program."

It's most likely NOT CIMPLICITY that's doing the setting/resetting as much as it's the Operating System in the Mark* V when it gets the command from the HMI (CIMPLICITY) to do the setting/resetting. And, it would help if we could "see" the CSP (Control Sequence Program) to understand a little better the signal being toggled.

THIS is one of the most frustrating parts of the Mark* turbine control system. GE Salem opted to use CIMPLICITY (now called PROFICY MACHINE EDITION) as the graphical user interface for the Mark* turbine control system (beginning with Mark* V). BUT they didn't want to allow people/control system integrators/anyone to be able to use it to communicate directly with the Mark* turbine control panel. SO, in the Mark* V they interposed TCI (Turbine Control Interface), a GE proprietary MS-Windows service to serve as a "buffer" to keep people out of that communication protocol.

In the process, and as CIMPLICITY matured and GE Salem learned how to use CIMPLICITY functions, the way that many functions--PARTICULARLY CPBs (Control Push-Buttons) were changed and changed and changed. And, true to form (as colleagues used to say, "Salem is consistently inconsistent!), GE Salem documented NOTHING. That's what makes it so frustrating.

One undocumented "perversion" of the command push-button targets had them being set/reset for a period of time from the CIMPLICITY screen button, and if I recall correctly that value was the time (in sixteenths of a second) that the contact would be closed. Does this CPB get set by a CMDSTATE block? Or does it just "appear" in the logic with coil or rung or block writing to it? In the definition for the signal (usually in one of the .ASG files or in the UNITDATA.DAT file), can you compare the type of signal to other CPBs to see if the definition for this particular signal is different than other CPBs? Again, without knowing a lot about version of CIMPLICITY and the Mark* V CSP there's not much more I can add.

Except to wonder why you are so "concerned" with this particular CPB and its operation. Is it now working as you think it should? Is it intermittent? Or??? I've never been a fan of how the steam turbine department chose and configured control signal names, but 52 is the device number for a breaker (usually an AC (Alternating Current) breaker), and a suffix of "T" usually denoted "tripping" or "trip." Is this signal initiating a lowering of load and opening of the generator breaker and a normal coast-down of the unit, or???

Anyway, best of luck. I doubt I can add much more--and I may have just added confusion (I hope not!). Trying to keep up with GE Salem's HMI changes was a losing proposition--mostly because of the lack of documentation of the system and all of the changes. And as other commissioning personnel did I just returned the software to GE Salem when it didn't work and they would fix it and send it back (they should have properly tested it before sending it to the field, but ... testing is time is money, and back then GE was all about reducing costs at all costs... and if they could get the field people to fix "small" problems with the HMI that was money that didn't come out of their profits).

I don’t have my notes with me for a better explanation, but like WTF? said it’s the time cimplicity holds the point true to send to the MarkV. 16 is the standard and I believe32 is the max and is 1 second. So 16 holds the value for 0.5 seconds. I have seen one that was set at 1 and the button had to be pressed multiple times to work, cimplicity needs to hold the value for some time for it to be sent to the MarkV. I’ll try to post again when I look what I have written about it
Thanks everyone for the excellent replies. This information is exactly what I needed. Using the number written to the HMI point as the timeout value is quite devious. I'm impressed.

For those who were wondering, I brought up these questions because I'm doing a controls upgrade on this steam turbine. So this particular Mark V is headed for the trash. My personal preference is to understand what I'm replacing before I try to replace it, hence the questions. I don't have any concerns with this particular shutdown button, it was just a representative example of what I was seeing on most command push buttons in the HMI. I believe this "set to 16" method is used consistently on all HMI points that are associated with writes to coils in the Mark V.

Once again, thank you all.


In Cimplicity there are settings called Ticks. The 16 ticks as WTF commented, is time based and in normal design is for 1 second. This was standard for all Cimplicity jobs. One of Salems biggest problems was field engineers who thought they knew all about Cimplicity and made changes based on what they had heard from others who did not have a clue as to what consequences would be brought about by their changes. So, Salem’s requisition engineers spent many hours a week resolving call in help support issues that was covered under Salem warranty.

There are considerations Salem had to deal with when moving to Cimplicity. Like any program today, processor speed, computer (HMI) speed, App coding which all come from various OEMs have specifications that do not play well together. The answer for Salem was to write code (IDOS, TCI) that allowed all the various non-Salem OEM process to work as best possible. These systems were tested rigorously in Salem prior to release. Were there issues, yes and Salem addressed each and every one as they were discovered.

When thinking about ticks for the PBs, consider the feedback for operator displays. Those data points can be modified to update at 1/16 second or 3 second intervals. At 1/16 interval you would not be able to make any sense of what was taking place much like if the update was at 3 seconds. With your new system you will be implementing, you will surely have the same decisions to make for operator data refresh rates and I’m also sure your ability to make those and other changes will be much simplified over Cimplicity! Good luck on your controls migration.