Mark V Simplex C Processor


Thread Starter



This is my first post on We have a GE Mark V system with only R and C processors (which I believe is considered a 'simplex' system).

Every once in a while the communications disappear on the HMI and we have to reset the C processor by performing the following steps: Clear the error messages, turn off the C processor, wait so many seconds then turn the C processor back on. The HMI indicates the turbine has tripped and needs to be reset.

Has anyone had similar experiences with a Mark V C processor intermittently needing a reboot and what would cause the C processor to suddenly stop? Where would the error messages that pre-date the locking(?) of the C processor be found in the HMI directory?

I am new to the Mark V and I am just now working my way deeper into the innards of this thing.
Any help would be very much appreciated.
Yes, your unit has a SIMPLEX Mark V.

HMIs can "overload" the StageLink and cause a loss of communications with <C>. Most often, the only way to reset the communications is to re-boot the <C> processor.

There can be many causes for the overload. CIMPLICITY asks for the status of every point in the project, whether or not the point is being displayed on a screen. And it does that at least once per second. Also, if the HMI is being used for MODBUS communications to another device, if the MODBUS.DAT isn't configured properly or is
asking for too much data at too fast a rate this can be a problem. The same goes for GSM links, if being used.

There is a "limit" of two HMI Servers per Mark V; this is an "unwritten rule" and some properly configured HMIs/CIMPLICITY projects can allow more than two Servers per Mark V. But, most as-shipped/as-installed HMIs have poorly configured CIMPLICITY projects, asking for points which aren't in the CDB, or asking for points that aren't used on any display, or asking for points from units which don't exist.

If the operator interface was upgraded from an <I> to an HMI, the comm problems can even be more pronounced and subject to loss/interruption.

Usually, the LCC/SLCC display will show some errors and error messages prior to hanging up. There are threads on which talk about
how to use the LCC display to check for errors; I think it's also discussed in the Mark V Maintenance Manual, GEH-5980.
Thank you for the reply... very much appreciated.

The C processor hasn't hung since I posted - just hangs very intermittently - which is the most troubling aspect.

We have GE coming for other problems and I'll hit them up for 'further education'.

Thanks again for your help.
Please let me clear up a few things. The Stage Link inteface is Client-Server. When a client (e.g. CIMPLICITY) asks for data, it assembles a list of points and Mark V responds with the data. TCI handles the transaction, and throttles it to once per second. Mark V points in CIMPLICITY are "On Demand". What that means is that CIMPLICITY will ONLY request the points that are either on an open screen, on a cached screen, on an open point control panel, or have a trend buffer defined. So, CIMPLICITY does not ask for all the points all the time. However, the (Salem designed) Manual Sync object has its own, private interface. It requests point data at frame rate. If this object is on an open screen, it can eventually cause communication problems for the C processor. Gas turbines use a separate screen for manual sync, but steamers mostly did not. If you have a steamer with this object in the unit_control screen, I recommend you move it to its own screen. This will lower the load on C.
The GE Mark V StageLink interface is an ARCnet-based token-passing network. I don't think that really fits the Client-Server definition, but I'm not a network guru.

I wonder why GE says the number of <I>s (which are basically "servers" in the GE Mark V HMI sense) for any Mark V panel is "infinite", but the number of GE Mark V HMI Servers for any Mark V panel is "limited" to two. I've even seen one poorly configured GE Mark V HMI Server "crash" a Mark V <C> processor withoug someone leaving a Sync display open open longer than required for synchronization. I've seen Sync displays open for long periods of time during troubleshooting without crashing a Mark V <C> processor. But, I think the type of ARCnet card, the versions of TCI and CIMBRIDGE and the version of CIMPLICITY all factor into the potential for problems. Unfortunately, no one's ever created a matrix for versions vs. problems.

I've always understood that <I>s were "on demand", only asking for the information which was being currently displayed or required for MODBUS or some trending function. That's why the number of <I>s for any Mark V is basically unlimited, because the StageLink traffic is so light compared to a GE Mark V HMI.

Now, when someone has Logic Forcing or Prevote Data open on a GE Mark V HMI for long periods of time, or even has multiple instances of either function open and running in a window on a GE Mark V HMI, *that* can really bring a Mark V StageLink to its knees. Both programs are requesting data from all processors at a pretty fast rate; Logic Forcing is continually asking if any logic is forced. Prevote Data is asking for "fast-voted" and "slow-voted" data as fast as possible. So, both increase StageLink traffic greatly. It's not a good idea to use a Logic Forcing display to monitor data points; one should create a User Defined Display for long-term data monitoring rather than a Logic Forcing display.

I don't want to start a long discussion on this because most of us, myself included, don't have a lot of the details that would be necessary to support or dispel one version or another. I'm simply sharing my experience and what little knowledge I have, which is very little because I, like others, have an extreme distate for CIMPLICITY as implemented on a GE Mark V HMI. And one of the biggest reasons is because of the lack of information available and the abundance of "tribal knowledge" much of which is simply myth and legend.
The topic is very much interesting

We do have simplex Mark V system and we faced similar communication failure at which master protective trip signal is activated.

The problem occurred more than once over the last 7 years. Actually the master protection relay shut off alarm is posted in the equipment trip log file before the communication failure alarm.

However, GE confirmed at all cases that the issue has to do with EPROM firmware upgrade. At all cases, EPROM was upgraded but the event is still persisting.

did you experience similar event?