Today is...
Saturday, May 27, 2017
Welcome to, the global online
community of automation professionals.
Featured Video...
Featured Video
A demonstration of EtherCAT control of linear motors using the CTC EtherCAT master.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Designated Controller in Mark VIe
How is the designated controller defined?

Mark VIe control system ( TMR), Frame 7EA. Can someone please explain about the designated controller in Mark VIe system? How the Mark VIe decides which controller is designated? All controllers are connected with EGD for communication then why do we need designated controller?

Thanks for your time.


I'm hoping demigrog will contribute and clarify any statement I make here.

In the Mark IV (remember that?) there was a <C> controller, and its main purpose was to display the voted/median/high select value of signals and data. There were three control processors and each processor could have its own value for any signal (shouldn't be much difference, but there could be), and there had to be a method for displaying a single value when there were actually three values for most signals (I/O that was connected to the three, redundant control processors). Any "software" voting that was done was done in <C>, but it was very limited.

In the Mark VI (and later Marks*) there is a designated controller for a couple of reasons. First, one of the controllers have to send their value to the HMI for display. Second, if one of the control processors in a TMR control panel fails or has to be shut down, then one of the remaining controllers has to be "in charge"--because you can't vote two values reliably. You can vote two out of three, but when there's only two one has to be the "voted value."

In the Mark IV there was a calculation about which controller of the two remaining controllers when one had failed or was powered down would be the controller (the so-called "designated voter"). In the Mark VIe, by default under normal circumstances <R> will always be the designated controller when all three controllers are healthy and communicating. If <R> fails or is powered down or is not healthy and communicating, then <S> becomes the designated controller, again, by default. <T> can never be the designated controller, because that would mean that both <R> and <S> had failed, and if that happens, the turbine is going to be tripped and there's no need for a designated controller, except possibly for ratchet/cooldown operation.

If <T> fails, is powered down or is unhealthy and not communicating, <R> will be the designated controller, by default.

I believe that if you connect to the designated controller when all three processors are happy and healthy and communicating you will be able to see the pre-voted values of all three processors in the Pre-vote Tab for each signal. But, if you connect to <R> or <S> or <T> when all three processors are happy and healthy and communicating you will only see that processor's value on the display and there won't be a Pre-vote tab, because you have selected a particular processor. (I don't have access to a Mark VIe at this writing, but that's what I recall. I may not be right, but that's what I seem to recall. I rarely ever connect to any controller other than the designated controller unless I'm downloading parameters/code and/or troubleshooting a particular issue when I want to see a particular processor's value (pre-voted).

There are some very large differences between the Mark IV and the Mark VIe in how signals are determined and voted. In the Mark IV, each processor used what it believed the value of any input to be, and made it's calculations using that value, and its outputs were a function of the inputs and calculations. And the four processors (<C>, <R>, <S> and <T>) were NOT synchronized (that's one reason why there can be so many voting mismatch alarms on signals, especially output signals like relay outputs) on the Mark IV. The <C> processor did any voting of signals that was required.

Beginning with the Mark V, each control processor read its value of each input, then communicates its value to the other control processors, and each control processor votes on the values of inputs using its value and the other two control processors' values and then executes the logic/application code--and under normal circumstances the outputs, when written to after a scan of the logic/application code is complete the outputs will normally be the same. This is called "Software Implement Fault Tolerance" and is the big difference between the Mark IV and later Marks*.

In order to do this reading, sharing, and voting and execution of the logic/application code the three control processors (and <C> in the Mark V) have to very tightly synchronized--which the Mark IV was not. In the Mark IV, one control processor could think the turbine should be tripped on low-low lube oil pressure, but the unit would not trip if the other two believed the lube oil pressure was not low-low. But, in the Mark IV if another processor believed the unit should be tripped on incorrect IGV angle the unit would trip--with NO alarm. Because there wasn't two-out-of-three agreement on what should trip the turbine, but there was two of the three trying to trip the turbine, but for different reasons. There would be Voting Mismatch Diagnostic Alarms, and the Auxiliary Display could be used to determine any control processor believed the turbine should be tripped.

Beginning with the Mark V, if <R> thought the lube oil pressure was low-low and the turbine should be tripped but <S> and <T> did not, <R> would use the not low-low signal and would NOT try to trip the turbine. There would be Voting Mismatch Diag. Alarms, but all three processors would be keeping the unit running. If <S> (or <T>) then believed the IGVs were out of position and the turbine should be tripped, <S> (or <T>) would use the voted value if IGV position and would not try to trip the turbine. There would be voting mismatch Diag. Alarms, but all three processors would still be keeping the unit running.

This is the big difference between the Mark IV and later Marks*. The three control processors are very tightly synchronized and each control processor uses the voted values of inputs when executing the logic/applications code, and theoretically (and practically) the processors will always come up with the same values for outputs (except for things like servo references and triple redundant transmitter inputs/feedbacks, etc.). Where the Mark IV could falsely trip a turbine on not two out of three, the Mark V and later Marks* can not--because of fault tolerance. Which should also make the overwhelming majority of output signals identical, so a designated controller can display it's value of signals and outputs and (voted) inputs accurately on an HMI.

And, when one of the three control processors fails, the designated controller's values are used as the voted inputs by the remaining control processor and the turbine will continue to run--under normal circumstances, of course. (I say this because someone always says, "Ours didn't!" but it always turns out that were a lot of other Diag. Alarms which hadn't been resolved which were indicating a problem which would contribute to a possible trip.)

This is my understanding based on readings and conversations and experience. Now, others may have a different understanding and conversations and experiences, and I may not be 100% correct--but it would take someone with some pretty detailed knowledge of how Salem does things these days to provide better information. (In my opinion....)

And probably a little more information that you wanted, but hopefully it helps with the answer and the understanding.

By chiranjeevi on 28 April, 2017 - 8:49 am


As there is no C communicator in MARK VIe, but when panel is powered on, as designated controller meant for providing initialization data to other controllers. how designated controller provides data to other two controllers?

How frame sync takes place between IO pack and controllers?

In MARK VIe system,i got an alarm indicating PCAAHI1 R failed communication,giving:
"Exhaust TC hardware fault" alarm.
It got immediately recovered.

My question is: if all PCAAH1A R, S, T I/O packs communication fails from pack to controller because of Ethernet cable fault, then what is the TTXm value it measures ?

Can anybody explain the above?


In the days of the Mark IV, the use of EEPROM was not widespread, in fact when the Mark IV was first designed and produced the <C> processor used battery-back RAM (BRAM) to store sequencing and information. <R>, <S> & <T> did have to go to get programming information from <C> during initialization.

In the Mark V, each microprocessor card in each processor (<C>, <R>, <S>, & <T>) had EEPROM and didn't need to go to <C> for any information.

In the Mark VI and Mark VIe, it was less expensive to use a <C> as a "gateway" to the control processors and by the use of a designated controller the necessary information could be passed to the HMI for operator use and monitoring.

During initialization of the control processors in the Mark VI and the Mark VIe they all have to be synchronized over the IONET before the outputs are enabled (at least two of the three in TMR system, anyway). This is all part of the initialization and the operating system which runs in the processors--including the protective processors. It can take several minutes for Mark VI and Mark VIe processors to get synchronized with each other when booting-up a panel after it has been powered down or lost power. It's a lot of communication and "hand-shaking" and sharing and such that has to take place before all the individual I/O cards and -Packs in a single processor get synchronized, and then each processor gets synchronized with the remaining processor(s).

As for exactly how all that happens, it's FBM (Friggin' Black Magic). All behind-the-curtain-stuff. And, it's fairly reliable (as long as the IONET cables, and -switches in the Mark VIe, are all working correctly and conducting).


First of all, it's not clear what the alarm was, and when it occurred, and what was happening at the time. As for exhaust T/Cs connected to the three PCAAs, the application code knows how many exhaust T/Cs are connected to each PCAA, and if the signals from one PCAA (out of three in a TMR system) are lost then the application code simply removes those T/C values from the calculation of TTXM and spreads. And, if the exhaust T/C values from two PCAAs are lost at the same time, well, the unit is going to trip (if it's running).

If the Mark VIe was installed as an upgrade to an older turbine control system there are some key activities which must be done to correctly ground (earth) the system. And, if the Mark VIe is a Mark IV Migration then great care needs to be taken during installation and commissioning to ensure the individual panels of the package are properly grounded as is the Mark IV panel itself. Amazingly enough, MANY Mark IVs were NOT properly grounded during installation. Sometimes they suffered a lot of nuisance problems (alarms; tripping; etc.), and other times nothing. BUT, when upgraded to a Mark VIe via a Mark IV Migration the existing Mark IV panel grounding has to be checked, and corrected if necessary, during a Mark IV Migration.

Hope this helps!