We have Mark V turbine control system for our Frame 6 GAS turbine. after rebooting the <C> processor, it is not coming to A7 state. it is showing A4 state and SDCC status showing "00". after changing the SDCC of <C> still <C> is showing A4 state and SDCC status showing "00".

Kindly suggest some check points.

 

shyam,

Hmmmmm....

GE recommends using a light film of conductive grease (usually supplied in the boxes spare cards are shipped in) on all of the ribbon- and cable connectors. This grease usually needs to be re-applied every two years or so. Have you been applying conductive grease to all ribbon cables and other cable connections in the Mark V?

The best way to do this is during maintenance outages, when the turbine is shut down and the control system can be shut down. Unplug every ribbon cable--ONE AT A TIME, of course--and apply a thin film of conductive grease across the face of the female part of the connector. Too much grease is just as bad as no grease, but there needs to be enough grease to coat the mail pins of the connector when it is re-inserted. Then re-insert the female end of the connector into the receptacle, and remove and reinsert the female end of the connector a couple more times, making sure on the last reinsertion the connector is firmly seated in the receptacle. Wipe of any excess grease from around the connector. Do this for all other types of connectors, as well, and be sure that the earth (ground) connectors of all cards with earth connections (the earth (ground) connectors are usually single white wires with female lugs that slip over male lugs on the printed circuit cards and are connected to an earth bus at the other ends of the wires) are also firmly seated.

This is also a good time to use a vacuum cleaner to perform some housekeeping in the Mark V panel, also. Dust, when combined with any humidity, is very harmful to printed circuit cards.

Another possible problem could be a blown fuse (or two) on the TCPS card in Loc. 5 of <C>. To see all the fuses, it's best to remove the card from the core, and lay it down on a non-conductive surface (one of the bags used for spare parts cards works very well for this) and carefully look over the card and locate all of the fuses, remove them and test them with a resistance meter. At least one of the fuses is very small and almost hidden between larger components on the card. The pocket on the back of every Mark V core door contains sheets for every card in the core, with the locations of fuses and connectors. This can be helpful in identifying fuses on the TCPS card. (Just remember to replace the sheets in the pocket....)

Lastly, there is a ribbon cable that connects the LCC/SLCC to the DCC/SDCC to the TCCA, and, I believe to the optional TCCB, if used. I believe the cable is identified as 3PL, and it has NO pull tabs on it. (Every other ribbon cable in the Mark V has pull tabs which should be gently used to remove the ribbon cable from its receptacle.) MANY times the connectors used on 3PL get disturbed because people incorrectly pull on the cable because there are no pull tabs on the cable connectors. Usually, all that's required is to firmly push on the back of each the 3PL cable connectors to make sure they are firmly seated and making contact with the cable's conductors. This is a very common problem (along with corrosion on cable connector pins and sockets), and great care must be used when disconnecting 3PL from any of the cards it is used on--again because there are no pull tabs so people usually just tug on the cable, which can cause the connectors (which are just "pressed" on to the cable) to come loose.

That's about all I can think of. The <C> core is connected to <R>, <S> and <T> via the DENET (see the Mark V Maintenance Manual, GEH-5980) and <C> will not go to A7 unless at least one of <R>, <S> or <T> is also at A7. I presume the other cores are all at A7, but I just needed to mention that. Sometimes people power down <R>, <S> and <T> when working on <C> and expect <C> to go to A7 when the other processors are shut down--and it will not. <C> has to see at least one of the other control processors (cores) at A7 before it will go to A7.

Please write back to let us know how you fare in resolving the problem. If you haven't applied conductive grease to any Mark V connectors before, or if it's been more than a couple years since you have--now is a good time to do so. The problem you are experiencing is most likely either caused by a loose/bad cable connector, or corrosion on pins and/or sockets of cables/connectors, or blown fuse(s) on the <C> TCPS card. I re-read some of your past posts and it seems you have 125 VDC battery grounds "disappear" after just disconnecting and reconnecting cables before. And, that 3PL cable without pull tabs is a common problem, too.

 

Thanks for your support, we checked all the ribbon cables and TCPS card fuses of <C> processor all are fine. Now we are planning to change SDCC card after getting the new one. Before that can you explain what are the procedures after changing the SDCC card of <C> with new one. ie, in my knowledge after changing the SDCC card we need to change the voter ID and stage link ID? where can I find these ID in <I> computer? need to down load something to <C> after changing the SDCC card? we changed the SDCC with old one that time we lost<I> communication and we checked stage link id and could not set. "not" like some message is coming, I think before that I should have to set voter ID. Can you explain regarding voter id and voter id setting? Your prompt reply is highly appreciable.

 

shyam,

Thanks for the feedback.

I believe the Mark V Maintenance Manual, GEH-5980, describes the process of setting Stage Link ID and Voter ID. It's done with the SLCC keypad. Once you access the "menu" of possible options on the SLCC you scroll through the various options using the INC and DEC buttons on the keypad. For <C>, you will need to set the Voter ID to C. For the Stage Link ID, you will likely need to look in F:\CONFIG.DAT to find the Stage Link ID of the Mark V <C> processor.

(If you have been able to check the status of the various cards using the SLCC display and keypad, then you scrolled right past the options to check/set the Voter ID and the Stage Link ID.)

I don't have access to GEH-5980 at this writing, but I'm pretty sure it describes how to use the LCC/SLCC keypad and display for setting Stage Link ID and Voter ID. Just follow the prompts on the display, and when it says "OKAY; FINE" remember to re-boot <C> to get the information to take effect and remain in EEPROM.

You also need to move the PROMsets from the SDCC card being replaced to the one being installed. Use care when doing so; PROM pins can be damaged very easily. And, they are static-sensitive, so use appropriate cautions. Pay particular attention to the orientation of the chips in the sockets. And, it's recommended to ONLY REMOVE AND INSTALL ONE CHIP AT A TIME.

And, the hardware ("Berg") jumpers need to be set to the same positions on the new card as on the card being replaced. This is VERY important.

Depending on the version of SDCC card you receive, it may come with a card configuration file which needs to be copied to the F:\UNIT1\PROM subdirectory, and then the I/O Configurator will have be updated for the card following the directions provided. If that's the case you will also have to download the IOCFG partition to <C> and then re-boot <C> to complete the process. But, if that's necessary, there should be instructions to guide you through the process.

There is a little "trick" that works really well if the particular chip isn't damaged--and they're usually not, but the only way to tell is to swap them as follows. I believe the PROM marked as U9 is the EEPROM chip where all of the processor-specific information is stored. It usually doesn't have any label on it, and it is a socketed chip. You can carefully remove the U9 from the new card and install the U9 from the old card, and that will have the Voter ID and Stage Link ID on it already. Unless you had to update the I/O Configurator for the new SDCC card, if you transfer the U9 chip you won't need to do anything--just check the Voter ID and Stage Link ID to make sure they are correct (if the <I> is getting data when <C> is powered-up the Stage Link ID and Voter ID are likely good!), then if <C> goes to I/O State A7 all will be good and you won't have to do anything else. Just check the I/O States of all the other cards (they all have to go to A6 for the processor to go to A7).

Hope this helps! And write back to let us know how you fare.

 

Shyam,

I believe you are changing your SDCC card and i have quite of these in stock. BRAND NEW.

If you could give me your e-mail id, i can send you my profile with the price.

I can supply immediately so that there is no downtime.

Will wait to hear from you.

Cheers,
Briha

 

Thanks for your great support,can you explain your below comments in detail,we are waiting for the new card.

>Depending on the version of SDCC card you receive, it may
>come with a card configuration file which needs to be copied
>to the F:\UNIT1\PROM subdirectory, and then the I/O
>Configurator will have be updated for the card following the
>directions provided. If that's the case you will also have
>to download the IOCFG partition to <C> and then re-boot <C>
>to complete the process. But, if that's necessary, there
>should be instructions to guide you through the process".

we are getting some voter mismatch alarms for some signals in <R>, <S>, and <T>. actually these signals are repeating signals (4-20ma) from f&g system of some other associated skid particularly Flame detector of that skid and used for only indications in mark V HMI<I>. the problem is f&g system is showing normal and all flame detector reading also showing normal in f&g HMI (00.00), repeating signals are connected to the <R> core. Mismatch alarms coming for only these signals.

once again thanks for your valuable reply and support.

 

Shyam,

In the later years of Mark V production "the factory" would often send a floppy disk with some batch files to install files in the PROM subdirectory as part of card replacement. (They did the same when new PROMsets were provided, also.) And if I recall correctly there was one version of SDCC that, if used as a replacement, required replacing the SDCC_CFG.DAT file in the PROM subdirectory. But, that would be documented in the instructions and floppy disk supplied with the card. This was a special case, but felt worth mentioning. I recall one site receiving the card and failing to read the instructions was initially unable to get the new card to work. After reading and following the instructions they were successful.

I've not seen the Diagnostic Alarm on 4-20 mA inputs you are describing. If this is not a new problem but something that has been ongoing for some time, my best advice would be to make sure the wiring for the signals is properly terminated--specifically the shield drain wires (which should only be terminated at one end). Also, if I understand the problem correctly, if the power for the loop is supplied by the repeater then sometimes there can be ground loop problems with the Mark V. Check the hardware ("Berg") jumpers for the return leg of the loop. Sometimes the only way to tell if there's a problem is to change the position of the ground jumper (which is either IN or OUT) to see if it has the desired effect. Refer to Appendix D of the Mark V Application Manual, GEH-6195, for details. Again, if the problem has been ongoing for some time, then a loop isolator may be required--but that would be a last resort.

If the inputs go to the TCQA (or optional TCQB) card then a component of the card in <R> might be failing.

Also, nuisance Voting Mismatch Diagnostic Alarms can be caused by corrosion on ribbon cable pins/sockets. Sometimes just unplugging cables several times, and an application (or re-application) of conductive grease will resolve the problem.

Please write back to let us know how you fare in resolving all of the problems you described in this thread.

 

Thanks for your support, we changed all the cards of <C> one by one (SDCC, TCCA, SLCC, TCPS, CTBA and <CD> TCDA), but still <C> DCC showing "00" state, TCCA=4 ,IOMA=3 like that. we changed <C> SDCC all EEPROMS and done the down loading also but still the problem is persisting, ie, DCC showing "OO" state. we checked all the ribbon cables which is connected with SDCC card all are fine. We are not getting the communication between SDCC and TCDA we checked the IONet cables that is fine also. Status of <R>, <S>, <T> Showing A7. Is there any other check points is remaining to solve this <C> core "A4" state issue?

Once again thanks for your prompt reply.

 

shyam,

From the information provided in this post and the post below this appears to be the same site/problem:

http://control.com/thread/1452436292

WOW! If you've replaced all of those cards, and the PROMs, and the TCPS card, then I'm stumped, too, but I have some ideas--keep reading.

If the StageLink ID and Voter ID were wrong, you couldn't talk to the Mark V from the <I>/HMI. Have you used the SLCC keypad to check the I/O States of the cards?

As I say near the end, I would be trying to isolate <C> from everything else at this point. I would suggest reading through the ideas below, then developing your own "most likely to succeed" list of activities, and working through them one by one until you've tried them ALL. Just remember to write down every step you take--and the findings. It will be helpful as you try to restore everything when you've finally found and resolved the problem.

If there's an EX2000, have you disconnected that coaxial cable from <C> and tried cycling the power on <C>?

Myself, I have to believe it's a cabling problem--and I still suspect the 3PL cable. Either that or something is causing the power supply voltages on the SDCC card to be "pulled down" (less than they should be) on the SDCC, or on the SLCC. But, I've suggested some things to try below.

Have you tried unplugging the power supply cable from the TCDA in <CD> and also the <C> IONET cable? I think there are IONET termination resistors and hardware (Berg) jumpers on the TCCA card, you might also try temporarily setting those jumpers to IN and unplugging the IONET cable from the TCCA (presuming I'm right about the IONET to <CD> terminating on the TCCA; I don't any Mark V Signal Flow Diagrams to look at at this writing, and it might connect to the CTBA; you need to refer to the Signal Flow Diagrams in Appendix D of the Mark V Application Manual, GEH-6195). This would completely isolate the TCDA from <C>, but it's only a long-shot guess at this point.

Are you absolutely certain that the TCPS in <C> is properly grounded (earthed)? In other words, if you disconnect the white ground (earth) cable (when the power to the TCPS is isolated from <PD>) and measure the resistance of the wire to ground (earth), it should be pretty near zero ohms.

I believe the 3PL cable connects the SLCC to the SDCC to the TCCA. And, it seems <C> can see the TCCA.... I'm just thinking "virtually" at this point....

I don't recall what the 8PL cable does; again, I don't have access to any Mark V manuals right now.

Have you tried using the SDCC card from <C> in <T>? You would have to change the PROMs and if you didn't change U9 you would also have to change the Voter ID, and FORMAT, then ALL. (Don't forget to upload the TOTD information first from <T>!). This would tell you if the SDCC card you are using for <C> is bad or not. It's a start, eh? If you're presuming the card(s) you've been using are good, and they're not, well then that's a problem. AND, if the card does work in <T> (<T> gets to A7) then you definitely know it's something wrong with power supply and/or cabling in <C>.

Have you tried disconnecting all of the I/O from the CTBA card? You can't unplug all the ribbon cables from the CTBA card, because at least one of them, I believe, connects the CTBA to the SDCC (perhaps through the or directly to the SDCC (I can't recall), but if there's some extraneous voltage or high-frequency signal getting into <C> from it's analog I/O....

Have you tried disconnecting the DENET cable from <R> to connects, I believe, to the TCCA card? I think it's an unshielded twisted pair cable, with a two-pin connector.

That's about it. If you can be certain the SDCC (and perhaps even the SLCC) are good (by substituting them into <T>), then it certainly seems it has to be cabling or power supply voltage(s). Unfortunately, you can't see Diagnostic Alarms in <C> (probably), so that's not going to help. Have you tried using DIAGC to look at any of the cards/PROMs in <C>?

I would be trying to just isolate <C>, even powering down <R>, <S> and <T> and <P>. You may even need to remove the power to ALL of the discrete inputs (including <QD1> and <CD>), and the solenoid output power (to both <QD1> and <CD> as part of this isolation of <C>.

I would also be trying to understand what changed during the maintenance outage that might have caused this problem. Have you looked at all the circuits that were disconnected and then reconnected during the outage when the power to the Mark V was removed?

Was anything else done in the Mark V during the outage--ANYTHING? Any wiring "disturbed" in the Mark V, or in the field?

I've just never run into this kind of problem before. Ever. I would suggest using the SLCC from <T> (since you've also borrowed the cables from that processor for this troubleshooting), but I'm worried about possibly damaging that card, but at this point, it's worth a try--but after first trying one of the SLCC cards removed from <C> in <T>. You'll have to change the SLCC PROMsets, but it's worth a try at this point. If the card(s) don't work in <T>, then that's something else you didn't know before. I don't know what it tells you--other than the SLCC cards are bad. Though not likely, I'm wondering .... about the only component you haven't tried replacing is the SLCC keypad....

It's a VERY long shot, but have you disconnected the coaxial cable from the <I>/HMI to the CTBA--at both ends--and meggared the main conductor to ground (earth), as well as the shield/connector body? Have you just left the StageLink (coaxial) cable disconnected from CTBA and powered-up <C>?

PLEASE write back with information--hopefully even the resolution. Perhaps someone else reading this can provide some ideas. I'll try to think of anything else to try, but at this point, I think trying to prove the SDCC and SLCC cards you're using in <C> are good, and by trying to isolate <C> as much as possible from everything else in the Mark V is the best course--about the only course I have to suggest. Unfortunately.

BEST OF LUCK!!!

 

Just a Thought....

Have you done an upload from the other cores? and or compared running program with what's on <I/HMI>.

IF running program was changed and not updated, I think you may face a problem like this.

 

Sorry for the late reply, our problem solved by changing the brand new <C> <SDCC> CARD. THANKS......CSA and all, but still have the problem for voter signals in <s> and <t> so we are waiting for the new tcqc card for <s>.