We had to power down our site for some distribution work, and when we went to restore power to the MKV panel (TMR) the S and T cores would only get to A6 while the C and R would reach A7 successfully. We also received almost 30 diagnostic alarms with most of them relating to the R core/TCQA card.

I also noticed a few "power supply out of limits" alarms which led me to check the power supply voltages in the DIAGC menu and found them to be curious to say the least on the R core. The S and T cores appeared "normal".

P5 = 5.8V
P15a = 4.74
N15a = 16.6
P15b = 16.6
N15b = -3.62
P125V = 148 ????
N125V = 148 ????

I tried replacing the TCQA card in the R core but that did nothing. I also noticed that the alarm beep isn't there when powering up the units or when alarms register. It was very weak sounding the last time I heard it as well (warbly).

We also tried the power supply card in the R core as a last ditch effort with no change in status.

Any suggestions on where to go now?

Thanks!

 

I've seen this happen before when power to the panel was removed by opening the "main" supply breaker and then re-applied by closing the "main" supply breaker. The proper method for shutting down a Mark V panel is to open the switches in the <PD> core (if so equipped; very early Mark Vs did not have switches for <C>, <R>, <S>, and <T> and <X>, <Y>, and <Z> so the plugs for these cores had to be manually unplugged) one at a time, then remove the power to the panel by opening the "main" supply breaker. Power should be re-applied in the reverse manner, by closing the "main" supply breaker to the panel then closing the processor power supply switches (or plugging the plugs back in) *one at a time*, beginning with <X>, <Y>, and <Z>, then powering up the control processors (<R>, <S>, and <T>) *one at a time* waiting for each processor to reach A6 or A7 before powering-up the next processor. <C> should be powered-up last, since at least one of <R>, <S>, or <T> must reach A7 before <C> will go to A7. (In other words, <C> will not go to A7 unless one of <R>, <S>, and <T> goes to A7.)

Have you used the LCC/SLCC display keypad to find out which card/cards are holding <S> and <T> from reaching A7? There have been several posts to control.com with the step-by-step process to use the keypad to determine the status of each card. I believe the process is also described somewhere in the Mark V Maintenance Manual, GEH-5980, along with a *brief* description of what each status means (though not much about how to "repair" a non-A7 status). Write back if you have questions. The number at the left of each card's status display is the "socket" number, which can be equated to the numbers on the cards in the I/O Configurator display. I believe this is also documented somewhere in the Maintenance Manual, though briefly.

Also on control.com, it has been said several times that DIAGC displays are not always to be entirely trusted. I believe the main reason given is that DIAGC.DAT must *exactly* match the versions of cards and PROMs installed on the cards in panel in order for the data to be trustworthy, and there are only a couple of people in the world who can say if the file matches the panel's cards/PROMsets and many panels do NOT have proper files for their card/PROMsets.

I would power the panel down one processor at a time, then power it back up as described above--beginning with <X>, <Y>, and <Z>, then <R>, <S>, and <T> (one at a time) and finally <C>. I've successfully used this process to get processors back to A7 without doing anything else. (This usually really angers maintenance people and managers when it works!) Patience is the key, and "hitting" the panel with power from the "main" supply breaker with all the switches on/plugs in doesn't work very effectively. It does "in the lab" in a training environment, but not usually very well in the real world when I/O is connected to the panel. (I wish they wouldn't use this method in training classes; it's a time-saver, but it's not the proper way on a running panel in the field with I/O connected to it.)

If the processors don't go to A7, then use the LCC/SLCC keypad to determine which card or cards are preventing each processor from reaching A7. Then, you need to get that card to A7 (easier said than done sometimes). Write back if you have questions or need assistance.

 

Thanks for your reply.

I did check the DCC/LCC keypad and found that the TCEA cards in the <Y> and <Z> locations were not responding. I also verified this as the green LED's on each card were dark. After pulling the <Y> I found two of the three 1.5A fuses had blown. Same situation on the <Z> card.

We had two spare TCEA cards so I put the first card in the <Y> position and it came up successfully as did the <S> core.

The same cannot be said for the <Z>. The LED bar graph on each card illuminates and I've been told there is possibly a way to decipher what the lights mean, but regardless the <T> did not go to A7. So, to do a little troubleshooting I swapped the <Y> and <Z> to see if the <T> would come up with the known good TCEA card that was previously in <Y>. Nope. Hmmmm. So I swapped them back to my first attempt and now the <S> didn't come up!!!

I keep getting "Missing IO Card" on the cores and was told it's a berg jumper issue, but I verified the jumper positions and everything checks out. I cannot figure why moving the one card that fired up fine originally on the <S> to the <T> and then back to the <S> stopped working (got the missing IO card again on <S>).

Another thing I was wondering about is the card "Group". The cards that came out were a "1B" but of the two spares I have a 1B and 2B. If I recall the TCEA-2B is the one that worked originally, so that didn't seem to matter.

I was also advised that I may have to default the card in the IO Config editor. I tried that but it made no difference.

I'm stuck! Help!

Thanks again!

 

I think now you have a cable problem and/or a hardware jumpe. You may be a victim of the lack of keys on the ribbon cables. The "trace" of a ribbon cable (usually the red, sometimes the black, edge or conductor of the ribbon cable must be placed such that it's towards PIN1 of the card connector. Usually, there's a 1 silk-screened on the card to indicate the side of the connector with PIN1. The card layouts in the plastic pockets on the backs of the core doors usually show which edge of the connector is PIN1, also.

The LED bargraphs should all blink the same indications at the same frequency as the others (in the <P> core); that's about as much use as they are. When one shows a different blinking rate or a different frequency, there will usually be one or more Diagnostic Alarms associated with that card.

Refer to the Signal Flow Diagrams in Appendix D of the Mark V Application Manual, GEH-6195, and make sure all the ribbon cables connected to the TCEA cards *AND* the TCTG card are all properly connected *at both ends.* This is especially true of the two-conductor IONET cables which run from <R>, <S>, and <T> to the TCEA cards (<X>, <Y>, and <Z>, respectively).

There are hardware ("Berg") jumpers for addresses of the TCEA cards, J4, J5, and J6. If you swap cards, these jumpers need to be set properly for the position; they differ for <X>, <Y> and <Z>. I think this is all spelled out in the App. Manual, in Appendix A, 'Hardware Jumpers.'

The TCEA hardware jumper positions for J8-J27, the Emergency Overspeed trip frequency settings, must match *exactly* the settings in the I/O Configurator for the HP- and LP Overspeed trip settings. See the screens of the TCEA card for details. If the hardware jumpers don't match the I/O Cfg values, the processor won't go to A7. Period.

This not directed specifically at you but just as a general precaution: *NEVER* (as in *NOT EVER*) change hardware jumper settings to match some paper document or some display on an operator if there is a discrepancy between jumpers in a running unit and some setting specified on some piece of paper or on some display on the operator interface. If the unit was running fine and something causes you to question a hardware jumper setting when troubleshooting, consider the as-found hardware jumper setting to be the correct setting, not some piece of paper that was recently located or some operator interface display which was recently consulted. Unless you personally know the piece of paper is correct or the operator interface display is correct, trust the as-found positions, especially if the unit has been running fine for some time with those positions.

In your case, since you have good hardware jumper settings for J8-J27 on the TCEA of <X>, make sure the positions on <Y> and <Z> match <R>. Make sure the J4, J5, and J6 hardware jumpers are in the positions specified for <X>, <Y>, and <Z> in the App. Manual. And make sure J1, J2, and J3 are in the Default position as shown in the App. Manual. In general, make all the hardware jumpers on <Y> and <Z> match those on <Z> *with the exception* of J4, J5, and J6, and make those three match the values in the Application Manual for <X>, <Y>, and <Z>. In other words, make <Y> and <Z> match <X> with the exception of J4, J5, and J6 which are processor-specific.

If you defaulted a card, I hope you had a copy of the card settings before you defaulted the card and reset the values after you defaulted the card.... If you defaulted a card without resetting the values to the application-specific values and downloaded to the panel, this is going to also be a problem. Make sure you have the proper values for the TCEA card for your application (on every screen of the I/O Cfg'r. for the TCEA card), making sure to 'Verify' any changes you make before changing screens, and then 'Save and Exit' when you quit the I/O Cfg'r. before downloading to <R>, <S>, and <T>. Then you need to reboot the processors, one at a time, and if you made changes to TCEA values, you also need to re-boot the TCEA cards to get them to read the EEPROM in their associated control processor and download the settings during the re-boot.

 

I managed to achieve A7 on all cores!

I still have issues with some oddball alarms that I haven't resolved and not sure where to look.

Here are the diagnostic alarms:

<C> 3155 Voter mismatch, <R> Q_R_POS10
<C> 3152 Voter mismatch, <R> FSG_B
<C> 3151 Voter mismatch, <R> FSGR_B
<C> 3144 Voter mismatch, <R> FSG
<C> 2078 Voter mismatch, <R> L64D_N
<C> 2077 Voter mismatch, <R> L64D_P
<C> 2076 Voter mismatch, <R> L27DZ
<T> 1314 TCQA Servo Current #3 Disagrees w/Ref
<S> 1314 TCQA Servo Current #2 Disagrees w/Ref
<R> 1337 TCQA LVDT Position Diff High Reg #2
<R> 1336 TCQA LVDT Position Diff High Reg #1
<R> 1314 TCQA Servo Current #3 Disagrees w/Ref
<R> 1313 TCQA Servo Current #2 Disagrees w/Ref


Do those have any meaning or give anyone a hint on where I should narrow my troubleshooting?

Thanks! Have a happy Thanksgiving.

 

It would be nice to know what steps you performed to allow all the processors to get to I/O Status A7. It would also be nice to know how the panel was powered-down and powered back up (which started this thread).

Most signal names are described in the file LONGNAME.DAT, in the F:\UNIT1 directory.

As for your "oddball" alarms, the first four in the group are related to LVDT feedback signals. Q_R_POS10 refers to the feedback connected to "Position Feedback Input #10", terminated on <R> core, <Q>'s control signal database. It's odd that it doesn't have a signal name, like CSGV_B, which is what is usually connected to input #10, but sometimes the second LVDT input didn't get assigned a unique name (still works anyway; one of those little Mark V quirks we all know and love!).

FSG_B is the second LVDT feedback for the Gas Control Valve; FSG is the first LVDT feedback. This IS the odd one, because it's odd that both of them are problematic for the <R> processor. Something's amiss here and needs to be resolved.

FSGR_B is the second LVDT feedback for the Stop-Ratio Valve., and it's also odd that <R> is seeing a problem with all these LVDT feedback signals. Sure seems like there's a problem with the TCQA or the TCQC card in <R>.

L64D_N and L64D_P are related to ground detection voltage levels, again in <R>, and L27DZ is also related to ground detection. Still pointing at <R>'s TCQC or TCQA card.

Usually, servo-valve output #1 is assigned to the Stop-Ratio Valve servo; servo-valve output #2 is assigned to the Gas Control Valve servo; servo-valve output #3 is assigned to the Liq Fuel Bypass Valve servo; servo-valve output #4 is unassigned; servo-valve output #5 is assigned to the IGV servo; and servo-valve outputs 6-8 are unassigned. (You can find all this in the I/O Report and IO.ASG).

The two TCQA LVDT position diff high alarms are related to the Stop-Ratio and Gas Control Valve LVDT feedback problems. The two <R> TCQA Servo Current Disagrees w/Ref alarms are also related to the LVDT feedback problems.

It sure seems like there's still some kind of problem with <R>s TCQA. Fix that first and you'll probably find most of the Diagnostic Alarms will go away.

It's been said before here at control.com, and it's something that's made the Speedtronic-related posts especially helpful: Feedback is the most important contribution. If you've found something useful, it's helpful for others to know what it was that was useful. Many people read these posts, both current posts and in the archives, so without feedback it's difficult for others to know what suggestions were helpful and which ones weren't. Please help keep the tradition alive.

 

Thanks again for all the information... it is much appreciated. Yes, looking back I guess I didn't state what I found to get the cores back to A7. I was short on time and had to get going (holiday, etc.).

The first problem was that the two TCEA cards in <Y> and <Z> were bad and were replaced. Maintenance had powered down/up the unit using the main breaker that fed the MKV panel. This will not happen in the future I can tell you that! The PD core will be used from now.

What else had happened to make the troubleshooting more problematic is that I was given some bad information about the IOCNFG editor, which I had limited experience with prior to this exercise anyway. With the TMR application there should only be one TCEA "card" listed and active in the <Q> setup screen. This was true, but I was told that the other two that were "purple" had issues and that's why they were showning as "purple" or inactive.

After finding out the two TCEA cards were bad and replaced, I then configured the two TCEA cards that were shown as "purple" in locations 16 and 17 but was getting the "Missing IO Card" on all three cores now. I finally determined that the information I received regarding the IOCFG was wrong and went back to just having one TCEA card (location 15) configured and all three cores were restored.

Throw in a bad TCEA card that was pulled out of inventory and it quicly becomes a real big headache trying to troubleshoot this with my limited MKV experience as well as bad information from a supposed reliable source!!

Anyway, that leads me up to this point with the remaining assorted alarms. Everything led me to believe that the TCQA card in <R> was having issues so it was replaced with no change. We fired the unit yesterday for testing and everything went well, but I would like to resolve these few alarms to make me feel better.

Thanks again.

 

At the turbine site should be a copy of GE's GEH-5980 SPEEDTRONIC MARK V TURBINE CONTROL MAINTENANCE MANUAL.

Another useful manual is GEH-5979 SPEEDTRONIC MARK V TURBINE CONTROL USERS MANUAL.

The third manual is GEH-6195 SPEEDTRONIC MARK V APPLICATION MANUAL.

They are available from GE on CD as pdf files if the copies are lost. I suspect that someone would email a copy if you had provided a throw-away email address otherwise GE could sell replacements. The Mark V is no longer manufactured by GE but support is still available. I cannot provide the files as I work for GE.

GE Industrial SystemsPost Sales Service
1501 Roanoke Blvd. Salem, VA 24153-6492
USA Phone:
+ 1 888 GE4 SERV (888 434 7378, United States)
+ 1 540 378 3280 (International)
Fax: + 1 540 387 8606 (All)

 

Okay, I'm kinda confused here with this reply, but it is nice to see that there is someone from the OEM "monitoring" this forum.

Danno, if you look in Chapter 7 of the Application Manual, you can see some information regarding the "path" of LVDT excitation and feedback circuits through the Mark V. Besides the 125 VDC power supply alarms, most of the Diag. Alarms you have are related to LVDTs and servo-valve outputs. Between Chapter 7 and Appendix D you should be able to follow the signals through the Mark V and replace the cards until you resolve the Diagnostic Alarms. I believe the Diagnostic Alarms are all related to printed circuit card problems, but that's just a guess from the info you've provided. You say you've run the unit and it's okay and that's good news, but it's not clear if you still have all the Diag. Alarms, or just some, or none.

 

I have the GEH-6195B, GEH-5982, GEH-5992, and GEH-5981 manuals.

I do not have the 5980 or 5979 manuals though.

Thanks for the information.

 

Danno, obtain and post a throw away email address from gmail or hotmail. I am sure someone will send you the missing documents (hint!). I keep such an email address and toss it when it starts to get spammed. I use Linux at home so I don't worry too much about problems with opening an email.

It looks like you have an older system as your GEH-6195 is an earlier revision; it is currently rev G. Your other manuals:

GEH-5982 SPEEDTRONIC MARK V TURBINE CONTROL SEQUENCE EDITOR USERS **OBSOLETE** REPLACED BY GEH-6195

GEH-5992 SPEEDTRONIC MARK V TURBINE CONTROL MODBUS USERS MANUAL**OBSOLETE**, REPLACED BY GEH-6195

GEH-5981 SPEEDTRONIC MARK V TURBINE CONTROL BBL REFERENCE **OBSOLETE** REPLACED BY GEH-6195

are no longer available.

I lurk on this site during my lunch breaks. I have some Mark V experience so I appreciate the help that CSA and markvguy both provide as I can relate to the problems in the field. I learn a lot from these guys and someday I may go back into the field.

I have had my fair share of diagnostic alarms and they can be a real challenge to solve. I am a pack rat and found my collection of documents to be a big help.

The pc for the <I> is no longer manufactured. If you have old pcs from your IT department then keep any similar parts such as hard drives. Any hard drive larger than 8 GB may not work on an <I> even if a partition of 2 GB is used similar to the original installation.

One thing CSA did not mention is using the special grease for the connector pins on the Mark V cards. It seems that tin-plated connectors with no lead in the plating will corrode and cause signal problems. Replacement cards come with the grease and instructions. I had to remove, grease and replace connectors which sometimes did solve the spurious signal problem. The removal of lead from the plating has caused many problems. NASA even lost several satellites to this problem.

I hope this helps. I know these threads get archived so I attempt to add information that may help any one who reads these. That is why I added the information on the obsolete documents.

 

Alarms are still there.............

walleyedan at gmail dot com

Thanks!