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.rvsssraoReply 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.

http://www.control.com/topic/58

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!

markvguyReply to this post...

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!> markvguyReply to this post...


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.


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.Reply to this post...


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.


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.Reply to this post...

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...."


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.

rvsssraoReply to this post...

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.


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,RAMReply to this post...


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.


Marquer V DCCC Alarmes

Publié par RVSSSRAO le 6 Décembre 2006 - 00:30

Nous avons beaucoup d'erreurs de plus en plus en continu CDC dans <S> de base du système de contrôle V-Marc. Comment procéder avec des alarmes ci-dessous? s'il vous plaît laissez-moi savoir la procédure étape par étape. Nous avons vérifié Câbles JL, Relais, remplacer la carte CDC etc laissons plus nous savons sur la façon de résoudre. D10- <s> DCC DPM: pas de mémoire BMS pour isr D7- <s> DCC incapable d'obtenir DPM tampon pour Xmit D2 - <s> DCC-BMS de mémoire 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 vérifier difficulté, PTR1 1354 <S > pilote TCQA PTR1relay RD2 échec 1698 <T> TCE1 TMR vérifier difficulté, PTR1 1698 <R> TCE1 TMR vérifier difficulté, PTR1 2344 <S> électeurs décalage, <S> L4PTR1 FB merci à l'avance. rvsssrao

http://www.control.com/topic/58

Répondre à ce poste ...

Publié par markvguy le 6 Décembre 2006 - 20:21

Ce problème est-survenant après un incident ou après une autre carte dans <S> a été remplacé (comme la LCC / SLCC ou la carte TCQC)? > À partir du deuxième groupe de Diag. Alarmes, il semble que <S> a décidé de ne pas participer à la gestion de la turbine, de manière efficace, vous n'avez qu'à l'électeur désigné (habituellement <R>) contrôle l'appareil quand il est en marche .... Il est présumé 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 vérifier l'état des E / S des cartes <S> et associé à <S>? (Rechercher control.com des explications sur la façon d'utiliser le clavier / SLCC LCC pour vérifier Etat E / S de cartes individuelles.) Le premier groupe de diagnostic alarmes se produit généralement lorsque soit il ya trop de demandes étant constitué d'un processeur ou quand il est un problème avec la configuration des demandes ou quand il ya un problème avec le câblage de communication ou si il ya un problème avec le matériel ("Berg") Les paramètres 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 première 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 paraît pas comme si c'était la cause du problème, que ce soit. Si les demandes de données qui n'existaient pas à un emplacement de mémoire particulier ont été faits, cela pourrait aussi causer le problème - mais il semblerait que ce serait produire sur chaque processeur. L'DENET (Data Exchange Network) est la manière dont les processeurs de contrôle et <C> communiquer. S'il y avait un problème avec le DENET ou le câblage ou les cartes à travers lequel le DENET passe, cela peut entraîner des problèmes similaires à ceux que vous rencontrez. L'acheminement de l'DENET est une sorte de vague, mais comprend la carte TCQC (le câble VARC) et la carte LCC / de SLCC. C'est concevable qu'il y est un matériel («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 vérifier les connecteurs de câble varc et ARCPL sur la carte TCQC de <S> et la carte LCC / de SLCC de <S> (voir les signaux Schémas 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 problème, essayez de remplacer la carte LCC, la carte de TCQC Plusieurs fois ces nuisances Diag. alarmes ne provoquent pas de problème avec l'exécution de l'unité, mais si votre message est bien compris et vous avez toutes les alarmes Diag. vous avez inscrit dans le poste en même 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 procéder, puisque nous ne savons pas exactement ce qui a précédé 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 résistance à l'un des connecteurs qui est à l'origine d'un problème. Il serait nécessaire d'arrêter 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 détrôner 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-emballés, vous pourriez être en mesure de convaincre votre représentant du service à la clientèle locale pour ouvrir un CCP (alimentation du Centre de réponse) cas pour vous.Faites-nous savoir ce que vous découvrez! markvguy



> Ce problème at-il commencé survenant après un incident ou après 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 décidé de ne pas participer à la gestion de la turbine, de manière efficace, vous n'avez qu'à l'électeur désigné (habituellement <R>) contrôle l'appareil quand il est en marche .... > > Il est présumé 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 vérifier l'état des E / S des cartes <S> et associé à <S>? (Rechercher control.com des explications sur la façon d'utiliser le clavier / SLCC LCC pour vérifier Etat E / S de cartes individuelles.) ANS: ENREGISTRÉS STATUT toutes les cartes. MONTRER A7. > Le premier groupe de diagnostic alarmes se produit généralement lorsque soit il ya trop de demandes étant constitué d'un processeur ou quand il ya un problème avec la configuration des demandes ou quand il ya un problème avec le câblage de communication ou s'il ya un problème avec le matériel ("Berg") Les paramètres des cavaliers soit la LCC / SLCC et / ou le DCC / cartes SDCC. ANS: Alors, comment vérifier la circulation dans les nœuds de communication.> À moins d'une routine viewn qui demande pour un grand nombre d'informations de <S> processeur tout le temps, la première 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 données viewn FROM <S> DE TOUS GT PROCESSORS.PRESENTLY pas déclenché 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 problème, que ce soit. ANS: SO Comment vérifier. OÙ VOIR. > Si les demandes de données qui n'existaient pas à un emplacement de mémoire particulier ont été faits, cela pourrait aussi causer le problème - mais il semblerait qu'il se produirait sur chaque processeur. > > Le DENET (données Réseau d'échange) est de savoir comment les processeurs de contrôle et <C> communiquer. S'il y avait un problème avec le DENET ou le câblage ou les cartes à travers lequel le DENET passe, cela peut entraîner des problèmes similaires à ceux que vous

rencontrez.L'acheminement de l'DENET est une sorte de vague, mais comprend la carte TCQC (le câble VARC) et la carte LCC / de SLCC. > > Il est concevable qu'il y ait un matériel («Berg») établissant cavalier question - avez-vous confirmé que tous les cavaliers de matériel sur les LCC / SLCC, DCC / cartes SDCC à <R> et <S> et <T> correspondent les uns des autres? Vous devriez également vérifier les connecteurs de câble varc et ARCPL sur la carte TCQC de <S> et la carte LCC / de SLCC de <S> (voir les signaux Schémas 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 problème, essayez de remplacer la carte LCC, la carte de TCQC.. > > Plusieurs fois, ces nuisances Diag. alarmes ne provoquent pas de problème avec l'exécution de l'unité, mais si votre message est bien compris et vous avez toutes les alarmes Diag. vous avez inscrit dans le poste en même 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 procéder , puisque nous ne savons pas exactement ce qui a précédé 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 résistance à l'un des connecteurs qui est à l'origine d'un problème. Il serait nécessaire d'arrêter de le faire, mais avez-vous avez-vous utilisé la graisse conductrice lorsque vous avez remplacé la carte CDC? Avez-vous essayé détrôner 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-emballés, vous pourriez être en mesure de convaincre votre représentant du service à la clientèle locale pour ouvrir un CCP (alimentation du Centre de réponse) de cas pour vous. > > Faites-nous savoir ce que vous découvrez! > markvguy



Une grande partie de la première réponse était sorte de «réflexion sur html", sorte de passer par une liste de contrôle mental de ce qui pourrait causer des problèmes. Malheureusement, les concepteurs de la Mk V ne fournissent pas beaucoup de la manière de capacités de dépannage internes, si facilement vérifier pour le trafic DENET n'est pas possible. En fait, le dépannage opérations internes est difficile, même pour le personnel de l'usine de GE, car il n'y a pas beaucoup de possibilités d'obtenir à des données de fonctionnement interne et il n'y a pas beaucoup d'ingénieurs laissé familier avec les opérations internes Mk V de contrôle de la turbine. L'une des premières 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é récemment acheté / installé - avec le nouveau PROMset (s) ??? ? Avez-vous mis en œuvre TIL-1480 R2 , il est très intéressant de noter que les problèmes ne sont actuellement constatés sur les <S > et que <S> est "interrogé" en utilisant l'un des outils viewn.!.?.! Quel outil viewn (s) utilisez-vous pour collecter des données? Utilisez-vous un fichier à la liste des points à recueillir par l'outil viewn? Si oui, pouvez-vous copier le fichier PointList à une réponse? Utilisez-vous un fichier batch pour exécuter l'outil viewn? Si c'est le cas, ne l'utilité viewn générer une "alerte" quand il est lancé par le fichier batch? À quel taux est les données recueillies avec l'outil viewn? S'il vous plaît la liste l'entrée de ligne de commande qui est utilisé pour démarrer l'outil viewn? Quand avez-vous commencer à utiliser viewn à recueillir des données auprès des <S> processeurs? Avez-vous apporté des modifications à la View2 fichier de données / de routine à l'époque les erreurs de CDC ont commencé? Qu'est-ce qui se passe lorsque vous effacez les erreurs de système de clavier d'affichage de la LCC lorsque l'utilitaire viewn n'est PAS en cours d'exécution? (Pour les erreurs de système claires en utilisant le clavier du LCC d'affichage, appuyez sur DCC sur le clavier de l'écran de LCC; '186 MONITOR »devrait apparaître à l'écran Appuyez sur INC jusqu'à ce que' Effacer les erreurs SYS" est affiché à l'écran, puis appuyez sur ENTRÉE presse INC nouveau.. jusqu'à ce que 'Effacer les erreurs SYS "est affiché à l'écran et appuyez sur ENTRER de nouveau Si le numéro indiqué est 0, des erreurs ont été effacés et réinitialisés;. si le nombre est petit ou incrémente pendant que vous regardez il, les erreurs n'ont pas été effacé. Appuyez sur NORM pour revenir à l'affichage par défaut, ou l'affichage revient à l'affichage par défaut après une brève période de temps.) Vous semblez dire qu'il ya des périodes où les alarmes ne s'affichent pas, puis ils commencent soudainement réapparaisse. Est-ce exact? Avez-vous essayé de remplacer la carte LCC? Encore une fois, il est très difficile de dire comment procéder car il est très 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 détecté que vous êtes un peu frustré par les réponses que vous obtenez, mais vous devez savoir qu'il ya beaucoup de sites qui connaissent les mêmes problèmes que vous et ils courent très bien jour après jour - et même GE n ' t savent exactement quoi faire pour résoudre le problème (s). Vous avez trouvé l'aide d'un forum libre - si vous payez pour ce conseil, vous pourriez avoir un reproche légitime. vous êtes commentaire au sujet d'être "... 1 court de déclenchement intempestif ..." est complètement déroutant.Malheureusement, raison de l'absence d'outils de dépannage pour les problèmes de ce genre, cela se résume assez souvent à la (répugnant) tâche d'échange de cartes ... Il est recommandé que vous arrêtez l'appareil vers le bas, mettez le <S> processeur, détrôner ( débrancher) tous les câbles un à la fois et avant de les rebrancher dans l'application de la graisse conductrice recommandé aux bornes (vous pouvez généralement trouver graisse conductrice emballé dans des boîtes avec de rechange imprimé des cartes de circuits imprimés; GE a commencé à livrer la graisse dans la fin des années 1990 avec toutes les cartes vendues comme pièces de rechange ou de remplacement de réparation et de rendement), puis remettre en

place les câbles. Cela devrait être fait sur tous les câbles de la carte de LCC, la carte CDC, et la carte de TCQC -. Particulier les câbles marqués VARC et / ou ARCPL Soyez sûr de faire attention à l'orientation des câbles sur la carte LCC, en particulier les câbles fixés aux connecteurs en bas de la carte. Aussi, soyez particulièrement prudent avec le câble de 3PL qui relie la carte LCC, la carte CDC, et la TCQA (et TCQB, si équipé). Les câbles 3PL n'a pas tirettes et il peut être très facilement endommagés si pas tiré lâche très soigneusement et remis en place en appuyant fermement tout au long de la nervure supérieure du connecteur! Si cela ne résout pas le problème, essayez de remplacer le LCC carte. L'auteur croit qu'il ya une certaine "caractéristique" de certaines révisions PROM Mk V qui, lorsqu'il est activé par une demande mal formée des données ou des données qui qui n'existe pas ou pour les données à un taux «excessif» provoque la DPM ( tampons et la manipulation des routines mémoire mémoire à double accès mémoire) et associés à être corrompus, parfois au-delà "réparation". Dans la plupart des cas, ces alarmes sont nuisibles et ne nuisent pas à l'opération de l'unité (encore une fois, si un sondage de Mk V opérateurs / techniciens a été prise, il serait sans doute révéler que quelque part entre 30 et 40% des panneaux exposition !. ce comportement de façon 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 défaillance, qui indiquent des problèmes plus graves - peut-être (probablement) pas même lié aux erreurs de LCC . C'est l'une des difficultés de faire face à ce genre de questions qui ont existé pendant une certaine période de temps avant que quelque chose se passe qui pousse les gens à prendre connaissance et commencer à "rapporter" choses sans rapport. Comprendre et dépannage Mk V Les opérations internes et de diagnostic Alarmes prend un peu de patience et d'expérience sur le tas.Et, il a été dit plusieurs fois auparavant - TOUTE processus ou alarme de diagnostic doit être dépanné et résolu aussi vite qu'il est annoncé. Ne pas le faire peut causer d'énormes quantités de temps et d'efforts pour être gaspillés; prendre de l'expérience. 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é implantée, mais Alarmes de diagnostic MÊME SUITE > Il est très intéressant de noter que les problèmes 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 & données sont recueillies auprès <S > CORE UNIQUEMENT. Nous avons 6 GT'S & POUR TOUS GT'S Nous recueillons des données 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 données? > ANS (RVSSSRAO), nous utilisons VUE 2 DOSSIER POUR LA COLLECTE DE DONNÉES. > Utilisez-vous un fichier à Liste des points à recueillir par l'outil viewn? Si oui, pouvez-vous copier le fichier PointList à une réponse? > ANS (RVSSSRAO):. nous créons un fichier avec la liste des points à RECUEILLIS > Utilisez-vous un fichier batch pour exécuter l'outil viewn? Si c'est le cas, ne l'utilité viewn générer une "alerte" quand il est lancé par le fichier batch? > ANS (RVSSSRAO): nous courons fichier batch pour collecter des données. > A quel taux est les données recueillies avec l'outil viewn? ? S'il vous plaît énumérer l'entrée de ligne de commande qui est utilisé pour démarrer l'outil viewn ANS (RVSSSRAO): 1 échantillon par minute pour 50 POINTSMAXIMUM. > Quand avez-vous commencer à utiliser viewn à recueillir des données auprès des <S> processeurs? ? Avez-vous fait des modifications apportées au fichier de données 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 récemment ON View2 FICHIER. > Qu'est-ce qui se passe lorsque vous effacez les erreurs de système de clavier d'affichage de la LCC lorsque l'utilitaire viewn n'est PAS en cours d'exécution? (Pour les erreurs de système claires en utilisant le clavier du LCC d'affichage, appuyez sur DCC sur le clavier de l'écran de LCC; '186 MONITOR »devrait apparaître à l'écran Appuyez sur INC jusqu'à ce que' Effacer les erreurs SYS" est affiché à l'écran, puis appuyez sur ENTRÉE presse INC nouveau.. jusqu'à ce que 'Effacer les erreurs SYS "est affiché à l'écran et appuyez sur ENTRER de nouveau Si le numéro indiqué est 0, des erreurs ont été effacés et réinitialisés;. si le nombre est petit ou incrémente pendant que vous regardez il, les erreurs n'ont pas été . autorisé Appuyez sur NORM pour revenir à l'affichage par défaut, ou l'affichage revient à l'affichage par défaut après une brève période de temps). ANS (RVSSSRAO): Même après avoir Réinitialisation des alarmes augmentent continuellement lorsque la vue 2 fichier n'est pas RUNNING.WE DO la même procédure pour l'effacement des alarmes DE LCC. > Vous semblez dire qu'il ya des périodes où les alarmes n'apparaissent pas, puis ils commencent soudainement apparaître de nouveau. Est-ce exact? > ANS (RVSSSRAO): pendant 3-4 mois à partir de maintenant n'ont déclenché 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 très difficile de dire comment procéder car il est très 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 détecté que vous êtes un peu frustré par les réponses que vous obtenez, mais vous devez savoir qu'il ya beaucoup de sites qui connaissent les mêmes problèmes que vous et ils courent très bien jour après jour - et même GE n ' t savent exactement quoi faire pour résoudre le problème (s). Vous avez trouvé l'aide d'un forum libre -. Si vous payez pour ce conseil, vous pourriez avoir un reproche légitime > > Vous êtes commentaire au sujet d'être "... 1 court de déclenchement intempestif ..." est complètement déroutant. > > Malheureusement, en raison de l'absence d'outils de dépannage pour les problèmes de ce genre, cela se résume assez souvent à l'(répugnant) tâche d'échange de cartes ... > > Il est recommandé que vous arrêtez l'appareil vers le bas, mettez le < S> processeur, renverser (débrancher) tous les câbles un à la fois et avant de les rebrancher dans l'application de la graisse conductrice recommandé aux bornes (vous pouvez généralement trouver graisse conductrice emballé dans des boîtes avec de rechange cartes de circuits

imprimés; GE a commencé à livrer l' de la graisse à la fin des années 1990 avec toutes les cartes vendues comme pièces de rechange ou de remplacement de réparation et de rendement), puis remettre en place les câbles. Cela devrait être fait sur tous les câbles de la carte de LCC, la carte CDC, et la carte de TCQC - en particulier les câbles marqués VARC et / ou ARCPL. ANS (RVSSSRAO): Nous allons le faire, mais DIFFICILE POUR RETIRER LA PRISE dès que la graisse a été appliquée. > Assurez-vous de faire attention à l'orientation des câbles sur la carte LCC, en particulier les câbles reliés aux connecteurs en bas de la carte. Aussi, soyez particulièrement prudent avec le câble de 3PL qui relie la carte LCC, la carte CDC, et la TCQA (et TCQB, si équipé). Les câbles 3PL n'a pas tirettes et il peut être très facilement endommagés si pas tiré lâche très soigneusement et remis en place en appuyant fermement tout au long de la nervure supérieure du connecteur! > > Si cela ne résout pas le problème, essayez de remplacer le la carte de LCC. > > L'auteur croit qu'il ya une certaine "caractéristique" de certaines révisions PROM Mk V qui, lorsqu'il est activé par une demande mal formée des données ou des données qui qui n'existe pas ou pour les données à un taux «excessif» provoque la DPM (double accès mémoire) et les tampons de mémoire associés et la manipulation des routines de mémoire pour être corrompus, parfois au-delà "réparation". Dans la plupart des cas, ces alarmes sont nuisibles et ne nuisent pas à l'opération de l'unité (encore une fois, si un sondage de Mk V opérateurs / techniciens a été prise, il serait sans doute révéler que quelque part entre 30 et 40% des panneaux exposition ce comportement de façon intermittente ou continue ... triste, mais vrai!). > > Quoi de troublant dans votre cas est les ptr1 Commentaires chauds et pilote de relais alarmes de défaillance, qui indiquent des problèmes plus graves - peut-être (probablement) pas même lié à la erreurs de LCC. C'est l'une des difficultés de faire face à ce genre de questions qui ont existé pendant une certaine période de temps avant que quelque chose se passe qui pousse les gens à prendre connaissance et commencer à "rapporter" choses sans rapport. Comprendre et dépannage Mk V Les opérations internes et de diagnostic Alarmes prend un peu de patience et d'expérience sur le tas. Et, il a été dit plusieurs fois auparavant - TOUTE processus ou alarme de diagnostic doit être dépanné et résolu aussi vite qu'il est annoncé. Ne pas le faire peut causer d'énormes quantités de temps et d'efforts pour être gaspillés; prendre de l'expérience. ANS (RVSSSRAO):. QU'EST-CE doivent être vérifiés POUR PTR1 PROBLÈME MERCI DE CONSEILS ET SUGGESTIONS.



Une chose que vous devez savoir sur les serveurs GE Mark V IHM par rapport à s: Ils génèrent beaucoup plus de trafic sur le StageLink que s - beaucoup plus! Et c'est même avant que l'on commence l'exécution des programmes viewn pour la collecte des données. (Un serveur IHM est une IHM avec une carte de ARCnet qui communique avec Mk V panneau (s) de contrôle de la turbine sur le StageLink.) Un ne demande que des données pour les points qui sont configurés pour apparaître sur l'écran qui est actuellement en cours de affichées 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 données 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 données à 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 données à partir du panneau de commande de turbine Mk V qui a des problèmes 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 appliquée;. il est non-durcissement et "gras" (c'est-à-glissante) et devrait effectivement faire enlever les connecteurs plus facile Il y avait généralement une information . fiche emballé avec les tubes de graisse conductrice sur la façon d'appliquer la graisse Encore une fois, plusieurs fois résoudre un problème comme celui-ci revient à remplacer les cartes, cet auteur a horreur du «dépannage» de cette façon, mais parfois il n'y a pas d'autre moyen Encore une fois,. cet auteur sait de nombreux sites qui rencontrent ce même problème, n'ont même jamais essayé de résoudre le problème, et ont connu aucun problème en essayant de

démarrer ou faire fonctionner les unités.!.?.!.? C'est l'un des «mystères de la Mk V . " Une chose intéressante qui peut être fait est d'échanger des cartes entre les processeurs et voir si le problème suit la carte. Par exemple, prendre la CDC de <S> et échanger avec l'un de <R>, faire les configurations appropriées et Téléchargements après mise sous tension de, re-démarrage et si le problème commence à se produire <R> et pas dans <S>, alors le problème est la carte CDC. Vous pouvez faire de même avec la carte de LCC. Si le problème reste dans <S>, alors il peut être un câble / problème de connexion. VARC ou ARCPL markvguy



Nous avons 6 GT de individuelle avec HMI et système 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 reliés en mode de guirlande avec un câble de fibre optique via MOD HUB.for tous les GT de nous collectons des données de <S> ordinateur. Quel est ce qu'il VARC ou ARCPL câble / connecteur. Merci pour la réponse à l'avance.



> Du 9 paragraphe de la première réponse, "... se référer 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 Février, 2007 - 22:24

Cher Mark V Guy, Nous avons eu l'occasion de faire un pas en avant dans la réalisation du diagnostic en outre dans la résolution de la <S> Erreurs de base DCC. Nous avons forcé certains signaux comme L4_XTP, L20 FG1X ETC pour vérifier l'état des relais à TCTG carte. Nous avons trouvé k14 relais pas de

mise en route. Donc, nous avons vérifié le câble de TCQA carte de <S> noyau de TCTG carte. Nous repalced le câble et constaté aucun changement de statut. Donc trouver conclu que TCQA carte est défectueuse. Donc, nous avons remplacé la carte.Actuellement, aucune alarme de diagnostic sont apparus jusqu'à présent. Machine a été repris en service deux jours en arrière. 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 Février, 2007 - 23:20

Félicitations pour trouver le problème, et merci pour les commentaires! Il aide tout le monde qui lit les messages et ont ou peuvent avoir des problèmes identiques ou similaires. Merci aussi pour les détails de la résolution des problèmes; ils sont aussi très utiles à cet auteur et d'autres, aussi. markvguy


Publié par RAM le 12 Décembre 2006 - 15:53

Salut, Très très intéressant et conseils de dépannage, espérons 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 problème, que ce soit. " Voulez-vous s'il vous plaît expliquer le sens de cette phrase? Cordialement, RAM



Il est présumé que <R>, <S>, l'information <T> et <C> demande de l'autre au début de la trame. En pensant à, il semble que si les demandes de <S> ont été mal formés par un processeur, ils seraient mal formés aux autres processeurs, qui se plaindraient de même. C'est de la pure spéculation, mais il ne semble pas illogique. Le système 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 réflexion sur html" en essayant de tirer logiquement que l' . problème 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 même temps. Ou, lorsque l'interrupteur dans le <PD> noyau est recyclé très rapidement. Parfois, il suffit de mettre hors tension pendant une minute ou deux avec l'interrupteur dans le <PD> noyau va résoudre le problème; . parfois, il ne sera pas C'est une pratique qui est assez fréquent dans les cours de formation Mk V - quand il n'y a aucune entrée ou sortie connectés à la centrale, et quand ils sont alimentés par des convertisseurs AC-DC avec une capacité de courant de sortie limité. Sur le terrain, Mk Vs sont généralement alimentés par piles nominales 125 VDC avec sortie courant très élevé surtout dans le cadre d'un disjoncteur de 50A, et les chargeurs avec sorties de courant élevés reliés à la batterie. Cet auteur n'a jamais toléré la pratique de re-démarrage d'un panneau entier avec le disjoncteur principal, même en cours de formation.Et ce que les gens voient en classe, ils portent habituellement retourner sur le terrain .... Il sera intéressant de savoir comment le panneau Mk V a été mis hors tension. markvguy

Date post:	27-Dec-2015
Category:	Documents
Upload:	nabil160874
View:	99 times
Download:	10 times

Mark v DCCC Alarms

Documents