GE Mark VI S Controller Failure

M

Thread Starter

matrix2016

Please i need your Support

The system is MARK VI. The situation before Startup is good no alarms and Healthy.

After Startup turbine and Few days we receive Controller S is offline ; IONET-2 communication Failure; Controller Sequencing Overrun.
the alarms in:

VCMI : Codes 57 and 67
VPRO : Codes 99;108;110.

and in UVCE all is 106 except controller S is 0.

so after the turbine stop and reboot the controller S we be in control mode and stabilized. so please what is the problem and what i will do?

Is the Problem is the version of toolbox or the Resistor 50 Ohm?

thanks
 
Have you looked-up the Diagnostic Alarm codes in the Mark VI System Guide, GEH-6421? What do they mean? What have you done to try to understand and resolve the problem?

I don't have access to GEH-6421at this writing, but that's the proper way to troubleshoot and resolve the issue.

Please write back to let us know what you find out the Diagnostic Alarms are indicating, and what actions the Diagnostic Alarm descriptions in GEH-6421 tell you to take. Then, we can provide more information and guidance.
 
M
Dear CSA.
Thanks for your reply

in the the MarkVI System Guide, GEH-6421 we have:

VCMI code 57: Controller Sequencing Overrun so the posibile cause is: Too much application code used in cotroller. Reduce the code size.

Code 67: Controller Board is offline, the VCMI cannot communicate with controller.


on VPRO:

Code 99: TREG/TREL/TRES Solenoid Voltage # Mismatch Requested State.
The state of the trip solenoid # does not match the command logic of the voted ETR# on TREG/TREL/TRES, and the voted primary trip relay (PTR) # on TRPG/TRPL/TRPS, the ETR cannot be reliably driven until corrected.

Possible Cause
The trip solenoid # voltage monitor on TREG/TREL/TRES has failed or ETR # driver failed, or PTR # driver failed. There may be a loss of 125 V dc through the J2 connector from TRPG/TRPL/TRPS, which has a separate diagnostic. Refer to fault 105-107.

Code 108: Control Watchdog Trip Protection
This alarm can only occur if Configuration -> ContWdogEn has been enabled.

An alarm indicates that the signal space point -> ContWdog has not changed for 5 consecutive frames. The alarm will reset itself if changes are seen for 60 seconds.

Possible Cause
The trip solenoid # voltage monitor on TREG/TREL/TRES has failed or ETR # driver failed, or PTR # driver failed. There may be a loss of 125 V dc through the J2 connector from TRPG/TRPL/TRPS, which has a separate diagnostic. Refer to fault 105-107.

108: Control Watchdog Trip Protection
This alarm can only occur if Configuration -> ContWdogEn has been enabled.
An alarm indicates that the signal space point -> ContWdog has not changed for 5 consecutive frames.
The alarm will reset itself if changes are seen for 60 seconds.

Verify that the ContWdog is set up correctly in the toolbox and that the source of the signal is changing the value at least once a frame. Check Ethernet cable and connections.

110: Stale speed trip protection.
This alarm can only occur if Configuration -> StaleSpdEn has been enabled. An alarm indicates that the signal Internal Points -> Speed1 has not changed for 5 consecutive frames. The alarm will reset itself if the speed dithers for 60 seconds.

Verify that the Speed1 signal is set up correctly in the toolbox and that the source of the signal reflects the VTUR pulse rate speed input.
Check Ethernet cable and connections.
 


greetings all

we faced the almost the same problem Alarm on VPRO Z and VCMI T. we replaced both card and TB for TERG but still the problem not solved your support is needed:

> 108: Control Watchdog Trip Protection
>This alarm can only occur if Configuration -> ContWdogEn has
>been enabled.
>An alarm indicates that the signal space point -> ContWdog
>has not changed for 5 consecutive frames.
>The alarm will reset itself if changes are seen for 60
>seconds.
>
>Verify that the ContWdog is set up correctly in the toolbox
>and that the source of the signal is changing the value at
>least once a frame. Check Ethernet cable and connections.
>
>110: Stale speed trip protection.
>This alarm can only occur if Configuration -> StaleSpdEn has
>been enabled. An alarm indicates that the signal Internal
>Points -> Speed1 has not changed for 5 consecutive frames.
>The alarm will reset itself if the speed dithers for 60
>seconds.
>
>Verify that the Speed1 signal is set up correctly in the
>toolbox and that the source of the signal reflects the VTUR
>pulse rate speed input.
>Check Ethernet cable and connections.

101 TREG/TREL/TRES Solenoid Voltage # Mismatch
Requested State. The state of the trip solenoid #
does not match the command logic of the voted ETR
# on TREG/TREL/TRES, and the voted primary trip
relay (PTR) # on TRPG/TRPL/TRPS, the ETR cannot
be reliably driven until corrected.

The trip solenoid # voltage monitor on
TREG/TREL/TRES has failed or ETR #
driver failed, or PTR # driver failed. There may be
a loss of 125 V dc through the J2 connector from
TRPG/TRPL/TRPS, which has a separate diagnostic.
Refer to fault 105-107.
 
matrix2016 & alaqeel,

Neither of you has told what troubleshooting was done and what the results of the troubleshooting were.

It would seem the problem lies with the <S> IONET; it could be the termination resistors, or, as is common, just simply corrosion oc thew BNC connectors (sometimes difficult to see, but a think film can greatly degrade data transfer).

If you're certain the 10Base2 IONET cables and BNC connectors and termination resistors are all good and clean and free of corrosion, the next thing would be to try troubleshooting the TREG/TRES/TRLY part of the link--making sure all of the interconnecting cables are all good. The Emergency Stop P/B/ (Pushbutton) circuit also affects the ability of the ETRs and PTRs to be picked up, so make sure that circuit is continuous and has low resistance.

You might try swapping the VPRO from <S> with the one from <R> or <T>, and see if the problem follows the VPRO card. If it does, replace the VPRO card.

Troubleshooting and resolution of problems like this is often a process of elimination. If you can't decide which is the most likely possible problem, just start with one path and work through it to the end of that path--if the problem isn't resolved, move to the next possible path and do the same, working through to the end. Be sure to write down all the steps you take and the results--if you have to have someone come to site to help with resolving the problem this will be very useful information. It's NO help to tell someone trying to help resolve a problem--be it via a World Wide Web forum or on site or by phone--that you checked this or that or everything and not be able to say what was checked, how it was checked or what the results of the efforts were. You will likely be a little disappointed if someone tells you to try this or that, or seemingly repeats what you've already done, and if they do it will likely be because they weren't told what was, how it was done and what the results were.

There are several possible paths outlined in the troubleshooting tips in the Mark VI System Guide. Again, just work through each path logically and methodically, documenting what was done, how it was done and what the results were, and you will likely arrive at the resolution on your own. If not, you will have some good actionable data to provide others you are asking to help resolve the problem.

Please write back to let us know how you fare in resolving the problem! A LOT people read these threads to learn how problems were resolved--both now and in the future, and your feedback may be very helpful to someone.
 
W

waheedullahkhan

Kindly tell me in detail how to configure the compact Flash Drive of Mark Vie controller and which file is required to download in flash Drive after we do formatting it.
 
Good day

For us we have the problem with rack T. Unfortunately, we replaced VCMI, VPRO and TB TREG cards but still we are facing these alarms.
We noticed power supply which feed our system 124VDC is it acceptable?

We loose the data few minutes for only the devices connected to TREG solenoid 3.

Still all VCMI have dignostic alarm (47&51) it can be rest(0) but almost after 2 hrs it come back again by the same alarms.
For VPRO only we received alarm on Z ( 202, 110, 10 &108) also we can rest (0) it but with in two hours alarms come back again by the same alarms .

Your feedback highly appreciated

Thanks
 
laqeel,

So, you DIDN'T mention if you've checked the IONET BNC connectors for evidence of corrosion. Sometimes all it takes is a cotton swab wetted with some electrical contact cleaner used to "swish" around the connectors to get rid of corrosion (which may only appear as a slightly darker discoloration in the connectors--of the cable AND the card edge connectors). If nothing else, it's worth a try--and it eliminates this as a possible cause.

You mention the "low" DC supply voltage. You mention it's only 124 VDC, but you didn't mention if it was previously the nominal 135 VDC (if you can tell us the number of batteries/cells in the string and whether they are the typical lead acid cells or something else, that would be helpful). And, if the supply voltage has dropped for some reason, have you discovered the reason?

Lead acid cells have a "feature" that when the contaminants in the bottom of the cell accumulate and begin to short out the plates in the cell they actually cause that cell to reverse polarity.... Yes, reverse polarity. AND, when ever there is any current draw of any magnitude the reverse polarity will cause the total battery voltage to drop during the current draw.

If you have the typical 57- of 58-cell lead acid battery arrangement (I think that's what it usually is), the battery charger should maintain the voltage slightly above the nominal battery voltage--but not higher than approximately 140 VDC (which the Mark V and Mark VI power supplies DO NOT like). Often the battery charger equalizer voltage is set to something slightly higher than 140 VDC and that can cause Mark V and Mark VI power supplies to fail--if the Mark* is not powered down when the battery charger is put on equalize mode.

You can find a shorted battery/cell in a series string of batteries with a voltmeter. Put the voltmeter on the appropriate DC voltage range and touch the positive lead to the positive terminal of each battery in the string and the negative lead to the negative terminal of each battery in the string and if there is a shorted cell the voltage you read will show a negative polarity, and usually something less than the nominal voltages of the other unshorted batteries/cells.

You can just jumper out the shorted battery/cell temporarily to see if that restores the battery voltage to near normal.

However, the battery charger, if working and adjusted correctly will usually keep the total battery voltage somewhere near nominal, so the problem could be the battery charger, also, or, as is sometimes the case, it could be some combination of bad battery/cell and a failed or failing charger. If the charger is failing, it's usually the output capacitors which fail, and this results in an AC voltage being super-imposed on top of the DC--which isn't really good for any of the electronics in the Mark* turbine control panel.

You also haven't mentioned if the 125 VDC battery is experiencing any kind of ground--either "soft" or "hard." A soft batter ground is a ground which results in the 125 VDC battery voltage split being anything other than a 50%/50% split of battery voltage (such as +90 VDC and -40 VDC) with respect to ground. Usually only a voltage split where one of the DC supply legs is less than approximately 30 VDC with respect to ground. A hard 125 VDC battery ground is when one leg or the other is nearly 0 VDC with respect to ground. Soft grounds are usually caused by moisture in some junction box (usually an external/exterior junction box or device, such an exhaust frame cooling fan pressure switch or an inlet filter house differential pressure switch). A soft ground, left unattended over time, can become a very hard ground--which is NOT good, especially if there are multiple soft grounds....

If you've tried replacing printed circuit cards, and still have the issue(s), then it's time to try looking at eliminating all the other possibilities, as recommended previously. It could be that something that hasn't been found is causing failures of good cards after they have been replaced--which is one reason why I'm ALWAYS reluctant to just start replacing cards when there's a problem, it can result in more failed cards if everything else hasn't been eliminated. (Sometimes, replacing cards is the only thing that resolves problems. But as spare cards are expensive, and sometimes more than one can be damaged if the true root cause of the problem isn't found and eliminated before replacing a failed card causes more failed cards, it's always best (in my personal opinion--many others feel VERY differently) to eliminate all other possible causes to the best extent possible before replacing cards as a troubleshooting method).

Are there other Diagnostic Alarms on the Mark VI which you haven't told us about? If so, what are they?

That's about all I can think of. Please write back with more information, and tell us how you fare in resolving the problem! A LOT of people read these threads, now and in the future, and the information and troubleshooting methods you share could help at least one person/site now or in the future. And even if it's just one person (and it could have been you had we been able to solve this problem before you posted!) is better than none!
 
HUNTER_DZ,

Помогите нам помочь вам, сообщив, с какой проблемой вы столкнулись, какие аварийные сигналы (Process- и Diagnostic Alarms) активны при возникновении проблемы, что вы сделали для устранения проблемы и каковы были результаты устранения проблемы (кроме того, что проблема по-прежнему существует).

Добавлю также, что использование программы-транслятора для поиска и устранения технических проблем может быть очень сложным.

Наконец, часто при замене платы VCMI происходит "процесс", называемый "загрузкой топологии" в затронутый процессор. Делали ли вы это? (Вот почему важно знать, что вы делали - и каковы были результаты). Также полезно знать, когда возникла проблема и происходило ли в момент ее возникновения что-то еще (загрузка, перезагрузка, отключение нагрузки и т.д.).

Лучший способ получить помощь - предоставить как можно больше информации (вы не предоставили НИКАКОЙ информации - только просьбу о помощи, и мы не знаем, связана ли ваша просьба с исходным сообщением, на которое вы ответили. (Это еще один хороший совет: всегда лучше открывать новую тему (с верхней страницы любого сайта Control.com), даже если она кажется точно такой же, как и другая (потому что редко бывает, что две ситуации/проблемы абсолютно одинаковы).

(I used a licensed copy of DeepL translation program. As such, I am not responsible for any errors which might be in the Russian translation of the English response I typed into the translation program.)
 
Have someone come to site who knows WTF they are doing.

Full stop. Period.

End of discussion.

It's practically IMPOSSIBLE to download viruses to the Mark* VI. Only binary files (m6B--the B stands for binary) are downloaded (or uploaded). These files cannot contain viruses.

Full stop. Period.

End of discussion.

Have someone come to site who knows WTF they are doing.

You can't answer questions. You have some agenda ("viruses"). You don't know WTF you are doing.
 
Dear WTF!
Initially the problem was that the controller (S) did not synchronize with the other two. Afterwards I completely rebooted markVI. first turned off (R), then (S), then (T). Next, I de-energized the VPRO. I left MARKVI without power for an hour. Then I turned on VPRO, then (R), (S), (T). After this the following errors appeared.
 
Top