Communication between <C> and <Q>

F

Thread Starter

Farid26

Hello

We have a problem about I/O in C core. IO status don't reach A7, it stopped in A5 level. This failure didn't affect the turbine running but other problems begin to appear like a command execution and visualisation (ie the inputs(feedback...) allocated in CD didn't validate in R, S, T, D and the HMI's connected through D couldn't get the real status of this signals,the opposite case through C.

We tried to resolve IO status problem in the first place, so we log in DCC monitor with the LCC keypad, IO C cards status function was checked, only these random characters were diplayed <16> **** -- 1F when i scrolling through this function. What mean that ? and can the IO cards status affect the communication between C and R, S, T, D , how a can use the hexadecimal bit encoding in denet diagnostic data with diagnostic counters tool because this bits changed frequently in tow states.

Thank you for your answers.
 
Farid26,

When <C> isn't at A7, then it can't access its I/O--which includes the inputs and outputs connected to <CD>, as well as to the analog inputs to <C>. So, if you're sending commands to <CD> using discrete (contact) inputs when <C> is not at A7, <C> can't recognize them.

<D> can't see <C>'s I/O when <C> is not at A7. <D> typically doesn't have any I/O of its own (there were a couple of one-off implementations of <D> that did have inputs and outputs, but they were not the norm).

I don't have a max-case IO_CFG.LST file for a Mark V at this writing, but for <C>, Socket 1 is the TCCA card; Socket 4 is the TCDA card in <CD>; Socket 8 is the LCC or SLCC card; Socket 12 is the DCC or SDCC card; Socket 13 is the IOMA "card" (which isn't really an actual printed circuit card, but a chip on the DCC/SDCC card). I'm wondering if Socket 16 would be for the TCCB card, which is an optional card supplied with some Mark V panels--but that's just a guess.

In general, when you are using the DCC Monitor function of the LCC/SLCC keypad when you encounter any "socket" that displays as asterisks ("*"), that means that the LCC/SLCC can't communicate with that card--and that's likely the reason the processor can't get to I/O State A7. (That's basically explained in the Mark V Maintenance Manual, GEH-5980, I believe.)

You should be able to see an I/O Status for every card configured for a particular processor using the DCC Monitor function of the LCC/SLCC keypad. If there's no I/O Status for any card, then the communication with that card--or that card--has a problem. I'm guessing the other cards shown in the DCC Monitor for <C> all show I/O Status A6, or most of them anyway. A6 is the I/O Status that says the card is reading its inputs and communicating with the other cards and is ready to enable its outputs--<b>BUT</b> ALL cards must get to I/O Status A6 before they will all go to I/O Status A7. (One or more cards can change from I/O Status A7 while the processor is at A7, but this is unusual and will usually be accompanied by a LOT of Diagnostic Alarms to indicate there is a problem. But, they all have to get to A6 before they will all go to A7 and the processor will then go to A7.)

DIAGC displays are usually very suspect, because the configuration file for DIAGC must EXACTLY match the revisions of the cards AND PROMsets in the panel or the information won't be correct. I'm not saying yours isn't correct--I'm just saying the odds it isn't correct are very high (in favor of NOT being correct). The only place where you can get help with information in DIAGC is GE. And, they don't like to support Mark V turbine control panels; they want to sell you Mark VIe.

Hope this helps. You need to understand what cards are associated with <C>, and then find out which card (Socket 16 from your post) isn't communicating and why and resolve that, and then if all the other cards are at A6 when you re-start <C> it (<C>) will eventually go to A7. As for interpreting information from a DIAGC display, you're going to need GE's assistance with that.
 
Top