Hello,

Our MarkV DCS - TMR - <C> Core has 23 % idle time or so without any connection with <I>

What should I do to resolve this problem?
How can I raise the idle time to over 30 %?

If we shutdown one of R, S, T, <C> core 's idle time is raised to about 36 %.

Please Help us.

 

When did this "problem" start?

What happens when you connect a working <I> to the Mark V <C> processor?

Specifically, which display are you looking at when you say the "Idle Time" is 23%: the Normal LCC/SLCC display on the keypad, or the Idle Time display accessed through the LCC/SLCC keypad?

Is this low "idle time" causing problems for either the turbine or plant operation or the <I>?

What kind of turbine is this Mark V installed on? Or is this one of the very few Mark Vs that were used as a DCS system (they're pretty rare!)?

 

Thank you.

answers are as below,

1. this problem started 8.l8
Voting mechanism has some problem ?
because if one of core is off, idle sore to 36 %

2. As you know the LCD of Normal LCC/SLCC display on the keypad displays Idle value

3. It seems that low idle may cause the error messages of LCC ERRORS

4. I don't know How Could I check MarkV Kind .

if I know your email,
I can give you the diagnostic Alarm Img
mine : yjdoo28 [at] gmail.com

I think it has some relation with voting system
Because when I shutdown one of Cores , <C> Idle value was raised from 22 to 36 %

Actually Before that problem happened, I did do somethings as below

1. I Changed the Voter ID <S> => <R> and then restore it.

2. I wrote some data on the Voting points using Spy to see voting mismatch alarm.

To restore the system I did EEPROM Download all to R, S, T and C, but there was no difference

Thank you.

 

You haven't answered all of the questions, and if you're playing with SPY and changing voter IDs, you're on your own. I didn't ask what kind of Mark V you were working on, I asked what kind of turbine the Mark V was being used to control. In your original post you indicated the Mark V was a DCS, and there were very few Mark Vs actually used as DCS control systems.

Do you know what the "idle time" was before you used SPY?

The idle time of <R> is always going to be less than that of <S> or <T> because <R> is the 'Designated Voter' and as such it has extra tasks and duties to execute.

I think the percentage that's shown in the LCC/SLCC Normal display is *not* the 186 idle time; I think it's the LCC idle time.

If the "idle time" was higher before this problem began when you started changing Voter IDs and using SPY, the only thing I can suggest at this time is to "erase" the EEPROM of all processors, then re-download ALL to them. The process would be to use the EEPROM Downloader and download the FORMAT partition/section to <T>, and then re-boot <T> using the power switch in <PD> core. When <T> is going through initialization it won't find anything and so it will get "stuck" at I/O Status A3/A4--but that's okay. Then use the EEPROM Downloader to download ALL to <T>, and when it's successfully completed the download, re-boot <T> processor using the power switch in the <PD> core. It should return to I/O Status A7.

Repeat this processor <S>, then <R>, then <C>--one at a time.

 

Posted by CSA on 31 August, 2010 - 7:47 am
"You haven't answered all of the questions, and if you're playing with SPY and changing voter IDs, you're on your own. I didn't ask what kind of Mark V you were working on, I asked what kind of turbine the Mark V was being used to control. In your original post you indicated the Mark V was a DCS, and there were very few Mark Vs actually used as DCS control systems."

=> Sorry, Actually this system is not for DCS Control but for Turbine.

"Do you know what the "idle time" was before you used SPY?"
=> It 's about over 30%

"The idle time of <R> is always going to be less than that of <S> or <T> because <R> is the 'Designated Voter' and as such it has extra tasks and duties to execute.

I think the percentage that's shown in the LCC/SLCC Normal display is *not* the 186 idle time; I think it's the LCC idle time."

=> Sorry, I didn't understand your answer, I didn't say 186 but 23 %

"If the "idle time" was higher before this problem began when you started changing Voter IDs and using SPY,
---- snip ----

=> Thank you so much, I'll do it !
And let you know the result, thank you

 

Dear CSA,

I did download all sections following your recommends.

But there was no difference.

I did it from <T> core to <C> core Step by Step,
After Downloading Fromat Section, rebooting. The TCS reached to A5 instead of A3/A4.

And then Downloading All, rebooting. The TCS reached to A7. But there was no Difference on Idle Time.

When our <I> Systems and another system (using Arcnet) communicate with TCS <C> core, there are some errors like belows,
DPM ...
NO MEMORY ERROR ..
BUFFER OVERFLOWS ..

Is anything like trouble shooting note to know these error message ? and fix it?

Thank you.

 

Actually Abnormal Messages are as belows

"3PL BAD INIT
53 DCC ERROR
IO OBJ .. ERROR
QST DPM TIMEOUT "

Thank you.

 

First, it's revealed that you were using SPY and other unsupported applications. We've still never understood if you know what the "idle time" was before you began using the unsupported applications to know if there is really a difference in "idle time" at all. Third, now we learn:

> When our <I> Systems <b>and another system (using Arcnet)</b> communicate with TCS <C> core, ... <

Something is asking for information or data that doesn't exist or the format of the request is incorrect.

3PL refers to the cable that connects the LCC/SLCC to the DCC/SDCC and to the TCQA (for <Q>) or TCCA (for <C>). So, it might seem there is some problem with the 3PL cable not being properly inserted, but that's just a guess at this point.

Whatever it is you are doing, with your "other system (using ARCnet)" and SPY, it doesn't seem the Mark V (the "TCS"???) likes it very much.

I'll say it one more time: the "idle time" you are referring to, if it's the percentage in the 'Normal' display is not the i80186 idle time, which is reported using another key sequence on the LCC/SLCC display.

But, you're on your own at this point. DPM means Dual-Ported Memory. QST means Queue Server Task. If there is a number after IO OBJ, that refers to the "socket" number of the affected card. Look in the I/O Configurator's <Q> and <C> card menus and the number under the card name is the socket number.

The problem may also be in what you're downloading. If you're not downloading a known, good configuration (I/O Configuration, CSP, Control Constants, etc.) then that might explain some of the error messages. Again, we don't know exactly what you're up to and what you've done and what you're downloading.

But, that's all I can add to this discussion, as you seem to be doing something unusual or developing something and looking for support without really providing the "rest of the story" so you're on your own! Best of luck!

 

Actually we have a MarkV Simulator.
So we want to know the functions of MarkV more details, Thank you. we need your help ..

 

The chin strap was a dead giveaway....