Today is...
Monday, August 19, 2019
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A tutorial introduction to programming using the QuickBuilder Programming Environment.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Mark 6 - VPRO diagnostic alarm
we experience the following alarm diagostic alarm on VPRO Z: The solenoid voltage 06 mismatch request state.

We have frame 5-C, controlled by Mark 6 simplex.
We experience the following alarm diagostic alarm on VPRO Z:
The solenoid voltage 06 mismatch request state.
After check of the manual, we understand that this means that the trip solenoid number 3 feedback voltage is not matching with the reference status.

Please give the purposed causes and their purposed solutios.

Best regards

Is there anything connected to solenoid number three, like the gas fuel trip solenoid, or the liquid trip solenoid, or the hydraulic trip solenoid?

What does the voted signal display say about the states of the three signals in each of the VPROs?

Thank you for your reply.

Please note that I reviewed today the wiring and I noticed that we have one trip solenoid only connected to TREG in terminal No. 1 of its terminal block. That is gas fuel trip solenoid 20 FG.

And we do not have any thing connected to the third or the second coil.

The 3 voted signals are as follows:
For X: 0
For Y: 0
For Z: 1

Best regards

Could you please reply to me? The question was: what is the cause for this alarm, and how can I solve it?

Regards

AmAm,

You don't seem to realize that the moderator only posts questions and replies approximately once per day, only occasionally more frequently, and sometimes a day or two (or three) go by before posts and replies get updated.

A proper answer required your input. The reply had to be sent to control.com to be reviewed by the moderator and then posted along with all other posts/replies.

If you have an emergency request and need immediate assistance, this is not the forum for you. Prompt and complete responses are much more likely to happen if you provide as much as information as you can (though the posting of them is still subject to the moderators of this forum and their schedule and server availability and even holidays (North American holiday schedule)). This is a free forum, and, its use is subject to several things: posting schedule (up to the moderators), review of topic for suitability, and willingness of others to respond (of course you can post any question, but whether or not you receive an answer is up to those who read and reply, and the posting schedule).

While not enforceable, we, especially in the GE Speedtronic turbine controls community here on control.com, encourage and even rely on feedback from the originators of threads about the usefulness and suitability of responses. When feedback is provided to the thread, then others who use the very powerful 'Search' feature of control.com can see if their question has already been asked and answered and whether or not the information provided was helpful or not. So, please let us know if you were able to solve your problem with the information provided. If you can take the time to write a question (and demand a response) then you can take the time to write a response with some feedback when you have resolved your problem.

It would seem to be odd that the alarm is being annunciated for an output that isn't being used, until one realizes that all of the Emergency Trip Relays are energized when the turbine is to be running.

I believe the method for sensing a problem is that a set of contacts on each of the relays is used to check to see if the relay is energized or de-energized. Or, from GEH-6421, Vol. II, VRPO | TREG | Figure 'TREG Trip Interlocks and Solenoids', it would seem that possible the KZ3 relay might not be operating. You might try (with the unit not running), swapping KZ3 with KZ2 (I think the relay numbers are silkscreened on the TREG) to see if the problem follows the relay. If it doesn't, then I would suspect either the: 1) TREG card; 2) cable connecting the TREG to the <Z> VPRO; or, 3) the <Z> VPRO.

Having said all of that, I don't think this alarm will ever cause a unit trip or forced outage. But, it is a nuisance Diag. Alarm. It's certainly worth trying exchanging the relays; if the problem follows the relay, then replace the relay. If it doesn't, then make sure the cable connecting the TREG to <Z> VPRO is firmly seated at both ends (when the unit isn't running!), and then start replacing components in the order listed above.

Let us know how the troubleshooting progresses. Feedback is what makes the posts as control.com useful for many people; hopefully you've already done some searches on control.com and found some with feedback that are helpful (if not, use the 'Search' feature; it's very good!).

Dear CSA,

First of all, I am very sorry for the delayed reply, this is because we cannot do your proposed tests until the unit is out of service.

We first started to do some disabling for the monitoring contacts of the Relays of TREG from the toolbox. The problem was not solved.

Then we swapped the <Z> VPRO with <Y> VPRO, now we catch the problem's cause. The alarm swapped to <Y> VPRO, that means it was the <Z> VPRO. For the time being we have no spare, but we will order (GOD WILLING).

We are now experiencing a fatal MARK6 Error, causing the unit to shut down maybe every 15 days. That is the IONet communication error. We have two units controlled by MARK6. The commissioning was from approx 2 years. We got in the last two months many IONet errors, causing the Core <T>, and/or <R> especially to be out of service and not possible to get reset.

First we got an IONet 1 failure on VCMI R, we checked the coaxial cables of IONet 1 and no change, but when we opened the terminal resistor of this IONet and put again and RESET it accepts the reset. BUT the second day the unit tripped again by the same fault. We changed the VCMI of core R, and the unit was still ok for one month. After one month the unit tripped again and caused the other unit to trip because of the core <T> failure in both of them. First we found from our investigation the following alarm toggles in both units maybe thousands of times:

31-AUG-2008 00:44:27.303 K101 1 Q 0000 ALM ALARM XMIT SUSPENDED. CPU SWITCHED.
31-AUG-2008 00:44:27.303 K101 0 Q 0000 ALM ALARM XMIT SUSPENDED. CPU SWITCHED.

Then one unit tripped by controller failure and after 30 minutes the other failed.

Could you please clarify the meaning of such <ALM ALARM XMIT SUSPENDED. CPU SWITCHED>? And could you please tell me about your suggestions for the cause(s) and solution of this IONet problem?

Moreover, it supposes that we have TMR system, when one core IONet fails why does the unit trip?
Please advise me.

Best Regards.

I'm extremely confused now. Because the original post said this was a Mark VI SIMPLEX application, and now you're talking about TMR processors.

I suggest you obtain the services of someone who can help correct the issues with the control panel(s) (whatever they are) and get the units running reliably. It really sounds like there are some possibly serious configuration issues at the site which are too complicated to try to resolve in this forum in any reasonable time frame.

Just because a system is TMR does not mean it was configured properly and can stand a failure of any single element. There are many, many, many components to a TMR system, not just the three control processors. If the servo-valve currents have not been verified the loss of a single processor can result in a "trip" because the servo will shut off the flow of air or fuel to the unit. You haven't said what the alarm messages are when the unit(s) experience tripping, so it's not possible for us to tell you why your "TMR" system is not behaving as you would think it should behave.

By the way, just because a Mark VI SIMPLEX has three VPROs in <P> does not make a TMR control system. (You didn't say exactly that, but I've heard it from several people over the years.)

Again, invest in some engineering time to analyze and resolve the problems at your site; it will be time and money well spent. There are numerous companies offering Mark VI services, though if the problems are really severe (and it sounds like they are approaching that level) it might be best to get a field engineer from GE who can liaise with the factory personnel in resolving the problem(s).

Dear CSA,

The first VPRO problem was for simplex system.
But the other problem of the trip of the two turbine together is for TMR system. We have both systems in our plant, simplex and triplex TMR.

This is the answer of the first question. The second question is to invite GE specialist to our site, and this already done, and take some data and send to SALM, USA and said that the reply will be delayed. So I want to know the root cause of this problem.

I think the last frequent alarm that I told you about is the cause, but what is meant by this alarm (XMIT SUSPENDED. CPU SWITCHED)? And how can I solve it?

PLEASE ADVISE ME.

Regards,
AMAM

There's a couple more things I want to bring up here. You mentioned disabling monitoring of contact monitoring. I would *sincerely* recommend *never* doing that. As I wrote, the alarm won't cause unit trips if it's on an unused output. Sometimes (and one can *NEVER* know exactly when) things are not well described or all the attendant and linked functions of certain configurations are not well documented. This is the trip protection logic and configuration we're talking about here; best never to mess with that. I hope you have restored it to it's original configuration.

Second, judging from your reply about trying to disable this or that, it would seem you are doing a lot of downloads and re-boots. This can quite often cause the kinds of problems you are describing. Best to keep downloads to a minimum. All too often people think a problem can be solved by a download and a re-boot, and don't realize the problems they can create by doing so. Especially if there are multiple HMIs being used for the downloading.

(And, yes; for those of you paying attention, the "equal" indication on the Status Bar isn't always 100% correct. When is it not? Again, that's one of those things that are just never really documented. Only speaking the truth here. For the majority of uses, the indications are spot on. However, when it's not, there are usually some Diagnostic Alarms which are indicating some kind of problem, however cryptic. And when performing multiple downloads during troubleshooting, it's very easy to get confused on which processors were downloaded to and which were not and what was downloaded where. My personal suspicion is that the selection that one gets to make about which processor to connect to when going online with the Mark VI can "influence" what's shown in the equal indication area of the Status Bar. That's just my *personal* suspicion; I have no hard data to back it up other than personal experience and anecdote, but when one changes processors when doing nothing else, the equal indication can change, so draw your own conclusions from your own testing.)

Third, I have heard this many times over the years: the "control system" causes a trip every eight days, or every 15 days, or every 29 days. That's just absurd. Usually, the problem is poor alarm management and poor maintenance practices. Okay, the unit might trip periodically (it shouldn't!) but when pressed for details about each trip, which were allegedly all caused by the same reason(s), it's discovered that the trips were usually not even vaguely related. And that's only if the alarm printer logs can be found, and it's simply amazing how many time people just shut the printer off because of dithering alarms instead of fixing the root cause(s) of the alarms. Or, it runs out of paper or ribbon and nobody can be bothered to change the paper or ribbon. So, there's no real record of the trips, and nobody bothered to download the trip history after every trip, or the files got "lost". No control system that I've ever seen had some kind of "timer" that would just trip every eight days, or every 15 days, or every 29 days. It's just preposterous to even suggest such a thing.

Just by virtue of the fact that control systems are "complicated" (and that's a relative term), they always get the blame for everything. And they are quite often used to mask or put a band-aid on problems which are unduly blamed on them. Of course it must be the control system; just look at all that wire and all those printed circuit cards and all that confusing software! While nobody ever comes right out and says it, that's what a LOT of operators, technicians, supervisors, and plant managers always think. Sometimes it makes me wish I hadn't gone into the controls field; every time there's a problem the first thing which get the blame and which has to be proven not to be the problem is the control system. And, then someone always thinks that every problem can be "fixed" by making some change to the control system. It's made for an awful lot of non-productive work for me (of course I always got paid for my efforts, but when you're the OEM rep and that company is deemed to have deep pockets and it's not their money that's being spend, start-up managers and plant managers always try to blame every problem on the control system). And, then a lot of problems when I refused to tweak this Control Constant or that bit of logic to get around a bad gas compressor or an incorrectly sized pressure-regulating valve or air and/or water in the liquid fuel. "Just add a couple of seconds to the loss of flame detection!" Sure; that's a real good idea. And when the HRSG blows up, who's gonna get the blame for actually making the change? Not the people who were insisting it be done; "He should have known better and not listened to us!"

Fourth, you haven't mentioned what Diagnostic Alarms are present on the unit; like most operators and technicians, no one pays attention to Diagnostic Alarms. They are useful, if difficult to understand. And, quite often they can help with certain "nuisance" and "intermittent" problems.

Fifth, what can you tell us about the ground system at your plant and what, if any, grounds are on the Mark VIs? Is there a separate protective earth and separate instrument earth? Have you measured the potential (voltage) difference between the two ground systems? (Just use a good voltmeter, and connect one lead to the instrument earth inside the control panel and the other lead to the protective earth connection in the control panel. Check both AC and DC voltages. There should be *no* difference, but I'm finding *lots* of installations where there are between 5 and 20 VAC or 2 and 10 VDC difference.)

However, from the sounds of it, you're fighting battles on several fronts, and you should have someone come to site and help resolve them. Then stop downloading and re-booting. You may have learned that in Mark VI class, but I can assure you that it's not proper maintenance procedure. It might have fixed a "problem" in a controller in Mark VI class, but it's not the first course of action for an operating unit. I can't tell you how many people have told me, "That's how we got the simulator to run in Mark VI class; we just did another download! And rebooted the simulator by killing the power to the entire panel and then turning it back on." Remember, the "simulator" doesn't have any instruments connected to it. Remember, the "simulator" gets downloaded to a *LOT*. Remember, the easy way to re-boot the "simulator" is just to turn off the power. Remember all the trouble you had with the "simulator".

I personally have a lot of issues with turbine control system training in general, not just the methods they use in the lab and so "promote" their use in the field. A control system is MUCH more than just the Mark V or Mark VI; it's all the devices and instruments connected to the turbine control system. It's been said by others here on control.com, that 99% or more of alleged control system problems are problems with the devices or instruments connected to the control system, OR, problems with the way people *think* the control system should operate the turbine. Neither of which are taught in Mark VI class. They don't teach very much, if anything, about Diagnostic Alarm troubleshooting. They don't teach very much if anything about servo-valve operation. They teach very little if anything about start-up sequences and shutdown sequences and how droop speed control works (they leave that control.com!) or how to determine when combustion mode changes should occur on machines equipped with DLN combustors. They teach very little if anything about how to troubleshoot process alarms, like, 'Hydraulic Protective System Trouble' or 'Startup Fuel Flow Excessive Trip' or 'P2 Pressure Test Failed'. Instead, they teach about adding flashing lights to CIMPLICITY displays, or adding I/O and sequencing--none of which most people will ever do. But, if that's what they teach in class, then everyone thinks that every problem can be fixed by changing sequencing or configuration or downloading to the panel. And that's where more problems are usually caused than solved.

So, try not to emulate too much of what you learned in Mark VI class; instead, try to learn to read the application code in Toolbox and troubleshoot alarms (Process and Diagnostic) and how to use the Device Summary and Interconnection Diagram and Generator Control Panel elementary to troubleshoot alarms and understand turbine operation. And, don't be doing downloads and re-boots every time a new and cryptic alarm is annunciated. In fact, once a turbine is properly configured, one shouldn't need to download at all, except for constant changes as a result of LVDT feedback calibration.

Come on, he asked you a direct question. What is the meaning of the alarm "XMIT Suspended, CPU Switched"? If you don't know, then just say, "Sorry, bud, I don't know." We have better things to do than read twelve pages of ranting.

very good, accurate and sincere advices