Mark V DCCC Alarms

Mark V DCCC Alarms
Posted by RVSSSRAO on 6 December, 2006 - 12:30 am

We have many DCC errors increasing continously in <S> Core of Mark V Control System. How to proceed
with below alarms? please let me know step by step procedure. We have checked JL Cables, Relays,
Replacement of DCC Card etc. Further let us know on how to solve.

D10-<s> DCC DPM: no BMS memory for isr
D7- <s> DCC unable to get DPM Buffer for Xmit
D2- <s> DCC-BMS out of memory
D9- <s> DCC DPM Invalid destination address
DCC errors found 20028 and was increasing

1708 <S>TCE1 Loop back relay,PTR1 1698<S> TCE1 TMR check trouble,PTR1 1354 <S> TCQA
PTR1relay driver RD2 failure 1698 <T> TCE1 TMR check trouble,PTR1 1698 <R> TCE1 TMR check
trouble,PTR1 2344 <S> Voter mismatch ,<S> L4PTR1 FB

thanks in advance.
rvsssrao
Reply to this post...

Posted by markvguy on 6 December, 2006 - 8:21 pm
Did this problem start occurring after some incident or after some other card in <S> was replaced (like the
LCC/SLCC or the TCQC card)?

>From the second group of Diag. Alarms, it appears that <S> has decided NOT to participate in running the
turbine, so effectively you have only the designated voter (usually <R>) controlling the unit when it is
running....

It is presumed that <S> is at I/O Status A7 at all times while this occurring. Have you used the LCC/SLCC
display keypad to check the I/O Status of the cards in <S> and associated with <S>? (Search control.com
for explanations of how to use the LCC/SLCC keypad to check I/O Status of individual cards.)

The first group of Diagnostic Alarms usually occurs when either there are too many requests being made of
a processor OR when there is a problem with the configuration of the requests OR when there is a problem
with the communication cabling OR if there is a problem with the hardware ("Berg") jumper settings on
either the LCC/SLCC and/or the DCC/SDCC cards.

Unless there is some VIEWn routine which is asking for a LOT of information from <S> processor ALL
the time, the first doesn't seem too likely--unless there's something you're not telling us. Like, is this on an
LM Mark V panel???

Since it would most likely be only that one of the other processors (<R>, <T>, <C>) that would be
configuring the requests of <S>, so this doesn't seem like it's the cause of the problem, either.

If the requests for data which didn't exist at a particular memory location were being made, this could also
cause the problem--but it would seem that it would occur on every processor.

The DENET (Data Exchange NETwork) is how the control processors and <C> communicate. If there was
a problem with the DENET or the cabling or the cards through which the DENET passes, this may cause
problems similar to the one you are experiencing. The routing of the DENET is kind of vague, but includes
the TCQC card (the VARC cable) and the LCC/SLCC card.

It's conceivable that there is a hardware ("Berg") jumper setting issue--have you confirmed that all the
hardware jumpers on the LCC/SLCC, DCC/SDCC cards in <R>, and <S>, and <T> match each other? You
should also check the VARC and ARCPL cable connectors on the TCQC card of <S> and the LCC/SLCC
card of <S> (refer to the Signal Flow Diagrams in Appendix D of the Mk V Application Manual, GEH-
6195, the drawing titled "<Q> Core - DENET and BUNet Connections on TCQC Terminal Board."

You say you've replaced the DCC card, so that shouldn't be the problem. Try replacing the LCC card, then
the TCQC card.

Many times these nuisance Diag. Alarms don't result in problems with running the unit, but if your post is
understood correctly and you have all the Diag. Alarms you listed in the post at the same time, then there is
definitely something which is causing <S> to not participate in running (and protecting) the unit, and you
are right to want to get it corrected.

It's really difficult to tell you exactly how to proceed, since we don't know exactly what PREceded this
condition and what all has been done. And when someone says they.ve done this or that, ETC., it's difficult
to know exactly what was done and how it was done.

There is a TIL (Technical Information Letter) out about using conductive grease on the connectors of the
cards in Mk V turbine control panels. It's conceivable that there is a high-resistance connection in one of
the connectors which is causing a problem. It would be necessary to shut down to do this, but have you did
you use the conductive grease when you replaced the DCC card? Have you tried unseating and reseating
the VARC and ARCPL connectors (again--do this only with the unit shut down and <S> powered down!)?

You can always consult with the OEM/packager for more help/assistance. If you have a GE-packaged unit
you may be able to convince your local Customer Service representative to open a PAC (Power Answer
Center) case for you.

Let us know what you find out!

markvguy

Posted by RVSSSRAO on 9 December, 2006 - 10:20 am
> Did this problem start occurring after some incident or after some other card in <S> was replaced (like
the LCC/SLCC or the TCQC card)?

ANS : NO .STARTED SUDDENLY.SOME QUIET SOME MONTHS NO DCC ALARMS APPEARED.
>
> >From the second group of Diag. Alarms, it appears that <S> has decided NOT to participate in running
the turbine, so effectively you have only the designated voter (usually <R>) controlling the unit when it is
running....
>
> It is presumed that <S> is at I/O Status A7 at all times while this occurring. Have you used the
LCC/SLCC display keypad to check the I/O Status of the cards in <S> and associated with <S>? (Search
control.com for explanations of how to use the LCC/SLCC keypad to check I/O Status of individual cards.)

ANS : CHECKED ALL CARDS STATUS. SHOWING A7.

> The first group of Diagnostic Alarms usually occurs when either there are too many requests being made
of a processor OR when there is a problem with the configuration of the requests OR when there is a
problem with the communication cabling OR if there is a problem with the hardware ("Berg") jumper
settings on either the LCC/SLCC and/or the DCC/SDCC cards.

ANS : SO HOW TO CHECK FOR TRAFFIC IN COMMUNICATION NODES.

> Unless there is some VIEWn routine which is asking for a LOT of information from <S> processor ALL
the time, the first doesn't seem too likely--unless there's something you're not telling us. Like, is this on an
LM Mark V panel???

ANS : NORMALLY WE ARE COLLECTING VIEWn DATA FROM <S> OF ALL GT
PROCESSORS.PRESENTLY NOT INITIATED WHEN MACHINE IS RUNNING.
>
> Since it would most likely be only that one of the other processors (<R>, <T>, <C>) that would be
configuring the requests of <S>, so this doesn't seem like it's the cause of the problem, either.

ANS : SO HOW TO CHECK. WHERE TO CHECK.

> If the requests for data which didn't exist at a particular memory location were being made, this could
also cause the problem--but it would seem that it would occur on every processor.
>
> The DENET (Data Exchange NETwork) is how the control processors and <C> communicate. If there
was a problem with the DENET or the cabling or the cards through which the DENET passes, this may
cause problems similar to the one you are experiencing. The routing of the DENET is kind of vague, but
includes the TCQC card (the VARC cable) and the LCC/SLCC card.
>
> It's conceivable that there is a hardware ("Berg") jumper setting issue--have you confirmed that all the
hardware jumpers on the LCC/SLCC, DCC/SDCC cards in <R>, and <S>, and <T> match each other? You
should also check the VARC and ARCPL cable connectors on the TCQC card of <S> and the LCC/SLCC
card of <S> (refer to the Signal Flow Diagrams in Appendix D of the Mk V Application Manual, GEH-
6195, the drawing titled "<Q> Core - DENET and BUNet Connections on TCQC Terminal Board."
>
> You say you've replaced the DCC card, so that shouldn't be the problem. Try replacing the LCC card,
then the TCQC card.
>
> Many times these nuisance Diag. Alarms don't result in problems with running the unit, but if your post is
understood correctly and you have all the Diag. Alarms you listed in the post at the same time, then there is
definitely something which is causing <S> to not participate in running (and protecting) the unit, and you
are right to want to get it corrected.

ANS : BUT WE 1 SHORT OF NUISANCE TRIP.

> It's really difficult to tell you exactly how to proceed, since we don't know exactly what PREceded this
condition and what all has been done. And when someone says they.ve done this or that, ETC., it's difficult
to know exactly what was done and how it was done.
>
> There is a TIL (Technical Information Letter) out about using conductive grease on the connectors of the
cards in Mk V turbine control panels. It's conceivable that there is a high-resistance connection in one of
the connectors which is causing a problem. It would be necessary to shut down to do this, but have you did
you use the conductive grease when you replaced the DCC card? Have you tried unseating and reseating
the VARC and ARCPL connectors (again--do this only with the unit shut down and <S> powered down!)?

ANS : GREASE WAS NOT USED.

> You can always consult with the OEM/packager for more help/assistance. If you have a GE-packaged
unit you may be able to convince your local Customer Service representative to open a PAC (Power
Answer Center) case for you.
>
> Let us know what you find out!
> markvguy

Much of the first reply was kind of "thinking on html", kind of going through a mental check-list of what
could be causing the problems. Unfortunately, the designers of the Mk V did not provide much in the way
of internal troubleshooting capabilities, so easily checking for DENET traffic is not possible. In fact,
troubleshooting internal operations is difficult even for GE factory personnel, since there are not many
avenues to get at internal operating data and there aren't many engineers left that familiar with Mk V
turbine control internal operations.

One of the first questions to ask here is: Do you have s or GE Mark V HMIs? If you have HMIs, have
you always had HMIs or were they recently purchased/installed--along with new PROMset(s)???

Have you implemented TIL-1480 R2?

It's VERY interesting that the problems are only being experienced on <S>, and that <S> is being
"interrogated" using one of the VIEWn tools.!.?.!

Which VIEWn tool(s) are you using to gather data?

Are you using a file to list the points to be gathered by the VIEWn tool? If so, can you copy the pointlist
file to a reply?

Are you using a batch file to run the VIEWn tool? If so, does the VIEWn utility generate any "warning"
when it is started by the batch file?

At what rate is the data being gathered with the VIEWn tool? Please list the command line entry which is
used to start the VIEWn tool?

When did you start using VIEWn to gather data from the <S> processors? Did you make any changes to
the VIEW2 data file/routine around the time the DCC errors began?

What happens when you clear the system errors from the LCC Display keypad when the VIEWn utility is
NOT running? (To clear system errors using the LCC Display keypad, press DCC on the LCC display
keypad; '186 MONITOR' should appear in the display. Press INC until 'CLEAR SYS ERRORS' is shown
in the display, then press ENTER. Press INC again until 'CLEAR SYS ERRORS' is shown in the display
and press ENTER again. If the number shown is 0, then errors have been cleared and reset; if the number is
small or is incrementing while you are watching it, the errors have not been cleared. Press NORM to return
to the default display, or the display will return to the default display after a brief period of time.)

You seem to be saying that there are periods of time when the alarms do not appear, then they suddenly
start appearing again. Is that correct?

Have you tried replacing the LCC card?

Again, it's very difficult to say how to proceed because it's very difficult to know what's been done, what's
being done, and how things were done. Don't take offense at that; it is sensed that you are somewhat
frustrated with the responses you are getting, but you should know that there are LOTS of sites which are
experiencing the SAME problems you are and they run just fine day in and day out--and even GE doesn't
know exactly what to do to resolve the problem(s). You are getting assistance from a free forum--if you
were paying for this advice, you might have a legitimate gripe.

You're comment about being "...1 short of nuisance trip..." is completely baffling.

Unfortunately, because of the lack of troubleshooting tools for problems such as this, it quite often boils
down to the (repugnant) task of swapping cards...

It is recommended that you shut the unit down, power down the <S> processor, unseat (unplug) all the
cables one at a time and before plugging them back in applying the recommended conductive grease to the
terminals (you can usually find conductive grease packed in the boxes with spare printed circuit cards; GE
started shipping the grease in the late 1990's with all cards sold as spares or repair-and-return
replacements), and then reseating the cables. This should be done on all the cables of the LCC card, the
DCC card, and the TCQC card--especially the cables labelled VARC and/or ARCPL.

Be sure to pay attention to the orientation of the cables on the LCC card, especially the cables attached to
connectors at the bottom of the card. Also, be especially careful with the 3PL cable which runs between the
LCC card, the DCC card, and the TCQA (and TCQB, if so equipped). The 3PL cables does not have pull
tabs and it can be very easily damaged if not pulled loose very carefully and reseated by pressing very
firmly all along the top rib of the connector!

If that doesn't resolve the problem, then try replacing the LCC card.

This author believes there is some "feature" of certain Mk V PROM revisions which, when activated by an
incorrectly formed request for data or for data which which doesn't exists or for data at an "excessive" rate
causes the DPM (Dual-Ported Memory) and associated memory buffers and memory handling routines to
be corrupted, sometimes beyond "repair". In most cases, these alarms are nuisance alarms and don't
adversely affect the operation of the unit (again, if a poll of Mk V operators/technicians was taken, it would
probably reveal that somewhere between 30- and 40% of panels exhibit this behavior either intermittently
or continually...sad, but true!).

What's troubling in your case is the PTR1 Feedback trouble and relay driver failure alarms, which indicate
more serious problems--possibly (likely) not even related to the LCC errors. That's one of the difficulties of
dealing with issues like this that have existed for some period of time before something else happens which
causes people to take notice and begin to "relate" unrelated things. Understanding and troubleshooting Mk
V internal operations and Diagnostic Alarms takes quite a bit of patience and on-the-job experience. And,
has been said many times previously--ANY process- or diagnostic alarm should be troubleshot and
resolved as quickly as it is annunciated. Failure to do so can cause huge amounts of time and effort to be
wasted; take it from experience.

markvguy

Posted by RVSSSRAO on 10 December, 2006 - 12:39 pm
ANS(RVSSSRAO) : WE HAVE HMI'S SINCE MACHINES WERE COMMISSIONED IN 2003.
>
> Have you implemented TIL-1480 R2?

ANS(RVSSSRAO) : TIL 1480 R2 WAS IMPLEMENTED BUT SAME DIAGNOSTIC ALARMS
CONTINUED.

> It's VERY interesting that the problems are only being experienced on <S>, and that <S> is being
"interrogated" using one of the VIEWn tools.!.?.!
>
ANS(RVSSSRAO) : WE COLLECT VIEW 2 DATA FOR REFERENCE PURPOSE & DATA IS
COLLECTED FROM <S> CORE ONLY. WE HAVE 6 GT'S & FOR ALL GT'S WE COLLECT DATA
FROM <S> CORE. BUT WE HAVE DIAGNOSTIC ALARMS FROM <S> OF ONE OF OUR GT'S.

> Which VIEWn tool(s) are you using to gather data?
>
ANS(RVSSSRAO) WE USE VIEW 2 FILE FOR DATA COLLECTION.

> Are you using a file to list the points to be gathered by the VIEWn tool? If so, can you copy the pointlist
file to a reply?
>
ANS(RVSSSRAO) : WE CREATE A FILE WITH LIST OF POINTS TO BE COLLECTED.

> Are you using a batch file to run the VIEWn tool? If so, does the VIEWn utility generate any "warning"
when it is started by the batch file?
>
ANS(RVSSSRAO) : WE RUN BATCH FILE FOR COLLECTING DATA.

> At what rate is the data being gathered with the VIEWn tool? Please list the command line entry which is
used to start the VIEWn tool?

ANS(RVSSSRAO) : 1 SAMPLE PER MINUTE FOR 50 POINTSMAXIMUM.

> When did you start using VIEWn to gather data from the <S> processors? Did you make any changes to
the VIEW2 data file/routine around the time the DCC errors began?
>

ANS(RVSSSRAO) : WE USE VIEW 2 FILE WHEN WE DO FUEL CHANGEOVER ONLY OR
DURING PERFORMANCE TESTS ETC.NO ACTIVITY WAS DONE RECENTLY ON VIEW2 FILE.

> What happens when you clear the system errors from the LCC Display keypad when the VIEWn utility is
NOT running? (To clear system errors using the LCC Display keypad, press DCC on the LCC display
keypad; '186 MONITOR' should appear in the display. Press INC until 'CLEAR SYS ERRORS' is shown
in the display, then press ENTER. Press INC again until 'CLEAR SYS ERRORS' is shown in the display
and press ENTER again. If the number shown is 0, then errors have been cleared and reset; if the number is
small or is incrementing while you are watching it, the errors have not been cleared. Press NORM to return
to the default display, or the display will return to the default display after a brief period of time.)

ANS(RVSSSRAO) : EVEN AFTER RESETTING ALARMS ARE INCREASING CONTINUOSLY
WHEN VIEW 2 FILE IS NOT RUNNING.WE DO THE SAME PROCEDURE FOR CLEARING OF
ALARMS FROM LCC.

> You seem to be saying that there are periods of time when the alarms do not appear, then they suddenly
start appearing again. Is that correct?

> ANS(RVSSSRAO) : FOR 3-4 MONTHS FROM NOW NO ALARMS WERE EXISTING .SUDDENLY
DURING MAINTENCE WE SWITCHED OFF ENTIRE MARK V PANEL POWER SUPPLY & SICE
THEN IT STARTED.

> Have you tried replacing the LCC card?

ANS(RVSSSRAO) : YES

> Again, it's very difficult to say how to proceed because it's very difficult to know what's been done,
what's being done, and how things were done. Don't take offense at that; it is sensed that you are somewhat
frustrated with the responses you are getting, but you should know that there are LOTS of sites which are
experiencing the SAME problems you are and they run just fine day in and day out--and even GE doesn't
know exactly what to do to resolve the problem(s). You are getting assistance from a free forum--if you
were paying for this advice, you might have a legitimate gripe.
>
> You're comment about being "...1 short of nuisance trip..." is completely baffling.
>
> Unfortunately, because of the lack of troubleshooting tools for problems such as this, it quite often boils
down to the (repugnant) task of swapping cards...
>
> It is recommended that you shut the unit down, power down the <S> processor, unseat (unplug) all the
cables one at a time and before plugging them back in applying the recommended conductive grease to the
terminals (you can usually find conductive grease packed in the boxes with spare printed circuit cards; GE
started shipping the grease in the late 1990's with all cards sold as spares or repair-and-return
replacements), and then reseating the cables. This should be done on all the cables of the LCC card, the
DCC card, and the TCQC card--especially the cables labelled VARC and/or ARCPL.

ANS(RVSSSRAO) : WE WILL BE DOING THIS BUT HOW DIFFICULT TO REMOVE THE
CONNECTOR ONCE GREASE HAD BEEN APPLIED.

> Be sure to pay attention to the orientation of the cables on the LCC card, especially the cables attached to
connectors at the bottom of the card. Also, be especially careful with the 3PL cable which runs between the
LCC card, the DCC card, and the TCQA (and TCQB, if so equipped). The 3PL cables does not have pull
tabs and it can be very easily damaged if not pulled loose very carefully and reseated by pressing very
firmly all along the top rib of the connector!
>
> If that doesn't resolve the problem, then try replacing the LCC card.
>
> This author believes there is some "feature" of certain Mk V PROM revisions which, when activated by
an incorrectly formed request for data or for data which which doesn't exists or for data at an "excessive"
rate causes the DPM (Dual-Ported Memory) and associated memory buffers and memory handling routines
to be corrupted, sometimes beyond "repair". In most cases, these alarms are nuisance alarms and don't
adversely affect the operation of the unit (again, if a poll of Mk V operators/technicians was taken, it would
probably reveal that somewhere between 30- and 40% of panels exhibit this behavior either intermittently
or continually...sad, but true!).
>
> What's troubling in your case is the PTR1 Feedback trouble and relay driver failure alarms, which
indicate more serious problems--possibly (likely) not even related to the LCC errors. That's one of the
difficulties of dealing with issues like this that have existed for some period of time before something else
happens which causes people to take notice and begin to "relate" unrelated things. Understanding and
troubleshooting Mk V internal operations and Diagnostic Alarms takes quite a bit of patience and on-the-
job experience. And, has been said many times previously--ANY process- or diagnostic alarm should be
troubleshot and resolved as quickly as it is annunciated. Failure to do so can cause huge amounts of time
and effort to be wasted; take it from experience.

ANS(RVSSSRAO) : WHAT NEED TO BE CHECKED FOR PTR1 PROBLEM.

THANKS FOR ADVICE & SUGGESTIONS.

One thing you should know about GE Mark V HMI Servers versus s: They generate a LOT more traffic
on the StageLink than s--significantly more! And that's even BEFORE one starts running VIEWn
programs for data-gathering. (An HMI Server is an HMI with an ARCnet card that is communicating with
Mk V turbine control panel(s) on the StageLink.)

An only asks for data for points which are configured to appear on the display which is currently being
viewed on the monitor--as well as any MODBUS or GSM (GE Drive Systems Standard Message Protocol)
points, if the is configured for either of those communication options.

A GE Mark V HMI Server is ALWAYS asking for EVERY POINT configured in the CIMPLICITY Point
Database which is every point on every display--and if it's a multi-unit GE Mark V HMI Server, well it's
asking for that information for every unit it communicates with! (It is thought that's why GE has set a
"limit" of no more than two GE Mark V HMI Servers asking for data from a single Mk V turbine control
panel).

By the way--how many GE Mark V HMI Servers are asking for data from the Mk V turbine control panel
which has the problems with the <S> processor? (An GE Mark V HMI Server

There should be no increase in removing the connectors when conductive grease is applied; it is non-
hardening and "greasy" (i.e., slippery) and should actually make removing the connectors easier. There was
usually an information sheet packaged with the tubes of conductive grease about how to apply the grease.

Again, many times resolving an issue such as this comes down to replacing cards; this author abhors
"troubleshooting" that way, but sometimes there is no other way. Again, this author knows of many sites
which experience this same problem, have never even tried to troubleshoot the problem, and have
experienced no problems trying to start or run the units.!.?.!.? It's one of the "mysteries of Mk V."

One interesting thing that can be done is to swap cards between processors and see if the problem follows
the card. For example, take the DCC from <S> and exchange it with the one from <R>, do the appropriate
configurations and downloads after powering-up, re-boot and if the problem starts occurring in <R> and
not in <S>, then the problem is the DCC card. You can do the same with the LCC card. If the problem
stays in <S>, then it may be a VARC or ARCPL cable/connector problem.

markvguy

Posted by RVSSSRAO on 17 December, 2006 - 3:03 pm
We have 6 GT's with Individual HMI & control system at local & 3 nos. of multi user licensed HMI at
main control room ( 2 for <D> Core & 1 for <C> Core)

all are connected in daisy chain mode with Fibre optic cable via MOD HUB.for all GT's we are collecting
data from <S> Computer.

What is this it VARC or ARCPL cable/connector.

Thanks for reply in advance.

Posted by markvguy on 18 December, 2006 - 10:23 am
>From the 9th paragraph of the first reply, "...refer to the Signal Flow Diagrams in Appendix D of the Mk
V Application Manual, GEH-6195, the drawing titled "<Q> Core - DENET and BUNet Connections on
TCQC Terminal Board...."

markvguy

Posted by RVSSSRAO on 14 February, 2007 - 10:24 pm
Dear Mark V Guy,

We got the opportunity to go one step ahead in carrying out the further diagnosis in solving the <S> Core
DCC Errors.

We forced some signals like L4_XTP, L20 FG1X ETC to check the Relays status at TCTG Card. We found
k14 relay not getting activated. So we checked the cable from TCQA Card of <S> core to TCTG Card. We
repalced the cable & found no change in status. So find concluded that TCQA Card is faulty. So we
replaced the Card. Presently no diagnostic alarms appeared till now. Machine was taken back into service 2
days back. It's kept under observation. Any further action will be intimated to you.

Thanks for your action & continued support.

rvsssrao

Posted by markvguy on 15 February, 2007 - 11:20 pm
Congratulations on finding the problem, and thanks for the feedback! It helps everyone who reads the posts
and have or may have the same or similar problems. Thanks also for the details of the troubleshooting; they
are also very helpful to this author and others, as well.

markvguy

Posted by RAM on 12 December, 2006 - 3:53 pm
Hi,

Very very interesting and troubleshooting tips, hope this will help others also.

In this context there is one particular sentence I am not able to understand: "Since it would most likely be
only that one of the other processors (<R>, <T>, <C>) that would be configuring the requests of <S>, so
this doesn't seem like it's the cause of the problem, either."

Would you please elaborate the meaning of this sentence?

Regards,
RAM

It is presumed that <R>, <S>, <T> and <C> request information from each other at the beginning of the
frame. In thinking about, it seemed that if the requests of <S> were malformed by one processor, they
would be malformed to the other processors, who would be complaining similarly.

That's pure speculation, but it doesn't seem illogical. The internal operating system of the Mk V isn't
documented and there isn't any convenient way to observe the requests on DENET (Data Exchange
NETwork).

Again, most of this is just "thinking on html" trying to logically derive what the problem might be.

This author has seen several cases of individual processors being powered-down and then misbehaving
inexplicably when powered-up--especially when the main breaker feeding the entire panel is used to power
down the processors and power them back up all at the same time. Or, when the switch in the <PD> core is
cycled very quickly. Sometimes, just powering down for a minute or so with the switch in the <PD> core
will resolve the issue; sometimes it won't.

This is a practice which is quite common in Mk V training courses--when there's NO inputs or outputs
connected to the panel, and when they are being powered by AC-DC converters with limited current output
capability. In the field, Mk Vs are generally powered by nominal 125 VDC batteries with very high current
output typically through a 50A breaker, and chargers with high current outputs connected to the battery.
This author has never condoned the practice of re-booting an entire panel with the main breaker, even in
training classes. And what people see in class, they usually carry back to the field....

It will be interesting to learn how the Mk V panel was powered down.

markvguy

Marquer V DCCC Alarmes

Publi par RVSSSRAO le 6 Dcembre 2006 - 00:30
Nous avons beaucoup d'erreurs de plus en plus en continu CDC dans <S> de base du systme de contrle
V-Marc. Comment procder avec des alarmes ci-dessous? s'il vous plat laissez-moi savoir la procdure
tape par tape. Nous avons vrifi Cbles JL, Relais, remplacer la carte CDC etc laissons plus nous savons
sur la faon de rsoudre. D10- <s> DCC DPM: pas de mmoire BMS pour isr D7- <s> DCC incapable
d'obtenir DPM tampon pour Xmit D2 - <s> DCC-BMS de mmoire D9- <s> DCC DPM invalides adresse
de destination erreurs de CDC trouv 20028 et augmentait 1708 <S> TCE1 bouclage relais, PTR1 1698
<S> TCE1 TMR vrifier difficult, PTR1 1354 <S > pilote TCQA PTR1relay RD2 chec 1698 <T> TCE1
TMR vrifier difficult, PTR1 1698 <R> TCE1 TMR vrifier difficult, PTR1 2344 <S> lecteurs
dcalage, <S> L4PTR1 FB merci l'avance. rvsssrao

Rpondre ce poste ...

Publi par markvguy le 6 Dcembre 2006 - 20:21
Ce problme est-survenant aprs un incident ou aprs une autre carte dans <S> a t remplac (comme la
LCC / SLCC ou la carte TCQC)? > partir du deuxime groupe de Diag. Alarmes, il semble que <S> a
dcid de ne pas participer la gestion de la turbine, de manire efficace, vous n'avez qu' l'lecteur
dsign (habituellement <R>) contrle l'appareil quand il est en marche .... Il est prsum que <S> est I /
O Statut A7 en tout temps pendant que cela se produise. Avez-vous utilis le clavier d'affichage / SLCC la
LCC pour vrifier l'tat des E / S des cartes <S> et associ <S>? (Rechercher control.com des
explications sur la faon d'utiliser le clavier / SLCC LCC pour vrifier Etat E / S de cartes
individuelles.) Le premier groupe de diagnostic alarmes se produit gnralement lorsque soit il ya trop de
demandes tant constitu d'un processeur ou quand il est un problme avec la configuration des demandes
ou quand il ya un problme avec le cblage de communication ou si il ya un problme avec le matriel
("Berg") Les paramtres des cavaliers soit la LCC / SLCC et / ou les cartes DCC / SDCC. moins d'une
routine viewn qui demande beaucoup d'informations partir de <S> processeur tout le temps, la premire
ne semble pas trop probable - sauf s'il ya quelque chose que vous ne nous dites pas. Comme, est-ce sur un
panneau LM Mark V ??? Comme il serait probablement seulement que l'un des autres processeurs (<R>,
<T>, <C>) qui serait la configuration de la demande de <S>, Cela ne me parat pas comme si c'tait la
cause du problme, que ce soit. Si les demandes de donnes qui n'existaient pas un emplacement de
mmoire particulier ont t faits, cela pourrait aussi causer le problme - mais il semblerait que ce serait
produire sur chaque processeur. L'DENET (Data Exchange Network) est la manire dont les processeurs de
contrle et <C> communiquer. S'il y avait un problme avec le DENET ou le cblage ou les cartes travers
lequel le DENET passe, cela peut entraner des problmes similaires ceux que vous
rencontrez. L'acheminement de l'DENET est une sorte de vague, mais comprend la carte TCQC (le cble
VARC) et la carte LCC / de SLCC. C'est concevable qu'il y est un matriel (Berg) tablissant cavalier
question - avez-vous confirm que tous les les cavaliers sur les LCC / SLCC, DCC / cartes SDCC <R> et
<S> et <T> correspondent les uns des autres? Vous devriez galement vrifier les connecteurs de cble
varc et ARCPL sur la carte TCQC de <S> et la carte LCC / de SLCC de <S> (voir les signaux Schmas de
l'annexe D du Manuel, GEH-6195 Mk V application, la dessin intitul "Q <> de base -. deNet et Bunet
Connexions sur TCQC Conseil Terminal" .. vous dites que vous avez remplac la carte CDC, ce qui devrait
tre pas le problme, essayez de remplacer la carte LCC, la carte de TCQC Plusieurs fois ces nuisances
Diag. alarmes ne provoquent pas de problme avec l'excution de l'unit, mais si votre message est bien
compris et vous avez toutes les alarmes Diag. vous avez inscrit dans le poste en mme temps, alors il est
certainement quelque chose qui est l'origine < S> de ne pas participer la gestion (et la protection) de
l'unit, et vous avez raison de vouloir faire corriger. C'est vraiment difficile de vous dire exactement
comment procder, puisque nous ne savons pas exactement ce qui a prcd cette condition et ce que tout
qui a t fait. Et quand quelqu'un dit they.ve fait ceci ou cela, etc, il est difficile de savoir exactement ce qui
a t fait et comment cela a t fait. Il ya une TIL (Lettre d'information technique) au sujet avec de la
graisse conductrice sur les connecteurs des cartes de Mk V panneaux de commande de turbine. Il est
concevable qu'il y ait une connexion haute rsistance l'un des connecteurs qui est l'origine d'un
problme. Il serait ncessaire d'arrter de le faire, mais avez-vous avez-vous utilis la graisse conductrice
lorsque vous avez remplac la carte CDC? Avez-vous essay de remettre en place et dtrner les
connecteurs varc et ARCPL? (Encore une fois - faire uniquement avec l'appareil teint et <S> teint) Vous
pouvez toujours consulter l'OEM / conditionneur pour plus d'aide / assistance. Si vous avez un appareil GE-
emballs, vous pourriez tre en mesure de convaincre votre reprsentant du service la clientle locale
pour ouvrir un CCP (alimentation du Centre de rponse) cas pour vous.Faites-nous savoir ce que vous
dcouvrez! markvguy


> Ce problme at-il commenc survenant aprs un incident ou aprs une autre carte dans <S> a t
remplac (comme la LCC / SLCC ou la carte TCQC)? ANS: NO .STARTED SUDDENLY.SOME
CALME quelques mois NO CDC ALARMES PARAISSAIENT. > > > A partir du second groupe de
Diag. Alarmes, il semble que <S> a dcid de ne pas participer la gestion de la turbine, de manire
efficace, vous n'avez qu' l'lecteur dsign (habituellement <R>) contrle l'appareil quand il est en marche
.... > > Il est prsum que < S> est I / O Statut A7 en tout temps pendant que cela se produise. Avez-vous
utilis le clavier d'affichage / SLCC la LCC pour vrifier l'tat des E / S des cartes <S> et associ
<S>? (Rechercher control.com des explications sur la faon d'utiliser le clavier / SLCC LCC pour vrifier
Etat E / S de cartes individuelles.) ANS: ENREGISTRS STATUT toutes les cartes. MONTRER A7. > Le
premier groupe de diagnostic alarmes se produit gnralement lorsque soit il ya trop de demandes tant
constitu d'un processeur ou quand il ya un problme avec la configuration des demandes ou quand il ya un
problme avec le cblage de communication ou s'il ya un problme avec le matriel ("Berg") Les
paramtres des cavaliers soit la LCC / SLCC et / ou le DCC / cartes SDCC. ANS: Alors, comment vrifier
la circulation dans les nuds de communication.> moins d'une routine viewn qui demande pour un grand
nombre d'informations de <S> processeur tout le temps, la premire ne semble pas trop probable - sauf s'il
ya quelque chose que vous ne nous dites pas. Comme, est-ce sur un panneau LM Mark V ??? ANS:
Normalement, nous recueillent des donnes viewn FROM <S> DE TOUS GT
PROCESSORS.PRESENTLY pas dclench si la machine fonctionne. > > Comme il serait probablement
seulement que l'un des les autres processeurs (<R>, <T>, <C>) qui serait la configuration des demandes de
<S>, si cela ne semble pas comme si c'tait la cause du problme, que ce soit. ANS: SO Comment
vrifier. O VOIR. > Si les demandes de donnes qui n'existaient pas un emplacement de mmoire
particulier ont t faits, cela pourrait aussi causer le problme - mais il semblerait qu'il se produirait sur
chaque processeur. > > Le DENET (donnes Rseau d'change) est de savoir comment les processeurs de
contrle et <C> communiquer. S'il y avait un problme avec le DENET ou le cblage ou les cartes travers
lequel le DENET passe, cela peut entraner des problmes similaires ceux que vous
rencontrez.L'acheminement de l'DENET est une sorte de vague, mais comprend la carte TCQC (le cble
VARC) et la carte LCC / de SLCC. > > Il est concevable qu'il y ait un matriel (Berg) tablissant
cavalier question - avez-vous confirm que tous les cavaliers de matriel sur les LCC / SLCC, DCC / cartes
SDCC <R> et <S> et <T> correspondent les uns des autres? Vous devriez galement vrifier les
connecteurs de cble varc et ARCPL sur la carte TCQC de <S> et la carte LCC / de SLCC de <S> (voir les
signaux Schmas de l'annexe D du Manuel, GEH-6195 Mk V application, la dessin intitul "<Q> de base -.
deNet et Bunet Connexions bord TCQC Terminal" > > Vous dites que vous avez remplac la carte CDC,
ce qui devrait tre pas le problme, essayez de remplacer la carte LCC, la carte de TCQC.. > > Plusieurs
fois, ces nuisances Diag. alarmes ne provoquent pas de problme avec l'excution de l'unit, mais si votre
message est bien compris et vous avez toutes les alarmes Diag. vous avez inscrit dans le poste en mme
temps, alors il est certainement quelque chose qui est l'origine <S> de ne pas participer la gestion (et la
protection) de l'unit, et vous avez raison de vouloir faire corriger. ANS: MAIS NOUS 1 COURT DE
NUISANCES TRIP. > Il est vraiment difficile de vous dire exactement comment procder , puisque nous
ne savons pas exactement ce qui a prcd cette condition et ce que tout a t fait. Et quand quelqu'un dit
they.ve fait ceci ou cela, etc, il est difficile de savoir exactement ce qui a t fait et comment cela a t
fait. > > Il ya une TIL (Lettre d'information technique) au sujet avec de la graisse conductrice sur les
connecteurs des cartes dans Mk V panneaux de commande de turbine. Il est concevable qu'il y ait une
connexion haute rsistance l'un des connecteurs qui est l'origine d'un problme. Il serait ncessaire
d'arrter de le faire, mais avez-vous avez-vous utilis la graisse conductrice lorsque vous avez remplac la
carte CDC? Avez-vous essay dtrner et de remettre en place les connecteurs varc et ARCPL (encore une
fois - faire uniquement avec l'appareil teint et <S> teint!)? ANS: GRAISSE n'a pas t utilis. > Vous
pouvez toujours consulter l'OEM / conditionneur pour plus d'aide / assistance. Si vous avez un appareil GE-
emballs, vous pourriez tre en mesure de convaincre votre reprsentant du service la clientle locale
pour ouvrir un CCP (alimentation du Centre de rponse) de cas pour vous. > > Faites-nous savoir ce que
vous dcouvrez! > markvguy


Une grande partie de la premire rponse tait sorte de rflexion sur html", sorte de passer par une liste de
contrle mental de ce qui pourrait causer des problmes. Malheureusement, les concepteurs de la Mk V ne
fournissent pas beaucoup de la manire de capacits de dpannage internes, si facilement vrifier pour le
trafic DENET n'est pas possible. En fait, le dpannage oprations internes est difficile, mme pour le
personnel de l'usine de GE, car il n'y a pas beaucoup de possibilits d'obtenir des donnes de
fonctionnement interne et il n'y a pas beaucoup d'ingnieurs laiss familier avec les oprations internes Mk
V de contrle de la turbine. L'une des premires questions poser ici est: Avez-vous s ou GE Mark V
IHM? Si vous avez des IHM, avez-vous toujours eu IHM ou ont-ils t rcemment achet / install - avec
le nouveau PROMset (s) ??? ? Avez-vous mis en uvre TIL-1480 R2 , il est trs intressant de noter que
les problmes ne sont actuellement constats sur les <S > et que <S> est "interrog" en utilisant l'un des
outils viewn.!.?.! Quel outil viewn (s) utilisez-vous pour collecter des donnes? Utilisez-vous un fichier la
liste des points recueillir par l'outil viewn? Si oui, pouvez-vous copier le fichier PointList une
rponse? Utilisez-vous un fichier batch pour excuter l'outil viewn? Si c'est le cas, ne l'utilit viewn gnrer
une "alerte" quand il est lanc par le fichier batch? quel taux est les donnes recueillies avec l'outil
viewn? S'il vous plat la liste l'entre de ligne de commande qui est utilis pour dmarrer l'outil
viewn? Quand avez-vous commencer utiliser viewn recueillir des donnes auprs des <S>
processeurs? Avez-vous apport des modifications la View2 fichier de donnes / de routine l'poque les
erreurs de CDC ont commenc? Qu'est-ce qui se passe lorsque vous effacez les erreurs de systme de
clavier d'affichage de la LCC lorsque l'utilitaire viewn n'est PAS en cours d'excution? (Pour les erreurs de
systme claires en utilisant le clavier du LCC d'affichage, appuyez sur DCC sur le clavier de l'cran de
LCC; '186 MONITOR devrait apparatre l'cran Appuyez sur INC jusqu' ce que' Effacer les erreurs
SYS" est affich l'cran, puis appuyez sur ENTRE presse INC nouveau.. jusqu' ce que 'Effacer les
erreurs SYS "est affich l'cran et appuyez sur ENTRER de nouveau Si le numro indiqu est 0, des
erreurs ont t effacs et rinitialiss;. si le nombre est petit ou incrmente pendant que vous regardez il, les
erreurs n'ont pas t effac. Appuyez sur NORM pour revenir l'affichage par dfaut, ou l'affichage revient
l'affichage par dfaut aprs une brve priode de temps.) Vous semblez dire qu'il ya des priodes o les
alarmes ne s'affichent pas, puis ils commencent soudainement rapparaisse. Est-ce exact? Avez-vous
essay de remplacer la carte LCC? Encore une fois, il est trs difficile de dire comment procder car il est
trs difficile de savoir ce qui a t fait, ce qui se fait, et comment les choses ont t faites. Ne prenez pas
infraction l'; est dtect que vous tes un peu frustr par les rponses que vous obtenez, mais vous devez
savoir qu'il ya beaucoup de sites qui connaissent les mmes problmes que vous et ils courent trs bien jour
aprs jour - et mme GE n ' t savent exactement quoi faire pour rsoudre le problme (s). Vous avez trouv
l'aide d'un forum libre - si vous payez pour ce conseil, vous pourriez avoir un reproche lgitime. vous tes
commentaire au sujet d'tre "... 1 court de dclenchement intempestif ..." est compltement
droutant.Malheureusement, raison de l'absence d'outils de dpannage pour les problmes de ce genre, cela
se rsume assez souvent la (rpugnant) tche d'change de cartes ... Il est recommand que vous arrtez
l'appareil vers le bas, mettez le <S> processeur, dtrner ( dbrancher) tous les cbles un la fois et avant
de les rebrancher dans l'application de la graisse conductrice recommand aux bornes (vous pouvez
gnralement trouver graisse conductrice emball dans des botes avec de rechange imprim des cartes de
circuits imprims; GE a commenc livrer la graisse dans la fin des annes 1990 avec toutes les cartes
vendues comme pices de rechange ou de remplacement de rparation et de rendement), puis remettre en
place les cbles. Cela devrait tre fait sur tous les cbles de la carte de LCC, la carte CDC, et la carte de
TCQC -. Particulier les cbles marqus VARC et / ou ARCPL Soyez sr de faire attention l'orientation
des cbles sur la carte LCC, en particulier les cbles fixs aux connecteurs en bas de la carte. Aussi, soyez
particulirement prudent avec le cble de 3PL qui relie la carte LCC, la carte CDC, et la TCQA (et TCQB,
si quip). Les cbles 3PL n'a pas tirettes et il peut tre trs facilement endommags si pas tir lche trs
soigneusement et remis en place en appuyant fermement tout au long de la nervure suprieure du
connecteur! Si cela ne rsout pas le problme, essayez de remplacer le LCC carte. L'auteur croit qu'il ya
une certaine "caractristique" de certaines rvisions PROM Mk V qui, lorsqu'il est activ par une demande
mal forme des donnes ou des donnes qui qui n'existe pas ou pour les donnes un taux excessif
provoque la DPM ( tampons et la manipulation des routines mmoire mmoire double accs mmoire) et
associs tre corrompus, parfois au-del "rparation". Dans la plupart des cas, ces alarmes sont nuisibles
et ne nuisent pas l'opration de l'unit (encore une fois, si un sondage de Mk V oprateurs / techniciens a
t prise, il serait sans doute rvler que quelque part entre 30 et 40% des panneaux exposition !. ce
comportement de faon intermittente ou continue ... triste, mais vrai) Qu'est-ce que c'est troublant dans
votre cas est les ptr1 Commentaires chauds et pilote de relais alarmes de dfaillance, qui indiquent des
problmes plus graves - peut-tre (probablement) pas mme li aux erreurs de LCC . C'est l'une des
difficults de faire face ce genre de questions qui ont exist pendant une certaine priode de temps avant
que quelque chose se passe qui pousse les gens prendre connaissance et commencer "rapporter" choses
sans rapport. Comprendre et dpannage Mk V Les oprations internes et de diagnostic Alarmes prend un
peu de patience et d'exprience sur le tas.Et, il a t dit plusieurs fois auparavant - TOUTE processus ou
alarme de diagnostic doit tre dpann et rsolu aussi vite qu'il est annonc. Ne pas le faire peut causer
d'normes quantits de temps et d'efforts pour tre gaspills; prendre de l'exprience. markvguy


ANS (RVSSSRAO):. Nous avons IHM DEPUIS machines ont t mis en service en 2003
>
> Avez-vous mis en uvre TIL-1480 R2? ANS (RVSSSRAO):. TIL 1480 R2 t implante, mais Alarmes
de diagnostic MME SUITE > Il est trs intressant de noter que les problmes ne sont tant connu sur
<S>, et que <S> est "interrog" en utilisant l'un des outils viewn.!.?.! > ANS (RVSSSRAO): Nous
collectons des VIEW 2 DONNEES DE REFERENCE BUT & donnes sont recueillies auprs <S > CORE
UNIQUEMENT. Nous avons 6 GT'S & POUR TOUS GT'S Nous recueillons des donnes de <S>
CORE. MAIS NOUS AVONS messages de diagnostic d'<S> DE L'UN DE NOS GT'S. > Quel outil (s)
viewn utilisez-vous pour collecter des donnes? > ANS (RVSSSRAO), nous utilisons VUE 2 DOSSIER
POUR LA COLLECTE DE DONNES. > Utilisez-vous un fichier Liste des points recueillir par l'outil
viewn? Si oui, pouvez-vous copier le fichier PointList une rponse? > ANS (RVSSSRAO):. nous crons
un fichier avec la liste des points RECUEILLIS > Utilisez-vous un fichier batch pour excuter l'outil
viewn? Si c'est le cas, ne l'utilit viewn gnrer une "alerte" quand il est lanc par le fichier batch? > ANS
(RVSSSRAO): nous courons fichier batch pour collecter des donnes. > A quel taux est les donnes
recueillies avec l'outil viewn? ? S'il vous plat numrer l'entre de ligne de commande qui est utilis pour
dmarrer l'outil viewn ANS (RVSSSRAO): 1 chantillon par minute pour 50 POINTSMAXIMUM. >
Quand avez-vous commencer utiliser viewn recueillir des donnes auprs des <S> processeurs? ? Avez-
vous fait des modifications apportes au fichier de donnes de View2 / routine l'poque les erreurs CDC a
commenc > ANS (RVSSSRAO): Nous utilisons VUE 2 DOSSIER QUAND NOUS FAISONS
changement de combustible SEULEMENT OU PENDANT LES ESSAIS DE PERFORMANCE ETC.NO
activit a t fait rcemment ON View2 FICHIER. > Qu'est-ce qui se passe lorsque vous effacez les erreurs
de systme de clavier d'affichage de la LCC lorsque l'utilitaire viewn n'est PAS en cours d'excution? (Pour
les erreurs de systme claires en utilisant le clavier du LCC d'affichage, appuyez sur DCC sur le clavier de
l'cran de LCC; '186 MONITOR devrait apparatre l'cran Appuyez sur INC jusqu' ce que' Effacer les
erreurs SYS" est affich l'cran, puis appuyez sur ENTRE presse INC nouveau.. jusqu' ce que 'Effacer
les erreurs SYS "est affich l'cran et appuyez sur ENTRER de nouveau Si le numro indiqu est 0, des
erreurs ont t effacs et rinitialiss;. si le nombre est petit ou incrmente pendant que vous regardez il, les
erreurs n'ont pas t . autoris Appuyez sur NORM pour revenir l'affichage par dfaut, ou l'affichage
revient l'affichage par dfaut aprs une brve priode de temps). ANS (RVSSSRAO): Mme aprs avoir
Rinitialisation des alarmes augmentent continuellement lorsque la vue 2 fichier n'est pas RUNNING.WE
DO la mme procdure pour l'effacement des alarmes DE LCC. > Vous semblez dire qu'il ya des priodes
o les alarmes n'apparaissent pas, puis ils commencent soudainement apparatre de nouveau. Est-ce
exact? > ANS (RVSSSRAO): pendant 3-4 mois partir de maintenant n'ont dclench aucune alarme
EXISTANT .SUDDENLY PENDANT Maintence Nous avons teint ENTIER MARK V PANNEAU
D'ALIMENTATION & SICE puis il a commenc. > Avez-vous essay de remplacer la carte LCC? ANS
(RVSSSRAO): OUI > Encore une fois, il est trs difficile de dire comment procder car il est trs difficile
de savoir ce qui a t fait, ce qui se fait, et comment les choses ont t faites. Ne prenez pas infraction
l'; est dtect que vous tes un peu frustr par les rponses que vous obtenez, mais vous devez savoir qu'il
ya beaucoup de sites qui connaissent les mmes problmes que vous et ils courent trs bien jour aprs jour -
et mme GE n ' t savent exactement quoi faire pour rsoudre le problme (s). Vous avez trouv l'aide d'un
forum libre -. Si vous payez pour ce conseil, vous pourriez avoir un reproche lgitime > > Vous tes
commentaire au sujet d'tre "... 1 court de dclenchement intempestif ..." est compltement droutant. > >
Malheureusement, en raison de l'absence d'outils de dpannage pour les problmes de ce genre, cela se
rsume assez souvent l'(rpugnant) tche d'change de cartes ... > > Il est recommand que vous arrtez
l'appareil vers le bas, mettez le < S> processeur, renverser (dbrancher) tous les cbles un la fois et avant
de les rebrancher dans l'application de la graisse conductrice recommand aux bornes (vous pouvez
gnralement trouver graisse conductrice emball dans des botes avec de rechange cartes de circuits
imprims; GE a commenc livrer l' de la graisse la fin des annes 1990 avec toutes les cartes vendues
comme pices de rechange ou de remplacement de rparation et de rendement), puis remettre en place les
cbles. Cela devrait tre fait sur tous les cbles de la carte de LCC, la carte CDC, et la carte de TCQC - en
particulier les cbles marqus VARC et / ou ARCPL. ANS (RVSSSRAO): Nous allons le faire, mais
DIFFICILE POUR RETIRER LA PRISE ds que la graisse a t applique. > Assurez-vous de faire
attention l'orientation des cbles sur la carte LCC, en particulier les cbles relis aux connecteurs en bas
de la carte. Aussi, soyez particulirement prudent avec le cble de 3PL qui relie la carte LCC, la carte CDC,
et la TCQA (et TCQB, si quip). Les cbles 3PL n'a pas tirettes et il peut tre trs facilement endommags
si pas tir lche trs soigneusement et remis en place en appuyant fermement tout au long de la nervure
suprieure du connecteur! > > Si cela ne rsout pas le problme, essayez de remplacer le la carte de
LCC. > > L'auteur croit qu'il ya une certaine "caractristique" de certaines rvisions PROM Mk V qui,
lorsqu'il est activ par une demande mal forme des donnes ou des donnes qui qui n'existe pas ou pour
les donnes un taux excessif provoque la DPM (double accs mmoire) et les tampons de mmoire
associs et la manipulation des routines de mmoire pour tre corrompus, parfois au-del
"rparation". Dans la plupart des cas, ces alarmes sont nuisibles et ne nuisent pas l'opration de l'unit
(encore une fois, si un sondage de Mk V oprateurs / techniciens a t prise, il serait sans doute rvler que
quelque part entre 30 et 40% des panneaux exposition ce comportement de faon intermittente ou continue
... triste, mais vrai!). > > Quoi de troublant dans votre cas est les ptr1 Commentaires chauds et pilote de
relais alarmes de dfaillance, qui indiquent des problmes plus graves - peut-tre (probablement) pas mme
li la erreurs de LCC. C'est l'une des difficults de faire face ce genre de questions qui ont exist
pendant une certaine priode de temps avant que quelque chose se passe qui pousse les gens prendre
connaissance et commencer "rapporter" choses sans rapport. Comprendre et dpannage Mk V Les
oprations internes et de diagnostic Alarmes prend un peu de patience et d'exprience sur le tas. Et, il a t
dit plusieurs fois auparavant - TOUTE processus ou alarme de diagnostic doit tre dpann et rsolu aussi
vite qu'il est annonc. Ne pas le faire peut causer d'normes quantits de temps et d'efforts pour tre
gaspills; prendre de l'exprience. ANS (RVSSSRAO):. QU'EST-CE doivent tre vrifis POUR PTR1
PROBLME MERCI DE CONSEILS ET SUGGESTIONS.


Une chose que vous devez savoir sur les serveurs GE Mark V IHM par rapport s: Ils gnrent
beaucoup plus de trafic sur le StageLink que s - beaucoup plus! Et c'est mme avant que l'on
commence l'excution des programmes viewn pour la collecte des donnes. (Un serveur IHM est une IHM
avec une carte de ARCnet qui communique avec Mk V panneau (s) de contrle de la turbine sur le
StageLink.) Un ne demande que des donnes pour les points qui sont configurs pour apparatre sur
l'cran qui est actuellement en cours de affiches sur l'cran -. ainsi que toute MODBUS ou GSM (Drive
Systems GE standard Message Protocol) points, si le est configur pour l'une de ces options de
communication Un serveur GE Mark V HMI est TOUJOURS demande pour chaque point configur dans
la base de donnes de point de CIMPLICITY qui est chaque point de chaque cran - et si c'est un multi-
unit GE Mark V Serveur IHM, ainsi c'est demander cette information pour chaque unit communique
avec! (On pense que c'est la raison pour laquelle GE a tabli une "limite" de pas plus de deux GE Marquer
les serveurs V IHM demandant des donnes partir d'un seul panneau de commande de turbine Mk
V). Soit dit en passant - le nombre de serveurs GE Mark V IHM demandent pour les donnes partir du
panneau de commande de turbine Mk V qui a des problmes avec la <S> processeur? (Un serveur GE
Mark V HMI Il ne devrait pas tre en augmentation de retirer les connecteurs lorsque graisse conductrice
est applique;. il est non-durcissement et "gras" (c'est--glissante) et devrait effectivement faire enlever les
connecteurs plus facile Il y avait gnralement une information . fiche emball avec les tubes de graisse
conductrice sur la faon d'appliquer la graisse Encore une fois, plusieurs fois rsoudre un problme comme
celui-ci revient remplacer les cartes, cet auteur a horreur du dpannage de cette faon, mais parfois il
n'y a pas d'autre moyen Encore une fois,. cet auteur sait de nombreux sites qui rencontrent ce mme
problme, n'ont mme jamais essay de rsoudre le problme, et ont connu aucun problme en essayant de
dmarrer ou faire fonctionner les units.!.?.!.? C'est l'un des mystres de la Mk V . " Une chose
intressante qui peut tre fait est d'changer des cartes entre les processeurs et voir si le problme suit la
carte. Par exemple, prendre la CDC de <S> et changer avec l'un de <R>, faire les configurations
appropries et Tlchargements aprs mise sous tension de, re-dmarrage et si le problme commence se
produire <R> et pas dans <S>, alors le problme est la carte CDC. Vous pouvez faire de mme avec la
carte de LCC. Si le problme reste dans <S>, alors il peut tre un cble / problme de connexion. VARC ou
ARCPL markvguy


Nous avons 6 GT de individuelle avec HMI et systme de commande nos locaux et 3. de multi-
utilisateurs sous licence HMI salle de commande principale (2 pour <D> de base et 1 pour <C> de
base) tous sont relis en mode de guirlande avec un cble de fibre optique via MOD HUB.for tous les GT
de nous collectons des donnes de <S> ordinateur. Quel est ce qu'il VARC ou ARCPL cble /
connecteur. Merci pour la rponse l'avance.


> Du 9 paragraphe de la premire rponse, "... se rfrer aux diagrammes de flux de signaux l'annexe D
du Manuel, GEH-6195 Mk V application, le dessin intitul" Q <> de base - deNet et Bunet Connexions sur
TCQC Terminal Conseil .... " markvguy

Publi par RVSSSRAO le 14 Fvrier, 2007 - 22:24
Cher Mark V Guy, Nous avons eu l'occasion de faire un pas en avant dans la ralisation du diagnostic en
outre dans la rsolution de la <S> Erreurs de base DCC. Nous avons forc certains signaux comme
L4_XTP, L20 FG1X ETC pour vrifier l'tat des relais TCTG carte. Nous avons trouv k14 relais pas de
mise en route. Donc, nous avons vrifi le cble de TCQA carte de <S> noyau de TCTG carte. Nous
repalced le cble et constat aucun changement de statut. Donc trouver conclu que TCQA carte est
dfectueuse. Donc, nous avons remplac la carte.Actuellement, aucune alarme de diagnostic sont apparus
jusqu' prsent. Machine a t repris en service deux jours en arrire. Il est gard en observation. Toute
autre mesure ne sera laiss entendre de vous. Merci pour votre action et un soutien continu. rvsssrao


Publi par markvguy le 15 Fvrier, 2007 - 23:20
Flicitations pour trouver le problme, et merci pour les commentaires! Il aide tout le monde qui lit les
messages et ont ou peuvent avoir des problmes identiques ou similaires. Merci aussi pour les dtails de la
rsolution des problmes; ils sont aussi trs utiles cet auteur et d'autres, aussi. markvguy

Publi par RAM le 12 Dcembre 2006 - 15:53
Salut, Trs trs intressant et conseils de dpannage, esprons que cela aidera d'autres personnes
aussi. Dans ce contexte, il est une phrase particulier, je ne suis pas en mesure de comprendre: Comme il
serait probablement seulement que l'un des autres processeurs (<R>, <T>, <> C) qui serait la configuration
des demandes de <S>, si cela ne semble pas comme si c'tait la cause du problme, que ce soit. " Voulez-
vous s'il vous plat expliquer le sens de cette phrase? Cordialement, RAM


Il est prsum que <R>, <S>, l'information <T> et <C> demande de l'autre au dbut de la trame. En
pensant , il semble que si les demandes de <S> ont t mal forms par un processeur, ils seraient mal
forms aux autres processeurs, qui se plaindraient de mme. C'est de la pure spculation, mais il ne semble
pas illogique. Le systme d'exploitation interne de la Mk V n'est pas document et il n'y a pas de moyen
pratique pour observer les demandes sur DENET (Data Exchange Network). Encore une fois, la grande
majorit est juste "une rflexion sur html" en essayant de tirer logiquement que l' . problme pourrait
tre Cet auteur a vu plusieurs cas de processeurs individuels tant aliment vers le bas, puis
inexplicablement mauvais comportement lors de la mise en place - en particulier lorsque le disjoncteur
principal alimentant l'ensemble du panneau est utilis pour teindre les processeurs et pouvoir les remettre
en place tout en mme temps. Ou, lorsque l'interrupteur dans le <PD> noyau est recycl trs
rapidement. Parfois, il suffit de mettre hors tension pendant une minute ou deux avec l'interrupteur dans le
<PD> noyau va rsoudre le problme; . parfois, il ne sera pas C'est une pratique qui est assez frquent dans
les cours de formation Mk V - quand il n'y a aucune entre ou sortie connects la centrale, et quand ils
sont aliments par des convertisseurs AC-DC avec une capacit de courant de sortie limit. Sur le terrain,
Mk Vs sont gnralement aliments par piles nominales 125 VDC avec sortie courant trs lev surtout
dans le cadre d'un disjoncteur de 50A, et les chargeurs avec sorties de courant levs relis la batterie. Cet
auteur n'a jamais tolr la pratique de re-dmarrage d'un panneau entier avec le disjoncteur principal, mme
en cours de formation.Et ce que les gens voient en classe, ils portent habituellement retourner sur le terrain
.... Il sera intressant de savoir comment le panneau Mk V a t mis hors tension. markvguy

Mark V DCCC Alarms

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Mark V DCCC Alarms

Încărcat de

Drepturi de autor:

Formate disponibile

Mark V DCCC Alarms

Posted by RVSSSRAO on 6 December, 2006 - 12:30 am

S-ar putea să vă placă și