Mark V C core problems

G

Thread Starter

gisaac

We have a TMR Mark V that has one I/O board associated with C core. The I/O on this board is analog data and occasionally the data will freeze. The only way for data to start updating again is to reboot C core. This has been going on for quite sometime now. Any ideas on what may be hanging the processor?

Thanks,
Guy
 
How old is your Mark V panel?

Have you implemented all of the recommended TILs for the Mark V, replacing PROMs for improved I/O communications?

Is the panel being used on a generator drive application or a mechanical drive application?

If the application is for a generator drive, what is the generator frequency, 50 Hz or 60 Hz?

Is the I/O that's freezing on the TBQA card, and is it thermocouple inputs?

When this happens are there any Diagnostic Alarms annunciated by the Mark V? If so, what are they?

What other Diagnostic Alarms are present when the unit is running?

Are there any error messages on the LCC/SLCC display when this occurs? If so, what are they?

Please be careful when saying the <C> is "failing", because if you are still seeing data on the <I> or HMI (which is it?) when it freezes, then <C> has not failed, just the inputs from the terminal board (which you did not identify in the original post; it would have been easy to say which card, why didn't you? Why do we have to ask which card the inputs of are freezing?) have stopped updating.

I believe, and it's been a LONG time, but in early Mark V panels with older PROMsets, there was a problem with certain cards and 50 Hz machines. I believe newer PROMs asked if the application was a 50 Hz generator, and applied some filtering to the inputs. Again, it's been a long time, but if the panel has not been updated per the many GE TILs (Technical Information Letters) and it's an older panel on a 50 Hz generator drive application, then this might be the problem. But it might not; but it's a good place to start looking.

Please try to provide as much relevant information as possible in your initial post; it really helps to get a more concise answer sooner, though without being able to recall or see all the relevant TILs this may or may not be a cause for your problems.

Do you have a good relationship with GE or one of it's packagers that you can call and report the PROMset and card revision information to for help understanding if you've the latest and most up-to-date PROMsets and cards?
 
The I/O that is freezing is on the CTBA board. This unit is used to run a 7EA turbine/gen set, 60Hz. It was installed around 2003-2004. I only provided the information that I had, didn't mean to upset anyone for not providing detailed information. To the best of my knowledge, there has not been much, if any, TIL updates to this control system. I will get the technicians to check for any diagnostic or LCC/SLCC errors the next time the I/O freeze occurs.

This has been a problem on and off since installation. We were told that it was related to a ground fault that was on the unit but that has been resolved without any effect on the I/O freeze.

Thanks for the reply.
 
The IO froze again this past Friday. This is the information I received from the technicians. They said the only thing they see on the SLCC display is " 1 DCC Errors" and "IO CFG BAD RESP". Any thoughts on this?

Thanks
 
H
Seriously consider the Prom TIL, you need to start from a known point so the rest of us can help you.
 
What have you done to try to resolve the problem other than resolve a ground?

To Hal Armour's point, why won't you tell us specifically what input or output that is connected to the CTBA ceases to do whatever it's supposed to be doing so we can be of more help? Is it all the inputs or just one, or two, or ? Is it all the outputs or just one, or two, or ? Is it both inputs and outputs? What happens when this freezing occurs? Does the Mark V stop seeing an input to the CTBA or several inputs to the CTBA? Or does an output of the CTBA stop updating or is it several outputs?

As I recall (and I don't have access to the Mark V App. Manual or any Mark V software at this time), the CTBA is mA inputs and mA outputs. So you seem to be saying that something connected to the CTBA, either a mA output from the CTBA which is providing some signal or indication to some PLC or DCS or meter or a mA input to the CTBA which is being used by the Mark V is required by either the device that's receiving the signal or the Mark V requires the signal for some control or monitoring purpose.

Is there a loop isolator connected between the Mark V and any CTBA mA input or output to another control system, like a PLC or DCS? Because if there is an input or an output that's connected to another control system such as a PLC or a DCS, they usually require a loop isolator to prevent common mode voltage problems.

Have you checked the cables connecting the CTBA to the other cards in <C> to see if they are firmly seated, and if they have any corrosion or have the recommended conductive grease applied?

Any input or output connected to <C> should not be "critical" to the operation of the turbine or auxiliary systems. That's a given, and it doesn't seem to be the case because you can re-boot <C> and it doesn't seem to affect the operation. But wait; we don't even know if this happens when the unit is running or when it's not running or both. There's just a lot we don't know, except that there's a problem. With some input or output connected to the CTBA (which took some time to establish).

The more I sit and write, the more I believe that this is fruitless. There's just too much we don't know. There was an apology for not providing detailed information, but no detailed information has yet been provided. All we know is it's been going on for a long time, it's not related to a ground that's been resolved (congratulations), it can't be said what if any of TILs have been done, and the LCC display says there's been an error when this happens. And, after some time, we got to the CTBA card.

Please be precise, because this is beginning to smell like someone who's fishing for possible answers to pass along to their tech's....
 
> What have you done to try to resolve the problem other than resolve a ground? <

Evidently that was not the problem...only the field engineer's recommendation.

> To Hal Armour's point, why won't you tell us specifically what input or output that is connected to the CTBA ceases to do whatever it's supposed to be doing so we can be of more help? <

All IO freezes on the CTBA board. This has been verified outside of the cimplicity graphics. Actually looking at live values directly on the mark v, none of the IO on the CTBA board is changing.

> As I recall (and I don't have access to the Mark V App. Manual or any Mark V software at this time), the CTBA is mA inputs and mA outputs. So you seem to be saying that something connected to the CTBA, either a mA output from the CTBA which is providing some signal or indication to some PLC or DCS or meter or a mA input to the CTBA which is being used by the Mark V is required by either the device that's receiving the signal or the Mark V requires the signal for some control or monitoring purpose. Is there a loop isolator connected between the Mark V and any CTBA mA input or output to another control system, like a PLC or DCS? Because if there is an input or an output that's connected to another control system such as a PLC or a DCS, they usually require a loop isolator to prevent common mode voltage problems. <

Some signals do interface with a d20 RTU. No isolators involved. We have 6 other turbine/gen sets that are identical with no isolators and no problems.

>Have you checked the cables connecting the CTBA to the other cards in <C> to see if they are firmly seated, and if they have any corrosion or have the recommended conductive grease applied? <

Cables have been checked

> Any input or output connected to <C> should not be "critical" to the operation of the turbine or auxiliary systems. That's a given, and it doesn't seem to be the case because you can re-boot <C> and it doesn't seem to affect the operation. But wait; we don't even know if this happens when the unit is running or when it's not running or both. There's just a lot we don't know, except that there's a problem. With some input or output connected to the CTBA (which took some time to establish). <

Took longer for response to show up since everything has to be run through the mods...The only time that the problem is realized is when the unit runs (which isn't very often) and the values are expected to change and they don't. The problem shows up at any time. i can't say only when it runs or is shutdown. One of the signals is a speed (rpm) signal (analog output to RTU). Sometimes the unit comes up and the speed indication never changes (0 rpm)...Other times the unit runs fine and when taking it off the rpm indication remains at 3600. So I think that rules out anything relating to an issue only when the unit is running or is offline.

>The more I sit and write, the more I believe that this is fruitless. There's just too much we don't know. There was an apology for not providing detailed information, but no detailed information has yet been provided. All we know is it's been going on for a long time, it's not related to a ground that's been resolved (congratulations), it can't be said what if any of TILs have been done, and the LCC display says there's been an error when this happens. And, after some time, we got to the CTBA card. <

See earlier reply by me about the TILs. I reply when I can, this is not the only thing I have to do. Not gonna sit around and hit refresh to see if anyone has responded. I check when I have time to check.

>Please be precise, because this is beginning to smell like someone who's fishing for possible answers to pass along to their tech's.... <

I wasn't expecting level 1 type responses...But sometimes the obvious is over-looked. I thought the intent of this forum was to help others and provide information. i don't think it was intended to be a bashing board for every post. i am experiencing a problem with a Mark V TMR controller and thought maybe someone has seen this type of problem before and could provide some insight.

Anybody seen Markvguy? There's a wealth of knowledge and doesn't get offended by people's posts.

Thanks for replying Hal. I am researching the TIL. But I am almost 100% sure it was not performed unless it was done prior to installation around 2004.
 
H
How about an update, any progress yet? One of the reason's we post and respond is so that we all can learn. If a particular fix works for you others may be able to apply it also!
 
Top