Hi colleagues,


We have Frame 6 gas turbines (type 6001B), which run on diesel and fuel oil, controlled by a GE speedtronic Mark V triplex (TMR). The Mark V cabinets version installed is: A.
On the "Prevote data display" we have <T> which gives different values from those of <R> and <S> even when the turbine is stopped. Also when we reset <R> by the white button, the LCC display displays after A5: "Missing IO card" then "IO CFG failed" then "DCC IO reset" and continu to reach A7. So we have A7 states on <C>, <R>, <S>, and <T>.
We start the turbine and couple it to the grid without problems, but after a certain time (between 1 hour and 5 hours) it trips without clear tripping alarms. On the "diagnostic alarms" we have many alarms.

What's wrong.... any suggestions?

 

One of the very nice--and useful--features of this version of Control.com is that one can post pictures and electronic files to their post(s). You need to take a CLEAR picture of the Diagnostic Alarm Display when the unit is running, when it's at zero speed (or on Cooldown ("ratchet")) and after a trip event. If you need to post more than one photo to incorporate all the Diagnostic Alarms--do it. But, we need to know what Diagnostic Alarms are active in order to be able to even begin to help you.

It's extremely unfortunate that the developers of the Mark* V did not have a convention or standard for the boot-up messages which were displayed on the LCC/SLCC display. And, as software versions changed so, too, did some of the boot-up messages. There was/were some version/versions that displayed an IO CFG FAILED message during the boot-up sequence, and it was/is confusing to many people. But, if you are able to reach I/O Status A7 (which is necessary to be able to START the machine) then the message is one of those poor boot-up messages that came and went with different versions of software (on the socketed chips) in the Mark* V. (A former contributor to Control.com liked to say the developers of the Mark* were consistently inconsistent--and he was correct, sadly so.)

Using the "white button" on the DCC/SDCC card (called a "soft reboot") to reboot a Mark* V processor is really not recommended because it DOES NOT reboot any I/O cards which are NOT located in the processor itself. For <R>, <S> & <T> this includes the TCEA cards in <P> and the TCDA cards in <QD1>, and <QD2> if so equipped; for <C> it includes the TCDA card in <CD>. There are really very few times when it is recommended to perform a soft reboot with the white button on the DCC/SDCC card; in fact as I write this I don't recall when it is better to perform a soft reboot than a hard reboot--by using the switches on the TCPD card in <PD> (or by unplugging and replugging in the cable for the desired processor in <PD>; early versions of the TCPD didn't have switches for the processor power supplies so it was necessary to remove and reinstall the cable for the power supply to perform a hard reboot).

If you want help with what caused the machine to trip you will need to post CLEAR photos of the Alarm Display immediately after the trip event and BEFORE any well-meaning but poorly trained operator initiates a MASTER RESET. This is CRITICAL to understanding what happened. GE has a really poor practice of blocking other trip conditions which might occur after the unit was already tripped by a previous problem, and that can and does make troubleshooting difficult--but NOT impossible. As with the Diagnostic Alarm photos you need to show all of the Process Alarms (top to bottom) for us to be of proper assistance.

You may not be able to post all the photos required in a single reply to this thread--just keep using additional threads to get all the photos in the thread for review and analysis.

That's all I can say without a comprehensive list of Diagnostic- and Process Alarms. Even if they don't make sense to you, they will to someone here. And, EVERY alarm (Process and Diagnostic) means something. Some alarms are nuisance alarms, meaning they shouldn't be annunciated like a Hydraulic Filter Pressure High process alarm that comes in every time the unit is started and clears a few seconds afterwards--that's a problem with the filter needing to be changed, dirty oil or sometimes it's just a matter of adding a little time delay to the alarm to say it must exist for 5 or 7 or 10 seconds before it is annunciated to get through that high pressure when the system is started; it could also be that the hydraulic system pressure and/or the hydraulic system pressure relief valve or the hydraulic pump compensator valve needs to be properly adjusted, repaired or replaced--but it means something and shouldn't be ignored. Any alarm (Process or Diagnostic) which comes and goes and comes and goes needs to be troubleshot--it's probably NOT a Mark* V issue, but it could be, and it needs to be resolved to prevent the operators from ignoring it, and other, alarms. It's incumbent on the I&C (Instrumentation & Control) technicians to work diligently to resolve these "dithering" nuisance alarms, because they can--and SHOULD BE--resolved.

I can't think of the file name off the top of my head right now but there should be a Trip History or Trip Log file that gets created after EVERY trip event, an electronic file that you can copy to removable media and post to a thread for help. The portion that may be most helpful is the Process Alarm section towards the bottom of the file, and that should also be visible on the operator interface monitor. You could take CLEAR photos of the Process Alarm section of the Trip Log or Trip History display and post them to this thread, also; that may prove very useful in trying to understand what happened to cause the trip event.

Be aware that a single Diagnostic Alarm WILL NOT cause the unit to trip (under normal circumstances). BUT, there are combinations of Diagnostic Alarms (usually in two or more processors) that WILL cause the unit to trip.

Also be aware that even if a processor reaches I/O Status A7 that it's possible for one of it's I/O cards to fall out of I/O Status A7 and the processor will still indicate A7 and will probably have some scrolling messages about the failed card. This is not typical but it can and does happen, though not very often.

It would probably also help if you can describe the plant where these machines are located--just tell us if it's actually synchronized to a larger ("infinite") grid, or if these machines are isolated from a larger grid and supplying some facility or plant (such as a refinery or chemical plant, etc.). It would also help if you could tell us if the power system the machines synchronize to has a stable frequency or if it has frequency deviations from time to time, some more severe than others, and if so, if the machine seems to trip more often during one of these frequency deviation events than when the power system is stable. You said the machines run on diesel and fuel oil--does that mean distillate fuel (like is used in buses and lorries) and light crude oil, or heavy fuel oil (the "bottom" of the crude oil storage tanks at a refinery)? Do the machines use <I> operator interfaces (WITHOUT MS-Windows) or some version of GE Mark* V HMI that runs some version of MS-Windows and GE CIMPLICITY? All of these things could be helpful to understanding the situation and helping to solve the problem(s).

If you want help--we need information. CLEAR photos of alarm displays, including the Process Alarm Trip History or Trip Log display or the entire Trip History file. Please do your best to make sure the photos are clear (sometimes photos taken with some digital cameras (such as on smartphones) will have a lot of horizontal lines in the photo which makes them very difficult to read, and sometimes the photos are no of the full display--side to side; we need time and date information for the alarms, as well as the alarm text messages, to be helpful, especially when trying to discover the "original" cause of the machine trip. Without more information, and clear information, there's not much more we can do. We would like to help--but you gotta help us to help you; we're not there beside you seeing what you see and knowing what you know. You are our eyes and ears.

In the Mark* V Maintenance Manual, GEH-5980, there is a section which describes how to use the LCC/SLCC display and keypad to troubleshoot the failure of a processor to reach I/O Status A7. It is very useful, just remember to write down the card name and I/O Status of each card as you scroll through them. Every card in a processor must reach I/O Status A6 in order for the processor and all of its I/O cards to go to I/O Status A7, but as was written above one I/O card can later fall out of I/O Status A7 and the processor will remain at I/O Status A7--though there WILL NE Diagnostic Alarms and probably status messages on the LCC/SLCC display.

Send us information and we will do our best to help--but we gotta have information. (And, stop using the white button to reset processors; if you need to do that continually something else is wrong and needs to be resolved and we can try to help with that. I shouldn't be necessary to continually keep resetting a processor--ever.)

 

Thank you WTF? for your answer and here are my answers to your questions:
The plant's actually synchronized to a larger ('infinite") grid;
The power system the machines synchronize has a stable frequency;
The machines start-up on distillate and at 5MW we transfert to heavy fuel oil;
The machines use <I> operator interface IDOS and IDP ver 3.5, on the same time HMI TMOS Scada since one year.
On Saturday we checked the states of the I/O cards on LCC and found:

1. For <R>, <S> and <T>:

1 TCQA A7
4 TCD1 A7
8 LCCQ A7
12 DCCQ A7
13 IOMA A7
15 TCE1 A7

1. For <C>:

1 TCCA A7
4 TCD1 A7
8 LCCC A7
12 DCCB A7
13 IOMA A7
Today, turbine stopped, we noticed a scrolling of messages on processors <C>, <R> and <T>:
8 DCC ERRORS
QST DPM NO DEST
N0 QST AVAILABLE
Today we forgot to check the states of the I/O cards on LCC.
On 08/11/2023 we had the following starts and trips:
start-up synchronization Trip
11:36 11:51 12:01
12:21 12:36 12:58
13:12 13:27 13:33
13:46 14:01 14:55
15:43 15:57 17:21
On 08/12/2023 we had the following starts and trips:
start-up synchronization Trip
10:53 11:08 15:06
15:22 15:39 19:52
20:11 20:27 21:52
For the photos and trip log I tried to join them but I had the message : "the uploaded file is too large", i will try to send them in the next reports.

 

The log report taken from the HMI TMOS Scada is Attached here

 

VERY often the messages you see scrolling across the LCC displays are the result of malformed requests for data as well as requests for large amounts of data in a short period of time. Having two types of operator interfaces on the same network most often leads to this type of problem.

I really don’t understand the chronological information you are posting.

I will require some time to decompress the information you sent and review it to be able to make any comments. I have a very busy day today, so I won’t get back for a couple of days or so. Thank you for your patience.

There is a way to “reset” the LCC display error codes using the LCC keypad; it’s one of the options you scroll past to get to the I/O STATES function, but I don’t recall which one. But if those messages are appearing after a trip I would say, again, it’s most likely related to malformed or excessive requests for data. The StageLink (ARCnet network) can be easily overwhelmed, and because of the way the Mark* V prioritizes different types of messages it could be that the TMOS HMI and the <I> (especially if there is more than one <I>) can be causing communication problems.

I would also suggest reviewing the ARCnet coaxial cabling, BNC tee connectors and termination resistors (and any ARCnet fiber optic devices) for poor connections or corrosion or incorrect configuration. Electrical contact cleaner and cotton swabs are good ways to clean BNC connectors.

 

WTF? : Thank you for your help
I think that the chronological information that I have published helps to interpret the alarm messages according to the state of the turbine (turbine on, stopped or triped)
On 08/11/2023 we had the following starts and trips:

start-up	synchronization	Trip
11:36	11:51	12:01
12:21	12:36	12:58
13:12	13:27	13:33
13:46	14:01	14:55
15:43	15:57	17:21

On 08/12/2023 we had the following starts and trips:

start-up	synchronization	Trip
10:53	11:08	15:06
15:22	15:39	19:52
20:11	20:27	21:52

 

You didn't say the Trip Log would be in French.... Adds a level of complexity to the review and analysis.

WHEN DID THIS PROBLEM START? After a maintenance outage? After a trip from load?

I've had a brief look at 08/11/2023, 12-04-42....rtf. The one at the top of the alarm list was preceded by a TRIGGERING BY DIFF. GENERATOR. In the second prior to this there was a LOSS OF CPD BIAS alarm followed by a SHUT-OFF VALVE NOT OPENING (in the same second), So, in my estimation, something cause the fuel stop valve to suddenly close which probably caused the reverse power relay to operate and that caused the generator breaker to open (trip). So, just about whenever there is a loss of fuel flow to the machine there is a sudden loss of CPD (because with no low or no fuel flowing into the combustors the pressure inside the combustors drops suddenly which decreases the backpressure on the axial compressor which causes the CPD to fall just as quickly). Again, in my estimation, something interrupted the fuel flow--and per GE's (loose) standard EVERY condition that results in a turbine trip should have an alarm. But, based on the alarm text messages I'm a little concerned that this may not have happened.

I can't tell much more because I can't see the Mark* V configuration files and the CSP for that machine. AND, I still want to review the other Trip Log files and I don't have time today.

Question: Was the unit running on distillate or heavy fuel oil when the trip occurred? Is the heavy fuel oil heated? How long after the fuel changeover do the trips occur (if they are occurring when running on heavy fuel oil)?

Are you CERTAIN there is no loss of fuel pressure to the machine PRIOR to the trip? Or, that any fuel filter or fuel strainer in the fuel supply to the machine is not plugged (choked)? Or, possibly the fuel strainers (which should be) upstream of the distillate fuel forwarding and heavy fuel forwarding pumps?

Does the machine have a clutch (electric) between the Acc. Gear and the High-pressure Liquid Fuel Pump?

Is the hydraulic system pressure at or very near normal and if a hydraulic accumulator is used on the machine is it properly charged?

A lot of questions, I know, but there's a LOT we don't know about this machine and how it's operated and how it's been maintained, so please help us to understand.

Finally, have you changed the DCC on <T>? (That's the one that occasionally doesn't go to A7, right?)

 

thanks WTF? for your interest,
I'm sorry that the trip log is in French and that I forgot to mention it.
Today we have <S> at A6 and the state of the I/O cards are:
(1) #### A5
(4) TCD1 A6
(8) LCCQ A6
(12) DCCQ A6
(13) IOMA A6
(15) TCC1 A6
The unit was running on heavy fuel oil when the trip occurred.
Does the machine have a clutch (electric) between the Acc. Gear and the High-pressure Liquid Fuel Pump? No, mecanic
The hydraulic system pressure is normal and no change was done for hydraulic accumulator .
We have changed the TCPS on <S> three weeks ago because we had a battery earth 125Vdc and after start-up the processor we had A7.
I think we have 3 problems :
<T>'s vote is wrong for about 75 signals ;
The current state of <S> at A6;
Process alarm: Q 0093 2 communication fault between C-RST
Are there any suggestions for each problem above?

 

The processor <S> is mounted at A7, the same for the I/O state, without intervention on our part. I think we have a fleeting connection problem and when this happens and with the problem of <T> the turbine trips.

 

I think you are likely correct. BUT, there is still the issue of the TMOS HMI and the <I>s all communicating with one Mark* V panel (if I understand correctly--if not please correct me). And there are several questions which should be simple to answer which you have not answered, also. I have seen too many operator interfaces and poorly configured operator interfaces cause problems such as the one you are describing with the error messages you have listed from the LCC display.

Something that isn't well know about the Mark* V (but which has been covered many times before on Control.com) is that the pins and sockets of the ribbon connections can become covered with a non-conductive film, even if the environment where the Mark* V is located. If there is any kind of corrosive atmosphere near the turbines and the Mark* V then that will only add to the problem. Further, if the temperature of the compartment/room where the Mark* V is located is not properly maintained (and it's NOT all about keeping it cool/cold!!!) and there is any dust in the area, then electronics and connections can also be adversely affected.

In every box that contains a spare Mark* V card there should be a small tube of conductive grease. Periodically, the Mark* V should be powered down (in a logical, orderly fashion--not just by removing 125 VDC to the panel!) and each of the ribbon cables should be unplugged and plugged back in several times (to loosen any film) and then a small amount of the conductive grease should be applied to the female socket end of the ribbon cables (too much grease is worse than no grease--so don't slather it on, rather put a reasonable amount of the conductive grease on the connector, but not so much that when you re-insert the connector into the card end the grease doesn't leak out onto the card. Again, it's best if you unplug the connector and plug it back in a couple more times after the conductive grease is applied to help get the grease onto the male pins and into the female sockets of the connector and to help further reduce any film on the pins and in the sockets. This should be done for ALL ribbon cables in the panel. Both ends of all ribbon cables. Even the cables which have only two or four or five conductors should also be treated the same way with conductive grease.

If the panel is dusty (the printed circuit cards) this would also be a good time to use a vacuum cleaner compatible with electronic usage (non-conductive brush!) to remove the dust. Housekeeping is important--VERY important with the Mark* V. AND, keeping the compartment cool--but NOT cold!!--is also very important. A cold compartment (which is a great place for humans to hang out in when its hot and/or muggy outside...!) can cause moisture (humidity) to be drawn into the compartment and condense on cold surfaces--which is NOT a good thing. It can also cause motor starter contactor pole faces to rust, which is not a good thing. I have been in compartments where it looks like it's raining on the metal cabinet doors because there is so much humidity condensing in the compartment. And, people are lounging in chairs to get a respite from the heat and humidity outside, sometimes with the doors open or not fully closed. And, a LOT of installations didn't properly seal the area directly under the Mark* V where field cables were brought up and into the Mark* V control panel and this is another source of humidity coming into the Mark* V AND the compartment.

I think you need to work on determining why <T> has so many mismatching signals--and a CLEAR photo of the Diagnostic Alarm Display would help GREATLY to work on this. I would be EXTREMELY surprised if there were few or no Diagnostic Alarms about these voter mismatches, and that most, if not all, of them are related to inputs (which can affect internal signals not directly related to inputs (and/or outputs)). I/O State A7 only means the card is communicating and healthy and participating in control and protection by writing to outputs. It DOESN'T mean the card is actually working correctly--ONLY that it has been determined to be healthy (communication-wise) to read inputs, execute the CSP and write to outputs. It's ENTIRELY possible that <T> is actually trying to trip the turbine for some reason and when <S> stops writing to outputs (which it will if it's A6) then that's a recipe for tripping in the TMR system. Diagnostic Alarms ARE NOT just nuisance alarms to be ignored, and 75 signal mismatches means there's something pretty significant wrong and that should be investigated and resolved.

As was written before--a single Diagnostic Alarm WILL NOT cause a turbine trip; BUT there are combinations of Diagnostic Alarms (especially on multiple Mark* V processors) that WILL cause a turbine trip. (Before you ask--it's IMPOSSIBLE to list every combination of Diag. Alarms that will result in a turbine trip. BUT by troubleshooting and resolving Diagnostic Alarms quickly significantly reduces the chances of multiple Diag. Alarms combining to cause turbine trips.)

There is a ribbon cable in each of <R>, <S> & <T> that connects several of the cards together--unfortunately I can't recall the cables designation as I'm writing this, but it connects the LCC to the DCC and then to the TCQA and other cards in each control processor. In their infinite friggin' wisdom the designers of the Mark* V chose NEVER to add pull tabs on the connectors of the cable, making removing them difficult when replacing cards. To make matters worse, a LOT of these cables weren't that well made, and when they are not carefully removed and reinserted the clip that helps to keep the connectors on the ribbon cables can get loosened, and in turn this can cause the ribbon cables to become disconnected from the socketed pins in the connectors. It is VERY IMPORTANT to treat this particular ribbon cable--the ONLY one without pull tabs!!!--very gently when removing this cable from a card, and when re-inserting the cable back into the card socket to make sure that the clip is properly clipped in by pushing firmly all along the clip (it's on the very top of the connector) and the two ends of the clip. Many a nuisance trip has been caused by loose connections in the connectors of this particular cable. MANY.

I want to add something here--you mentioned replacing a TCPS card because of a problem with a 125 VDC battery ground. The 125 VDC Battery Ground alarm will ONLY be generated by devices DIRECTLY connected to the 125 VDC battery or supplied by the 125 VDC battery. AND, this includes devices NOT connected to the Mark* V (analog I/O--pressure transmitters, thermocouples, speed pick-ups, vibration sensors, servos, LVDTs, etc., CANNOT CAUSE 125 VDC Battery Ground alarms. Full stop. Period. Devices such as temperature switches, limit switches, pressure switches, 125 VDC solenoid-operated valves, etc. are ALL directly powered by 125 VDC from the Mark* V control panel and CAN cause 125 VDC Battery Ground alarms. So, unless the 125 VDC connector on the TCPS has conductors which have gotten damaged (insulation damage from sharp surfaces/edges, for example) changing the TCPS card won't fix a 125 VDC Battery Ground alarm. In my 20+ years of experience this has never happened that a TCPS card was responsible for a 125 VDC Battery Ground alarm.

Look, I want to help, but the tasks I'm working on at the moment have "blossomed" into something that wasn't anticipated by anyone and I need to get this situation resolved so other work can continue. I'm not getting paid for my contributions to Control.com (and I wouldn't accept payment), but work and personal isues will always come first.

Send us CLEAR photos of the Diagnostic Alarm screens and let us help to get this problem resolved. I'm still looking for some common denominator that could cause these trips, and as of yet I haven't found one. The "missing" TCQA card in <S>'s I/O State list is very worrisome--and points directly to this ribbon cable that doesn't have pull tabs. And if it's been a while, or never, since conductive grease was applied/re-applied to ribbon cable connectors then that should seriously be considered, as well. AND, think long and hard about what kind of communication problems the TMOS HMI can cause when connected to Mark* Vs with <I>s. I have seen this also, but the site wouldn't acknowledge the TMOS HMI was the problem (even when we disconnected the TMOS HMI and the problems stopped...) and wouldn't disconnect the <I>s (which was what the TMOS representative had told them). To my knowledge, they still have intermittent communication issues, and even nuisance, unexplained trips to this day (and that was about 8 years or more in the past).

Help us to help you--give us the answers to the questions and provide CLEAR photos of the Diagnostic Alarm Displays. If nothing else, push firmly on the backs of the ribbon cable connectors in <R>, <S> & <T>--the ones without pull tabs! It CAN'T hurt anything--and it may even help.

And, please, tell us when this problem started. Is it a couple of weeks, or a couple of months? And what happened just before the problem started??? If you can correlate any activity, work, lightning strikes, card replacement(s) (even the TCPS card...), that would be a big help.

GE has a convention (because I refuse to call it a standard since it's NOT published anywhere, even in GE!) that ANY and EVERY condition that results in a turbine trip has a Process Alarm to indicate why the trip occurred. But, for the life of me, I can't find anything--yet--that helps to understand why the turbine tripped. The Loss of CPD bias alarm is pretty constant, but, again, that will happen every time flame is lost in the turbine. So, what's causing the flame to be lost? If the liquid fuel supply pressure/flow isn't stable, especially if the pressure is fluctuating and going very low (less than 2 barg, for example, and then above 6 or 7 barg, then back down to 2 barg, and so on) that can cause problems with maintaining flame, especially if the machine is at a high load. If the liquid fuel stop valve isn't remaining open and is closing early for some reason and interrupting the flow of fuel, that could cause what you're describing (though I would expect to see a LOSS OF FLAME process alarm, and I haven't seen that yet in my (limited) review). If the coupling between the high-pressure liquid fuel pump and the Accessory Gear is loose (and higher loads/fuel flows require more torque through that coupling than starting and acceleration and low load) that could cause problems with liquid fuel flow and cause loss of flame.

But getting CLEAR photos of the Diagnostic Alarm displays and some answers to some of the questions we've asked would also help a lot.

Please keep in touch.

 

As WTF stated, there is a grease that protects the pins of ribbon cable from oxidizing and corroding, its called NyoGel 760G. The cable that connects DCC to LCC to TCQA is the 3PL. Why did TCQA go to A5? Maybe 3PL isn't seated correctly or is corroded. As far as 75 voter mismatches, the vote between <Q> cores happens on a twisted pair daisychain cable between the three TCQC cards called VARC. Once voted it goes to <C> on CARC. This is referred to as DENET. For a <Q> core to communicate to its respective <P> and <QDn> cores it goes on yet another twisted pair daisychain cable JX. This is IONET. There's another cable on TCQC called JBU, this is how the <BOI> bypasses <C> and controls <Q> directly.

This is all documented in the Case Wiring Diagram.

Knowing how each core talks to its respective <P> and <QDn>, and how they communicate with each other helps in diagnosing these problems.

"Process alarm: Q 0093 2 communication fault between C-RST"
That alarm makes me think VARC or CARC, or possibly a TCQC

(1) #### A5
(4) TCD1 A6
(8) LCCQ A6
(12) DCCQ A6
(13) IOMA A6
(15) TCC1 A6

Those numbers in () next to the cards is the Socket number. Losing Socket 1 of any particular <Q> core makes me think 3PL or the TCQA itself, as WTF mentions.

I think you have more than one problem and those problems are now cascading into unit trips.

 

Also see attached. Helpful in understanding what is going on at any A status.

 

Hey everyone, it's been a hard day

Before reading your messages I give you the news:
Yesterday, after tripping, we restarted without TMOS SCADA (disconnected) and the turbine worked without tripping for almost 5 hours and it was just before giving the stop order that it tripped in the same way.
Works on Processor<S>:
On the TCQA board in Loc 2 we found the green DEL "OFF" and on the DCC board all the DELs of the red bar "ON". When the wires of the 2PL plug were shaken, the green DEL on TCQA goes "ON" and the red DELs of DCC are: first from the right and fifth from the right "ON" and the last from the left flashes.
For processors <R> and <T> the red DCC DELs are: first from the right and third from the right "ON" and the last on the left flashes.
We also noticed that the processor <S> initializes itself many times and the LCC display restarts and reaches R7.
We measured the voltages on TCPS of <S> and we found:
N15 ------> -15.01Vdc
P15 ------> +14.92Vdc
P5 ------> +5.13Vdc
N24 ------> -31.40Vdc
P24 ------> +27.68Vdc
We measured the voltages on DCC of <S> and we found:
P5 ------> +5.04Vdc
P15 ------> +14.83Vdc
N15 ------> -15.02Vdc
The processor <S> and the TCEA Y board on <P> have been de-energized via the switches on <PD> TCPD and all the connectors plugs and all the pins and sockets of the ribbon connections of the processor <S> have been cleaned by an electronic boards and connectors cleanin product.
After supplying TCEA, <S> was supplied which, before reaching A7, showed the following messages:
6 DCC errors
IO CFG failed
DCC IO reset
We did not start the turbine today to see the result of this work.
I always try to reduce the volume of the photos (which have about 3 MB) to be able to send them to you as attach files.

Please excuse my delay in answering because I am very busy and my English is weak

 

Thanks for the updates!

We can all appreciate the effort you are making.

In my experience (as I have written) those "error" messages you are seeing during boot-up are "normal" and can be misleading (as they seem to be to you). If all the processors have the same error messages on the LCC display during boot-up then it's just the version of software that has this message and is not a problem.

You said you cleaned the boards, but you didn't say you used conductive grease when the cables were re-connected. That is pretty important. Very early spare cards weren't shipped with conductive grease, but almost every card from about the middle of the product life of the Mark* V was shipped with conductive grease in the box. I don't recall the name of the grease (something with NOX in it if I recall correctly) but heat sink grease (such as is used for computer microprocessors on motherboards--newer motherboards with the microprocessors clamped to the motherboard) would also work if I remember correctly.

You could try uploading the photos to a site that allows sharing (such as photobucket.com) and then post a link to the files and we can download them from there.

I believe White has the correct name of the cable without pull tabs--3PL. And, if you can "shake" the cable and cause a different flashing of LEDs then it's pretty certain that there's something wrong with the cable connectors which have come loose because appropriate care wasn't when unplugging them. If you can get some new 3PL cables I highly recommend you do so! Once these cable connectors go bad they are difficult if not impossible to make good and reliable again. It was really unconscionable of GE not to buy cables with pull tabs, but it's way too late now.

The flashing and colors of the LED bars has never been documented--that I know of--to know what each one or each sequence means. It only means something to the card designers/programmers, and the flashing sequence can and does change whenever upgrading to newer PROM revisions (which probably doesn't happen much these days, but it was pretty maddening when that happened and we couldn't explain or document why it changed...!). What's important is: ALL of the cards in each control processor (<R>, <S> & <T>) should all flash at the same rate AND in the same sequence when everything is happy and healthy and there are NO Diagnostic Alarms. So, all the DCC LED bars should be the same and flash at the same rate in <R, <S> & <T>--if there are no Diagnostic Alarms--as an example, the first, third and fifth LED segments should all flash at the same rate on the same cards in all three control processors. All the TCQA LED bars should flash at the same rate and in the same sequence. All the TCEA LED bars; all the TCDA LED bars. In my experience, if there is even one Diagnostic Alarm in one processor one of the LED bars will flash a difference sequence, but at the same rate. Flashing at the same rate means the control processors are all synchronized, and they SHOULD BE synchronized! That's one of the most important things about the Mark* V, -VI & VIe--that the control processors are all synchronized so that reading inputs and sharing inputs (for voting) and writing to outputs are synchronized and happen at the same times during execution of the CSP or application code.

Some LED bars did have different colors, but I think that changed with newer revisions of the Mark* V, but, again, rate and sequence--and color, if applicable--should all the same in all control processors if there are no Diagnostic Alarms. And it would really be helpful to see those Diagnostic Alarms. But, I'm going to stop asking about them; I know you're busy but we might be able to spot something which may be very helpful (IF the alarm test isn't in French--it seems that some of the Process Alarm messages were translated with software and someone might not have checked to see if they were good translations or not....

Hope things get better!

Do you know how to use the VIEW tools? They are command-line executables that generate ASCII text files. I think there's one that can be configured to trigger on an event (a change of state of a logic point, such as L4) and have some pre- and post data for a few points. I could make some recommendations--but, it has to run in the foreground on an <I> so if you have only one <I> that makes it difficult to use, unfortunately. AND, I don't recall if that version of IDOS had the triggered VIEW executable.... Anyway, if you do we might be able to get some information--though I think you're on to something with cleaning the connectors (applying conductive grease) and making sure all of the ribbon cable connectors (on the 3PL cable) are good and tight. There are some third-party vendors that sell Mark* V parts, including cables; you might try contacting one or more of them to see what they have available. (I say that a little hesitantly because I hear at least one vendor is being very aggressive with emails and phone calls after initial contact trying to sell parts and upgrades and services and HMIs.) One of them used to be an advertiser on Control.com and they had a pretty good stock of Mark* V parts they've acquired over a couple of decades.

 

thanks WTF? and White for your patience and help.
Finally I will send to you the alarms photos.
I also inform you that the turbine worked yesterday without tripping, which means that the cleaning of the connectors gave results. It remains to be confirmed during the following starts.
Regarding the <T> voting problem, I'm thinking of cleaning up the connectors (especially 3PL).
In the following message you will find all the answers of your previous questions.
Best regards

 

1- We only have QD1 and no QD2.
We only have <C> and not <D>.
2- We have TCPD in <PD> with switches.
3- The tripping issue began after replacing the TCPS card of <S> due to a 125 Vdc ground fault. The <T> voting issue is older, and I am not aware of the circumstances under which it occurred.
We have isolated all the devices powered by 125Vdc and the battery earth persists, it is only when we disconnected TCPS that the 125Vdc voltage becomes normal. When we changed TCPS, the 125Vdc battery ground message disappeared.
4- Regarding the "LOSS OF CPD BIAS" alarm, I believe it is a consequence of the trip and not the cause, as it appeared even after normal shutdowns (same situation for the other turbines).
5- MK5 configuration files and turbine's CSP. do you want me to send them too?
6- The turbine trips on heavy fiol oil. The fiol oil is preheated.
7- The turbine trips half an hour to five hours after changing to heavy fiol.
8- I am certain that there is no fiol pressure loss in the machine before tripping. There are no clogged filters or strainers in the machine's fiol supply. The fiol circuit is normal (no issues).
9- We haven't changed the DCC on <T>. <T> still displays A7 even though it has a strange voting behavior.
10- The machine has a clutch (electric) between the ACC. Gear and the high pressure liquid fiol pump (20CF-1).
11- The compartment containing the MKV is kept clean at a temperature between 23 and 25 °C. The doors are always closed.
12- We don't have electric grease GE, but we use sprays designed for electronic cards and connections, with the following features:

• Evaporates quickly.
• Effectively removes stains.
• Wide range of applications.
• Environmentally safe.

13- The issue began, or more precisely was noticed, on 07/08/23, as it has been almost one year since the last turbine start. These turbines are installed to support the grid in case of power problems (following a trip of a large thermal power plant, for instance).
14- I would like to inform you that if the fiol supply pressure drops, an alarm will be triggered, and the turbine will switch to distilate first (and not to trip), which is not the case in our situation.
15- We don't have spare cables. I'm wondering how to order them (reference number, part number...).
16- Yes, I know how to use the view1 and view2 tools, and I believe we have the view executable triggered. We have a local <I> in the TCC and another remote <I> connected to multiple turbines.
I hope I answered all your questions clearly.
THANKS

 

Are you certain the DCC/LCC in <T> in fact has its VOTER ID set to <T> and not something else? It is possible to replace a DCC and not properly set the VOTER ID. The core might go to A7 as that is the I/O status, not the VOTER ID. You can set the voter id with the LCC pinpad. I've seen a site replace a DCC and not set the voter id properly, the panel had two <R> cores and a <T> core. Everything went to A7 but the vote was trash. The second <R> core went to A7 because its <P> and <QDn> core came up properly but the vote was off as there was no <S>, just a <T> and two <R>'s. The <C> core only requires one <Q> core to reach A7, before it will reach A7 itself. As such, the <C> will communicate with an <I> or <HMI> when the panel has a bad voter ID configured.

Each core needs to have its VOTER ID set properly, and only the <C> and <D> (which you do not have a <D>) need to have its Stagelink ID set. <Q> cores have no Stagelink ID and the LCC will tell you that if you try to interrogate it.

 

Very good point, @White. The procedure for setting a processor's Voter ID is in the Mark* V Maintenance Manual, GEH-5980.

 

The conductive grease, NyoGel 760G, or an equivalent, protects against oxidation and corrosion--an electrical cleaner will remove the film but it won't protect against subsequent oxidation or corrosion. It is strongly suggested the site obtain a suitable protectant and apply it properly at the first opportunity on ALL machines. Too much grease is worse than no grease; it attracts dust and makes a mess.

One uses the LCC display and keypad to check and or set/change the Voter ID.

By the way, when replacing the DCC (or SDCC) if you remove the U9 chip from the card being replaced and use it to replace the U9 chip on the DCC (or SDCC) card to be installed in the processor you don't have to change the Voter ID or do any downloads to the processor--because all of that information is already stored on the U9 chip of the card being replaced. (The ONLY time I ever encountered a bad U9 chip was in a lab setting that was being downloaded to 20+ times per day; never in the field. AND downloading DOES NOT set or change the Voter ID. The Voter ID should be visible on the LCC (or SLCC) display; if no Voter ID has been set the LCC (or SLCC) display will usually display <Q>, or the Voter of the processor the card was previously installed in.)

 

I checked the voter ID on each processor's LCC display and found:

1. For <C> : Voter ID (C) --
2. For <R> : Voter ID (R) --
3. For <S> : Voter ID (S) --
4. For <T> : Voter ID (T) --

I will prepare a list of the signals of <T> for which the vote is different from that of <R> and <S> when the turbine is stopped and when it is running.