Diagnostic Alarms

Diagnostic Alarms, also affectionately known as "Diagnasty Alarms," are generally ignored by most operators
and technicians. This is because many Diag. Alarms are nuisances. Most. Diag. Alarms are "left over" from
engineering development activities, and the alarm text messages are ambiguous and can be very misleading.
HOWEVER, most nuisance Diag. Alarms are the result of either incorrectly configured inputs or outputs,
electrical noise on contact input circuits caused by poor wiring/cabling practices, poor cable shield wiring
practices, or excessively tight tolerances for detecting the alarm conditions in the PROMsets.
When the Diag. Alarm display is "clean, then any Diag. Alarm which is annunciated should be investigated
and resolved as quickly as possible, and unit operation will be much more reliable and there will be fewer
"unexplained" trips.
It is unbelievable the number of sites and units which have had numerous Diag. Alarms since commissioning
and no one pays any attention when subsequent ones are annunciated. Amazingly enough, it's these same sites
which always seem to have the highest occurrences of "unexplained trips" and "unusual problems," and when
asked, "How long have these Diag. Alarms been present?" nobody can answer, or, the usual answer is, "Oh;
they've always been there; we never pay attention to Diag. Alarms."
Unfortunately, it's not possible for operators, technicians, or most GE personnel, to understand the limits of
most Diag. Alarms. There's no "CSP" for Diag. Alarms. It takes a good level of familiarity with the Mk V
hardware to troubleshoot and understand most Diag. Alarms.
GE did produce "help" files for Diag. Alarms, but unfortunately it was only for a limited set of PROM
revisions and was never maintained very well. If you can find a copy of the files (HELP_BD.DAT and
HELP_QD.DAT) they can be helpful in troubleshooting even if they arent 100% applicable to your unit.
1) The current for servo-valve output #5 (usually assigned to the IGV servo--BUT check your I/O Report
and/or IO.ASG file to be certain) for the indicated processor disagrees with the "calculated" output value.
(Usually on <I>s the processor which has detected the Diag. Alarm condition--the "indicated" proccessor--is
listed somewhere on the line the Diag. Alarm is displayed on.) This usually indicates a wiring problem (open
circuit, high/low resistance, etc.) or a TCQA or TCQC card problem (refer to the servo-valve output
descriptions in the App. Manual and the Signal Flow Diagrams in Appendix D of the App. Manual to follow
signals through the Mk V). If one of the remaining two #5 servo-valve outputs develops a problem, the unit
will most likely trip--this alarm should be resolved at the earliest possible time.
2), 3), 4) Diagnostic Alarms detected by any processor will be annunciated independently; in other words, it
doesn't take two-of-three processors to annunciate a Diag. Alarm like it does for a process alarm. The three
TCEA cards have detected that the generator breaker is taking longer to close than the self-correcting limit
programmed in the I/O Configurator. This is generally caused by the Self-Adapt feature being turned on when
it should not be (see the App. Manual--this feature should be used only with certain types of breakers), _OR_
the generator breaker status contact connected to the <P> core is not a direct-acting contact (the generator
breaker status contact connected to the <P> _MUST NOT_ come from an auxiliary relay, it must come from a
contact which is directly actuated by the generator breaker's main contacts/actuator). If the generator breaker is
closing "satisfactorily", then this alarm is probably not serious and may just be a configuration issue,
particularly if this alarm has been present for a long time (but nobody probably pays attention to the Logger
(the Alarm Printer) and/or it's always out of paper or jammed or the ribbon is worn out or it's just shut off--so
there's no telling how long ago this alarm was first annunciated...the Logger is your friend and troubleshooting
partner; if it's not working--fix it).
5),6) No; this is probably NOT related to a 125 VDC Ground alarm. The 125 VDC is inverted to AC, then
transformed down to a lower voltage (magnitude unimportant), then converted into regulated DC voltages (+5
VDC, +/-15 VDC, etc.)--so there is "isolation" between the 125 VDC and the regulated power supply voltages.
There is probably a problem with the indicated processor's power supply. There was also a version of IOMA
software which generated these alarms at a very annoying and nuisance rate... Subsequent versions of IOMA
PROMs "fixed" this. If the indicated processor for these two alarms is the same as that for the TCQA servo
output Diag. Alarm, then these three Diag. Alarms may be related...but if it were a real serious problem there
would probably be many more Diag. Alarms related to the +/-15 power supply problem

Do you have _both_ <I>s and HMIs connectd to the same StageLink? (This is an important question...)
On the 'Main Menu' of an <I> there should be a 'Diagnostic Alarm Display' selection. If there isn't, exit out to a
command prompt and type the following command and then press Enter:
ALMDSP DIAG
This will bring up the Diagnostic Alarm Display, and show any Diagnostic Alarms being annunciated. Diag.
Alarms must be Acknowledged and Reset (on an <I>) just like Process alarms, to clear them from the
Diagnostic Alarm Display.
If there is no Diagnostic Alarm Display selection on the Main Menu, SOMEONE has deleted it or commented
it out from F:\RUNTIME\MENU.DAT. EVERY <I> which shipped from the factory had a Diagnostic Alarm
Display selection on the Main Menu--and it NEEDS to be there!
L30DIAG_C comes from a Mk V "internal" logic. The CSP generally only shows how Process Alarms are
annunciated. Drop 000, "DIAGNOSTIC ALARM", is just a Process Alarm to alert the operator that a
Diagnostic Alarm condition has been detected and is being annunciated and/or has not been resolved/reset.
(Isn't this fun?)
In general, on Mk V systems equipped only with <I>s, error messages on Mk V processors in the Mk V
turbine control panel did NOT always result in Diagnostic Alarms being annunciated on the <I>. On HMIs,
processor erros annunciated on the LCC/SLCC displays quite often resulted in L30DIAG_C being set to a "1"
with NO Diagnostic Alarm being shown on any display. In other words, quite frequently on Mk V systems
equipped with HMIs it was NOT possible to clear Process Alarm Drop 000 until all LCC/SLCC display error
messages were cleared--even though NO Diagnostic Alarms were being shown on any display on the HMI.
(Are we still having fun?)
To clear error messages on a Mk V processor (<C>, <R>, <S>, or <T>), press the LCC button in the upper
lefthand corner of the LCC/SLCC display keypad; '--186 MONITOR--' should appear on the display. Then
press the INC button three times until '3> CLEAR SYS ERRORS' is shown in the display (you may have to
use the DEC button if you pass it the first time, or just keep pressing INC at a slow rate until you get back to
the third selection; there are seven selections on the LCC/SLCC display).
When '3> CLEAR SYS ERRORS' is shown in the LCC/SLCC display, press the ENTER key; the number of
errors will be shown. Press the INC key again three times until '3> CLEAR SYS ERRORS' is shown in the
display, and then press ENTER again. If '0 SYS ERRORS' is shown in the display, press the NORM key to
return to the normal LCC/SLCC display. If the number of errors is still not at zero, problems still exist--which
should be annunciated on the Diagnostic Alarm display on the operator interface.
Diagnostic Alarms are SUPPOSED to be indicative of problems with the Mk V hardware (printed circuit
cards) or sofware. In other words, they are "internal process alarms". Unfortunately, many improper
configuration settings (particularly in the I/O Configurator) result in nuisance Diagnostic Alarms which were
never resolved by the start-up/commissioning engineer.