MarkV Control System

R

Thread Starter

RAM

In Speedtronic MarkV control system, what is the meaning of designated processor? I mean to say, what function is the designated processor doing? Is the <R> controller the designated controller always?

In the maintenance manual-5980, it says that the processing load of <R> should be kept as low as possible. Is there any specific reason for that?

One more thing, if we kept view file running for a large period of time on the LCC display, the DCC error continuously counts up. Has anyone seen this?

Thanks and regards,

RAM
 
In the GE Speedtronic TMR system when one control processor fails or is powered-down, there can no longer be two-out-of-three (or, TOOT) voting, so it is the job of the Designated Processor (sometimes referred to as the Designated "Voter") to determine the states of logic signals and logic outputs in the execution of the CSP and operation of the unit. The designated processor is that control processor which, in the event of a loss or failure of one of the other two control processors in a TMR unit (while the unit was running), would be the "decider" of logic determination and outputs, primarily.

When all three control processors are operating properly, <R> is always the Designated Processor. If, <R> is the control which was powered-down or had failed while the unit was running, then <S> becomes the Designated Processor. <T> should never become the Designated Processor....

The Designated Processor also performs some background communications functions for the DENET, so it's idle time is usually a little lower than the other two control processors.

Yes; if you keep a VIEW2 file running at 32 Hz for a long period of time, especially if it's "hammering" the Designated Processor, the DCC errors will usually increment. If you look closely at the output of the VIEW2 routine, you will usually see some slight time "differences" (i.e., the data points sometimes skip a couple of milliseconds)--it is believed this is the result of the DCC errors. The DCC just gets "over-loaded" at times with requests for information and the DPM (Dual-Ported Memory) and memory buffers--especially if SOEs and/or EVENTs are enabled and/or there are a lot of Process- and/of Diagnostic Alarms occurring at the same time--just get "over-run."

The good news is that the CSP seems to keep being executed properly and the operation of the unit doesn't seem to be adversely affected when there are a lot of DCC errors.

There is usually almost NO reason to ever use VIEW2 at a 32 Hz rate, since most CSPs are executed at an 8 Hz rate.... So, that means that if VIEW2 were run at 32 Hz, most data values would only be changing once every four data points.... Further, if one is trying to use VIEW2 to monitor servo-valve output currents (CDB (Control Signal Database) pointnames FAL, FAG, FAGR), the values of those signals only get "reported" to the CDB from the software regulators on the TCQA cards at a 4 Hz rate--even though the currents are changing at a 128 Hz rate! So using VIEW2 to monitor servo-valve output currents at anything other than a 4 Hz rate is fairly pointless.

markvguy
 
Thanks Markvguys again for your indetail explanation.Yes it clears the thought and concept.

In this context just i would like to clear one of my doubt is that in MARKV TMR system
it is the <R>-PROCESSOR which is always the designated one.How it it is determined that <R> will always be the designated one.Is it that is comes as part of firmware(EPROMS) and internal coomunication,which is beyond our scope to know.

In MARKVI there is weighting algorithm that is being executed in all 3 control processors independently,based on the result of that algorithm the designated controller will be selected.

So in MARKV is there anything like that to determine the designated processor.

Thanks and Regards

Ram
 
It is hard-coded into the firmware as part of the operating system in the Mk V turbine control panel. The order of designated processors in Mk V TMR control panels is fixed and is not calculated, cannot be observed, and cannot be changed.

In Mk IV, the determination of which processor was "in control" when one processor failed or was powered-down was a calculated value, and it seems GE have returned to using a calculated value to determine the designated processor with Mk VI as well.

markvguy
 
Thanks for your valuable comment.

In our markv TMR panel while the turbine was not running I was doing an experiment. The designated processor was <R>,indicated by the symbol"V" in the LCC display. The idle time of <R> was 39%, <S> was 42%, <T> was 42% and <C> was 20%.

As the <R> is the designated voter so as you already said its idle time will be less, because for its internal communication right.

Now I switch off the <R> core, immediately the <S> core becomes the designated processor, indicated by symbol "V" in its LCC display. One of the things I noticed is that the idle time of <S> and <T> increase to 51% and that of <C> core increases to 38%.

Can you please tell me the reason for this, as previously i was unaware of that?

Regards
RAM
 
When all three processors are controlling, each frame (remember this discussion?) consists of reading inputs, communicating inputs, voting inputs, executing the CSP (Control Sequence Program), writing outputs, and idle time. The process is repeated each frame the CSP is executed.

It would seem (since this author has never pondered the situation before), that when <S> is the designated processor there is no longer a need to communicate the values of each processor's inputs and then vote those values before executing the CSP and writing to the outputs. <S>'s values will be used by <S> and <T> in executing the CSP and writing to the outputs, and <C> doesn't have the overhead of taking values from <R>, <S>, and <T> and keeping track of them for communication to the <I>/HMI if needed.

This is pure conjecture, but it kind of seems to make sense....

Okay, here we are again discussing things which don't affect unit operation and can't be modified and can't be observed (since the Mk V's internal operating system isn't accessible), and it was presumed we weren't going to do that any more....

Can you tell us the three typical Combustion Monitor conditions which will trip the unit? Can you tell us why some contact input values are inverted? Can you tell us how to read CDB (Control Signal Database) signal names L63HG1L and CPKRAP (without looking at LONGNAME.DAT)? Aren't the answers to these questions more important than why the idle time on <S> and <T> increases when <R> fails or is powered-down?

This author believes there is no such thing as a dumb question--only dumb answers. However, some questions are more appropriate than others. (Well, there is one dumb question: "It's broke--what do I do?" You have to imagine that being said with a Texan drawl to get the full effect....)

markvguy
 
Top