Unit Tripped by R and S offline processor alarm .

Hi for all;

We have a gas turbine GE frame 9FA Mark6 control system. sometimes unit tripping by R and S offline processor alarm. we chearched so many times to
idintify why this alarm trigger and trip the machine but unfortunatly we not able to figgure out the problem. we suspected
fail or malfunction in VCMI cards we replaced bothe VCMI cards and also control cards UCVG for both racks and run unit again after somtimes it repeated and unit tripped again. in SOE an alarm CPU SWITCHED SUSSPEND and Mark VI DALMLOG Report "IONET-2 Communications Failure" and Mark VI DALMLOG Report "IONET-3 Communications Failure" and before this both alarms one alarm Mark VI DALMLOG Report <Card reboot occurred here.>. we suspected again over voltage comming from DACA1,DACA2 and 125VDC battery Charger we measured volt and foun as follow 240,250 and 125 and found in range.again we do extra job take both cards VCMI and UCVG cards for three racks R,S and T and clean racks by blower and clean also IONET-1,2,3 socket and cables and start unit. it is run for some days and again tripped by same alarm. friends can any one face same issue and figure out the problem .
Thanks and best Regards
 
The stainless steel braided coaxial cables used to interconnect the VCMI cards and the VPRO cards are the IONET cables. If there are problems with the cables or the BNC connected on the cables (including the BNC termination resistors) or the BNC connectors on the cards (VCMI and/or VPRO) these kinds of issues will occur. Often when they do you will find one or more of the red COLlision LEDs on the cards are lit indicating a problem with IONET communications.

I believe there was a GE TIL (Technical Information Letter) issued some years ago about component issues with some VCMI cards. A reputable Mark VI card supplier should be able to help with the TIL or repairing the issue.

I have also seen the BNC termination resistors and BNC tee and elbow connectors just fail—usually because of corrosion due to poor housekeeping and improper humidity and temperature control in the compartment where the Mark VI is housed. If it hot, humid and dusty outside the compartment where the Mark* is housed AND the air conditioner thermostat is set very cold humidity WILL make its way into the Mark* panel and condense on places it shouldn’t be. Add dust poor housekeeping practices to the problem and it can be difficult to find all the adversely affected areas.

Best of luck with the problem! It can be frustrating to solve. Get GOOD quality BNC components from RS or another quality supplier—for Ethernet 10Base2 systems, not just generic BNC connectors!!! And work with a reputable Mark* card supplier to obtain good VCMI and possibly VPRO cards.

it will take time, but you will eventually resolve the problem if you are methodical and patient and … stubborn. Best of luck!!!
 
msalem73,

(I mistakenly posted this in another thread; sorry.)

To START a turbine with a TMR (Triple Modular Redundant) Mark VI it is necessary for ALL processors--and the protective processors (the three VPROS in <P>: <X>, <Y> & <Z>) to all be healthy and communicating via the IONET (the braided steel-sheathed coaxial 10-Base2 cables connecting the three VCMIs and the three protective processors).

The VPROs control the ETR (Emergency Trip Relays) on the TREG card, and the three UCVx cards control the PTR (Primary Trip Relays) on the TRPG card. BOTH sets of relays (the PTRs for the particular fuel/stop valve solenoid being used, and the ETRs) have to be energized and working (at least two out of three of each set of relays during normal operation, but certainly all relays during the initial START sequence) in order go get 125 VDC to the trip/fuel stop valve solenoid (20FG-1 in your case). The -65 VDC (presuming no 125 VDC battery ground exists) comes through the PTRs on the TRPG, and the _65 VDC comes through the ETRs on the TREG. Together, they combine to provide 125 VDC and the necessary current to operate the solenoid so that the fuel stop valve can be opened (the SRV in your case, via 20FG-1).

Based on the information provided, I can't say any more. On each of the three VCMI cards (in close proximity to the BNC connectors on the card) are LEDs which can be useful (some times) for diagnosing problems similar to the one you are trying to describe. TX stands for Transmitting; RX stands for Receiving; COL stands for Collision detection--which can occur when there are IONET problems--either cables or BNC connectors or BNC termination resistors, or even problems with the VPRO card(s), to which the IONET cables must also be connected for proper communication and operation.

The LEDS might be indicative of a problem, and they might not be.

There have been reports of rack issues; you said you removed some cards and cleaned the backplane and that's good.

Older RKPS power supplies (the honking giant power supplies on the right side of the processor racks) have also been known to have components which don't last as long as expected; I believe GE had a TIL out about that (or maybe more than one TIL--I can't recall). But, intermittent power supply issues could also be contributing to the problem.

DON'T overlook Diagnostic Alarms!!! The next time this occurs, use Toolbox to check the Diagnostic Alarms on the VPROs and the VCMIs and the UCVx cards. (If there is no or poor comm's between cards, not all Diag. Alarms may be visible.)

I have spent a good deal of time troubleshooting Mark VI IONET problems--and it's not fun and it's frustrating. They are usually intermittent, and it's usually something simple. For example, on at least two sites the BNC connector for one of the IONET ports on one of the VCMI cards was causing an intermittent problem--turns out the solder joints holding the BNC connector on the VCMI card were damaged and loose and making intermittent connection. On another card, it was a chip in the IONET circuit which was failing intermittently. (That one was traced by exchanging it with another VCMI and observing the problem followed the card to its new processor rack.)

WRITE DOWN the troubleshooting steps you perform. MORE IMPORTANTLY--write down the results of what you did. If you end up getting someone to site to help with the problem you will likely have tried so many things that you can't remember what you did or what the results were or how you did it--and you will be paying for someone else to repeat what you (think) was already done (tried). (If I had a nickel for every time I've heard, "We tried that!!" I would be a very wealthy man, but when I ask what the results were or how it was done no one can remember. So, do yourself a favour right now--and start writing down everything you've done and what the results were. ("It didn't work," doesn't count as a result. Something did happen or didn't happen--either something you expected to happen, or didn't expect to happen. That's a result.)

Be methodical. If you have questions--we can try to answer them here. (Some answers are better than others; YMMV. (Your Mileage May Vary)).

Finally, realize you may be fighting more than one problem. For example, a loose solder joint and a poor connection (corrosion). Or, a failing/failed BNC connector and an intermittent RKPS power supply. And a loose solder joint. (Unplugging cables and plugging them back in can damage already weakened solder joints. Failure to insert a card in a slot properly can cause damage to pins and receptacles.) Care should be taken with every operation. BNC connectors and BNC termination resistors are inexpensive; buy lots and replace them all.

Be safe, and stay healthy!!!

And please write back to let us know how you progress. If you need more help, we are going to need Diagnostic Alarm information (either screen captures or CLEAR photographs--both can be attached to posts here on Control.com).
 
Hi for all;

We have a gas turbine GE frame 9FA Mark6 control system. sometimes unit tripping by R and S offline processor alarm. we chearched so many times to
idintify why this alarm trigger and trip the machine but unfortunatly we not able to figgure out the problem. we suspected
fail or malfunction in VCMI cards we replaced bothe VCMI cards and also control cards UCVG for both racks and run unit again after somtimes it repeated and unit tripped again. in SOE an alarm CPU SWITCHED SUSSPEND and Mark VI DALMLOG Report "IONET-2 Communications Failure" and Mark VI DALMLOG Report "IONET-3 Communications Failure" and before this both alarms one alarm Mark VI DALMLOG Report <Card reboot occurred here.>. we suspected again over voltage comming from DACA1,DACA2 and 125VDC battery Charger we measured volt and foun as follow 240,250 and 125 and found in range.again we do extra job take both cards VCMI and UCVG cards for three racks R,S and T and clean racks by blower and clean also IONET-1,2,3 socket and cables and start unit. it is run for some days and again tripped by same alarm. friends can any one face same issue and figure out the problem .
Thanks and best Regards
Hi

Looks like these faults /alarms are from VCMI diagnostic ...
I dont see a track on CPU SWITCHED SUSPEND...cAN YOU TELL US MORE ABOUT THIS CODE ...
 
ControlsGuy25,

The topic of CPU SWITCH has been covered before on Control.com. It’s not well-documented by GE (SURPRISED? You should not be…).

I think basically it means the designated processor has changed, for whatever reason (in this case, probably because of the hiccup in comm’s between processors).
 
ControlsGuy25,

The topic of CPU SWITCH has been covered before on Control.com. It’s not well-documented by GE (SURPRISED? You should not be…).

I think basically it means the designated processor has changed, for whatever reason (in this case, probably because of the hiccup in comm’s between processors).
CSA,

Well I am not surprised about the point that you highlighted ..

It is sometime the case.... Sometimes documents are very good and we should also highlight it..

Just wanted a clarification about that alarm/fault code designation from @msalem73

Cheers,
Controls Guy25.
 
Hi for all;

We have a gas turbine GE frame 9FA Mark6 control system. sometimes unit tripping by R and S offline processor alarm. we chearched so many times to
idintify why this alarm trigger and trip the machine but unfortunatly we not able to figgure out the problem. we suspected
fail or malfunction in VCMI cards we replaced bothe VCMI cards and also control cards UCVG for both racks and run unit again after somtimes it repeated and unit tripped again. in SOE an alarm CPU SWITCHED SUSSPEND and Mark VI DALMLOG Report "IONET-2 Communications Failure" and Mark VI DALMLOG Report "IONET-3 Communications Failure" and before this both alarms one alarm Mark VI DALMLOG Report <Card reboot occurred here.>. we suspected again over voltage comming from DACA1,DACA2 and 125VDC battery Charger we measured volt and foun as follow 240,250 and 125 and found in range.again we do extra job take both cards VCMI and UCVG cards for three racks R,S and T and clean racks by blower and clean also IONET-1,2,3 socket and cables and start unit. it is run for some days and again tripped by same alarm. friends can any one face same issue and figure out the problem .
Thanks and best Regards
It Looks like original written by original poster is not 100% entire.. One should read "xmit suspended CPU switched"..

Please be more specific..

Cheers
James
 
Dear CSA;

Thanks for your advice and your fast prompet and sorry for late in reply. for your information GE proposed brfore for our plant
to apply TIL no.1905 which telling each IONET ports on VCMI cards has chip socket type this socket somtime dust and make bad contact and make a failure in communication in IONET and after upgread VCMI card they change socket type to welding type for all VCMI card port .Our plant allready applied this TIL in 2019 and .for your information also same offline alarm processor happened today and tripped another unit also pleae find the attached all sequene of events and diagnostic alarm for VCMI and CPU
Best regards
 

Attachments

Dear CSA;

Thanks for your advice and your fast prompet and sorry for late in reply. for your information GE proposed brfore for our plant
to apply TIL no.1905 which telling each IONET ports on VCMI cards has chip socket type this socket somtime dust and make bad contact and make a failure in communication in IONET and after upgread VCMI card they change socket type to welding type for all VCMI card port .Our plant allready applied this TIL in 2019 and .for your information also same offline alarm processor happened today and tripped another unit also pleae find the attached all sequene of events and diagnostic alarm for VCMI and CPU
Best regards
Best for all.. With this issue...

We asking questions you deniying to reply so Hasta la Vista...

Cheers
 
It Looks like original written by original poster is not 100% entire.. One should read "xmit suspended CPU switched"..

Please be more specific..

Cheers
James
msalem73,

(I mistakenly posted this in another thread; sorry.)

To START a turbine with a TMR (Triple Modular Redundant) Mark VI it is necessary for ALL processors--and the protective processors (the three VPROS in <P>: <X>, <Y> & <Z>) to all be healthy and communicating via the IONET (the braided steel-sheathed coaxial 10-Base2 cables connecting the three VCMIs and the three protective processors).

The VPROs control the ETR (Emergency Trip Relays) on the TREG card, and the three UCVx cards control the PTR (Primary Trip Relays) on the TRPG card. BOTH sets of relays (the PTRs for the particular fuel/stop valve solenoid being used, and the ETRs) have to be energized and working (at least two out of three of each set of relays during normal operation, but certainly all relays during the initial START sequence) in order go get 125 VDC to the trip/fuel stop valve solenoid (20FG-1 in your case). The -65 VDC (presuming no 125 VDC battery ground exists) comes through the PTRs on the TRPG, and the _65 VDC comes through the ETRs on the TREG. Together, they combine to provide 125 VDC and the necessary current to operate the solenoid so that the fuel stop valve can be opened (the SRV in your case, via 20FG-1).

Based on the information provided, I can't say any more. On each of the three VCMI cards (in close proximity to the BNC connectors on the card) are LEDs which can be useful (some times) for diagnosing problems similar to the one you are trying to describe. TX stands for Transmitting; RX stands for Receiving; COL stands for Collision detection--which can occur when there are IONET problems--either cables or BNC connectors or BNC termination resistors, or even problems with the VPRO card(s), to which the IONET cables must also be connected for proper communication and operation.

The LEDS might be indicative of a problem, and they might not be.

There have been reports of rack issues; you said you removed some cards and cleaned the backplane and that's good.

Older RKPS power supplies (the honking giant power supplies on the right side of the processor racks) have also been known to have components which don't last as long as expected; I believe GE had a TIL out about that (or maybe more than one TIL--I can't recall). But, intermittent power supply issues could also be contributing to the problem.

DON'T overlook Diagnostic Alarms!!! The next time this occurs, use Toolbox to check the Diagnostic Alarms on the VPROs and the VCMIs and the UCVx cards. (If there is no or poor comm's between cards, not all Diag. Alarms may be visible.)

I have spent a good deal of time troubleshooting Mark VI IONET problems--and it's not fun and it's frustrating. They are usually intermittent, and it's usually something simple. For example, on at least two sites the BNC connector for one of the IONET ports on one of the VCMI cards was causing an intermittent problem--turns out the solder joints holding the BNC connector on the VCMI card were damaged and loose and making intermittent connection. On another card, it was a chip in the IONET circuit which was failing intermittently. (That one was traced by exchanging it with another VCMI and observing the problem followed the card to its new processor rack.)

WRITE DOWN the troubleshooting steps you perform. MORE IMPORTANTLY--write down the results of what you did. If you end up getting someone to site to help with the problem you will likely have tried so many things that you can't remember what you did or what the results were or how you did it--and you will be paying for someone else to repeat what you (think) was already done (tried). (If I had a nickel for every time I've heard, "We tried that!!" I would be a very wealthy man, but when I ask what the results were or how it was done no one can remember. So, do yourself a favour right now--and start writing down everything you've done and what the results were. ("It didn't work," doesn't count as a result. Something did happen or didn't happen--either something you expected to happen, or didn't expect to happen. That's a result.)

Be methodical. If you have questions--we can try to answer them here. (Some answers are better than others; YMMV. (Your Mileage May Vary)).

Finally, realize you may be fighting more than one problem. For example, a loose solder joint and a poor connection (corrosion). Or, a failing/failed BNC connector and an intermittent RKPS power supply. And a loose solder joint. (Unplugging cables and plugging them back in can damage already weakened solder joints. Failure to insert a card in a slot properly can cause damage to pins and receptacles.) Care should be taken with every operation. BNC connectors and BNC termination resistors are inexpensive; buy lots and replace them all.

Be safe, and stay healthy!!!

And please write back to let us know how you progress. If you need more help, we are going to need Diagnostic Alarm information (either screen captures or CLEAR photographs--both can be attached to posts here on Control.com).
Dear CSA;

Thanks for your advice and your fast prompt and sorry for late in reply. for your information GE proposed before for our plant
to apply TIL no.1905 which telling each IONET ports on VCMI cards has chip socket type this socket sometime dust and make bad contact and make a failure in communication in IONET and after upgrade VCMI card they change socket type to welding type for all VCMI card port .Our plant already applied this TIL in 2019 and .for your information also same offline alarm processor happened today and tripped another unit also please find the attached all sequence of events and diagnostic alarm for VCMI and CPU
Best regards
 

Attachments

It Looks like original written by original poster is not 100% entire.. One should read "xmit suspended CPU switched"..

Please be more specific..

Cheers
James
Hello
you are right i received an alarm in alarm list which highlighted in your post " XMIT suspended CPU switched"
you can see in SOE file which i attached to you and all diagnostic alarms. last action i after trip i removed all connectors and cables IONETs for VCMI and VPRO and clean all connectors wit CRC ,reset all the diagnostic alarms and start the unit .

thanks and best regards
 

Attachments

Hi

Can you tell us if you have remarked that :

03-SEP-2021 21:48:08.223 G2 1 Q 2468 ALM EMERGENCY MANUAL TRIP - MKVI PANEL
03-SEP-2021 21:48:08.223 G2 1 Q 2470 ALM VPRO - EMERGENCY STOP PB DEPRESSED
03-SEP-2021 21:48:08.223 G2 0 Q 2477 ALM AIR PROCESSING UNIT LOW PRESSURE
03-SEP-2021 21:48:08.223 G2 1 Q 2497 ALM GAS FUEL PRESSURE LOW
03-SEP-2021 21:48:08.223 G2 1 Q 2536 ALM BATTERY 125VDC GROUND
03-SEP-2021 21:48:08.223 G2 0 Q 2563 ALM CONTROL COMPARTMENT TEMP HIGH
03-SEP-2021 21:48:08.223 G2 1 Q 2588 ALM COMPRESSOR BLEED VALVE POSITION

What means Emergency stop PB depressed...also looks like there is 125VDC ground fault...
 
Is that L5ESTOP1_PB2 the designated PB that i mention on my last post
...
Looks like something not ok with that device ..

Try to investigate on VSVO too as I see some diagnostic alarms on taht one too...

Looks like ETR or PTR is missing here with excitation interlocking trip relay ..
 
Hi

Can you tell us if you have remarked that :

03-SEP-2021 21:48:08.223 G2 1 Q 2468 ALM EMERGENCY MANUAL TRIP - MKVI PANEL
03-SEP-2021 21:48:08.223 G2 1 Q 2470 ALM VPRO - EMERGENCY STOP PB DEPRESSED
03-SEP-2021 21:48:08.223 G2 0 Q 2477 ALM AIR PROCESSING UNIT LOW PRESSURE
03-SEP-2021 21:48:08.223 G2 1 Q 2497 ALM GAS FUEL PRESSURE LOW
03-SEP-2021 21:48:08.223 G2 1 Q 2536 ALM BATTERY 125VDC GROUND
03-SEP-2021 21:48:08.223 G2 0 Q 2563 ALM CONTROL COMPARTMENT TEMP HIGH
03-SEP-2021 21:48:08.223 G2 1 Q 2588 ALM COMPRESSOR BLEED VALVE POSITION

What means Emergency stop PB depressed...also looks like there is 125VDC ground fault...
Hi ControlsGuy25

thank for your reply This alarms follow the tripped due to offline processor but actual no Emergency push button pressed .
during last trip of unit i check battery charger for any positive or negative ground but no alarm existing and confirm from Mark 6 rack R VCMI 125 VDC power monitor positive and negative volt is +62.5 VC and -62.5 VDC. respectively.
what is your advice in next step?
Thanks
 
Hi ControlsGuy25

thank for your reply This alarms follow the tripped due to offline processor but actual no Emergency push button pressed .
during last trip of unit i check battery charger for any positive or negative ground but no alarm existing and confirm from Mark 6 rack R VCMI 125 VDC power monitor positive and negative volt is +62.5 VC and -62.5 VDC. respectively.
what is your advice in next step?
Thanks
Hi Msalem73

I would advise you to try to find a method to know if control signal from VPRO VSVO and VTTUR cards are ok..


Step by step so we may have better overview ...

ControlsGuy25.
 
After looked at GE manual it seems that there is kind of inetrlocking excitation trip relay WHICH MAY BE NOT WORKING properly in your case...

That can be origin of exciation fault trouble that come as an alarm..
 
A 125 VDC ground exists. Once the control system trips the turbine, the offending device is now isolated.

I like to call this a 107 ground refering to a wire number that GE utilized for most turbines.

It is common to most terminal board and it often shared in the most terrible fashion. In the Mark V world it would be located on Bus a, b, c, d and e of one's terminal boards.

The grounds could be isolated by jumper BJ1,2,3,4,5

If this occurs in <P> core a bit more troubleshoot is needed.

I believe the Mark VI copied the IO layout for terminal strips.

Just for info for others: PTR ETR etc are little icecube relays in the protective core.

Although GE diagnostic info would never blame one of the relay boards, I recently had a TCRA board on a Mark V provide me with several hours of troubleshooting.
 
A 125 VDC ground exists. Once the control system trips the turbine, the offending device is now isolated.

I like to call this a 107 ground refering to a wire number that GE utilized for most turbines.

It is common to most terminal board and it often shared in the most terrible fashion. In the Mark V world it would be located on Bus a, b, c, d and e of one's terminal boards.

The grounds could be isolated by jumper BJ1,2,3,4,5

If this occurs in <P> core a bit more troubleshoot is needed.

I believe the Mark VI copied the IO layout for terminal strips.

Just for info for others: PTR ETR etc are little icecube relays in the protective core.

Although GE diagnostic info would never blame one of the relay boards, I recently had a TCRA board on a Mark V provide me with several hours of troubleshooting.
I have very little troubleshooting experience on the MKVI hardware.

The following info is for CSA to think about:

MKV ONLY:

TCPS power supply board on each core has a FU1 located in the upper left corner of of that board.

FU1 supplies power to the 24VDC to the digital core TCDA which interogates that core for valid data from the relay boards TCRA.

I have not researched how that applies to the P core.

However, I have found that grounds can be transmitted from the digital output boards TCRA.

I did not try to find the fault in the TCRA digital output board or any of it's relays. It was time to get that turbine started.

CSA, I have witnessed GE copy problems from the MKI to the MKV and MKVI.

Your experience may be key to this.
 
I can only offer a few things on this thread.

If I understand correctly, this is now happening on a second unit. That suggests something common to both machines. Like the earthing (ground) system....?

Or, I have seen similar issues when multiple units shared a common 125 VDC battery (never a good idea in my personal opinion).

The original poster mentioned <DACA>s. They are notorious for magnifying spikes on the input power to the output 125 VDC! Some sites use inexpensive inverters to provide power to the <DACA>s. If the output of the inverter is not clean then the <DACA>s will magnify spikes and dips and the RKPS power supplies don't like that--at all! They are not filters by any means, and the Mark VI panels should all have <CPF> filters, also. And I have seen issues with components on those filters cause nuisance and intermittent problems.

The RKPS (rack-mounted) power supplies for the processor racks had one or TILs about them, as well. They also have had component issues, mostly some bad components from suppliers.

Also, the VPROs have their own power supplies, and they like clean power, too.

If the site experiences electrical storms (lightning) during the rainy season this can make other electrical/earthing issues worse, and weaken components in filters and power supplies.

If the earthing systemS--possibly two systems for Mark VI (Functional (Instrument) and Protective (Safety)) are not properly isolated then issues with improperly earthed devices (high-voltage/high-current motors) can also cause issues like this.

I'm throwing a lot of ideas--but there's a LOT we don't know about this plant, how it's operated and maintained, where it's located, what the soil conditions are, what provides power to the <DACS>s, how the earthing systemS (there may be more than one!) are constructed and tested and maintained and the type of soil they are buried in--any and all of these things can result in issues like this.

Many 9FA units were installed quickly in some very unique locations in the world, with unusual ambient conditions, often places with high ambient temperatures and high humidity and dust. The grids they are connected to are unstable and poorly regulated, and F-class machines weren't really designed for these kinds of locations and grids. Some of the plants were designed and built by GE--and their Power Plant design and construction division was a mess (big, long, ugly story made worse by nepotism).

Without being on site to observe and witness what is happening and how the plant was designed and built and has been operated and maintained it's impossible to say with any degree of certainty what might be the causesS of the issues being described by the original poster. If it were my plant, I would start by isolating the power to the <DACA>s first--they are not required as long as the 125 VDC batteries and chargers are properly maintained and reliable. I would be checking the input power supplies to the <DACA>s for cleanliness. ALSO, I would be checking the output of the 125 VDC battery chargers for cleanliness.

I would be checking the earthing grids to be sure they are properly maintained and working well. If the site uses Functional and Protective earthing grids I would be checking them for proper isolation from each other.

Again--if this is now happening to a second unit at the site, there's something common and/or shared between the units, or something like that. I don't think it's a Mark VI issue, but rather that the Mark VI's are being affected by conditions. It could even be a cumulative thing--dirty power supplies have finally damaged components.

Finally, general housekeeping and temperature and humidity control are also of high importance and often overlooked. Dust and humidity and heat are the enemy of electronics, and poor housekeeping and temperature and humidity control will eventually and ALWAYS destroy electronics, usually by causing nuisance and intermittent problems at first. And, of course--it's ALWAYS the control system that's at fault, right???!?!?!!!

WRONG.

Hope this helps. I have a bad feeling about this. Poor construction proctices, along with poor maintenances practices and poor earthing issues and ambient conditions--a real recipe for a long slog of troubleshooting and repair and blaming and just a bad situation all around. But the Mark VI needs clean power and to be well maintained, and if it's not it's going to be blamed for a lot of problems which are not it's fault. Stop looking at ND blaming the Mark VI's--and make sure they are clean and cool and dry and properly earthed and have clean power supplies to the<DACA>s and from the battery chargers. Do this methodically and logically. And as part of a routine maintenance plan. And the Mark VI will last another decade or two. Easily.

Best of luck! Write back to let us know how you progress. I am pretty confident it's not the Mark VI that's at fault there. And making sure the Mark VI is clean and dry and cool and properly earthed and cleanly powered will be easier--in the long run--than troubleshooting these issues which are commonly caused by external issues. Believe it or not. Logic says so. And so does experience--and isn't that what you wrote to ask for????
 
oussama el,

I want to add: Normally, when GE (USA) provides a 125 VDC battery and charger for a Mark* turbine control there is no ground (earth) detection card in or earth condition detected by the battery charger. Earth detection is performed by the Mark*. Many times, unfortunately, when a Customer with a Mark* buys a new battery charger they mistakenly buy one with earth detection capability--and if the earth detection in the Mark* is not blocked the earth detection of both systems are adversely affected (the business of resistors in parallel reducing the resistance to less than the lowest resistor value). This can cause erroneous earth indications in BOTH the battery charger AND the Mark*. AND it can make locating Earth's very difficult.

It's also VERY IMPORTANT to understand that the earth detection of the Mark* and the battery charger CANNOT distinguish between Earth's in devices connected to the Mark* and other devices powered by the battery--contrsry to false and extremely popular belief. ANY EARTH ON AMY DEVICE OR CIRCUIT CONNECTED OR POWERED BY THE 125 VDC BATTERY IS REPORTED AS AN EARTH BY THE MARK* OR THE BATTERY CHARGER!!! That's right--an earth in the DC Hydraulic Ratchet Pump motor field circuit will be detected by either system as an earth EVEN THOUGH the DC Hydraulic Ratchet Pump motor field circuit is not connected to the Mark*. Same for an earth in the DC Emergency Compartment Lighting circuits. The Mark* ESPECIALLY cannot separate devices powered directly by the 125 VDC battery that are connected to the Mark* from devices which are also powered by the 125 VDC battery but NOT connected directly to the Mark*--again, contrary to false and popular belief. The Mark* just CANNOT distinguish between devices connected to the Mark* and devices not connected to the Mark*.

So, if the earth detection hardware jumper is IN in the <PD> core AND there is an earth detection card or function operating in the 125 VDC battery charger, the two are working"against" each other and they should not both be active or enabled simultaneously. And if they both are then detecting earths is going to be difficult and time-consuming. But, in reality neither will properly detecting an earth if both are enabled at the same time.

Again, if the same thing is happening to two or more units then it's very probable two (2) Mark VI turbine control panels have NOT failed in a similar manner and at nearly the same time. It's more likely that something similar or shared by the two Mark* turbine control panels is/are failing or failed. That could be ANY NUMBER of things, from earthing systems to temperature/humidity control (or lack thereof), or housekeeping (dust and dirt), to <DACA> power supplies, to dirty 125 VDC battery charger output(s), to failing/failed rack-mounted power supplies, to VPRO power supplies to earths. And, it could also be a combination of any (or all) of the above. Failure to adhere to industry standard earthing protection schemes and regularly testing and properly maintaining earthing systems can also contribute to or be the entire problem. Someone connecting a 440 VAC motor to the Functional earthing system, or connecting a field device to the Protective earth system. Or a shield drain wire to the Protective earth system--all of these could compromise the integrity of the independent earths. A change in the moisture content of the soil the earths are buried in, or a separation of earthing components in a particular system could also contribute to or be the problem.

Look for something similar to both machines or common to both machines as the root cause of the problem; that could ultimately lead to a failure of Mark* components or cards--but simply replacing the failed Mark VI card or component IS NOT resolving the root cause(s) of the problem and will only lead to more failures.

Again, please write back to let us know how the problem resolution is progressing!
 
Top