Mark V I/O card alarms and warm start up procedure

G

Thread Starter

GSH

Dear all,

In our plant we are using MARK V control system. daily we are monitoring the IO cards status but in C processor we are getting frequently the following alarms though we are clearing the alarms in card.

BAD BUFFER SIZE
QST DPM NO MEMORY
IO OBJ#4 RESET
please suggest me the consequences of this alarms

while checking IO card status in T PROCESSOR TCQB card is in A2 state. in documents it is said warm start is required. please suggest me how to do warm start up.
 
B

Bob Johnston

Warm start on a MKV processor is to just restart from the small reset button on the front processor card of the controller. Cold start is a power reset of the controller from the PDA power switch. After reset, see if the failed card comes back up to A6 and the controller to A7. What was the controller status when the card was at A2??
 
GSH,

These Diagnostic Alarms can be caused by:

1) operator interface requests for data points that do not exist

2) "malformed" data requests

3) excessive data requests

If there are misspelled or incorrect CDB (Control Signal Database) names (pointnames which don't exist) being requested of the Mark V (by the <I> or GE Mark V HMI (running MS-Windows and CIMPLICITY)) then these alarms can be generated.

Many times if the operator interfaces communicate with external control systems (a DCS, for example) if the point list on the Mark V operator interface is not configured correctly these alarms can be generated. If digital points are put into a list of analog points, or vice versa, these alarms can be generated. Or, if signal names are misspelled or don't exist these alarms can be generated. This is especially common for GE Mark V HMIs shipped from the factory, as the CIMPLICITY projects have been often found to contain pointnames which don't exist in the Mark V. (Sad, but true.)

If there are too many GE Mark V HMI Servers requesting data of a single Mark V control panel these alarms can be generated. (The general rule is that no more than two GE Mark V HMIs should be communicating with a single Mark V control panel.) GE Mark V HMIs running CIMPLICITY request data for EVERY POINT in the CIMPLICITY project--whether or not that data is being displayed on a display or not. So, instead of asking only for the data currently being displayed on any CIMPLICITY display, the GE Mark V HMIs are always asking for every point which exists in the CIMPLICITY project, whether or not is currently being displayed. So, the Mark V <C> processor can be overwhelmed by all the data point requests.

Also, if one or more operator interfaces is running 'Logic Forcing' and/or 'Pre-Vote Data' displays continually then the operator interface is continually requesting LOTS of data at a VERY FAST rate, and the Mark V <C> Processor can be overwhelmed.

The dual-ported memory chips of LCC/SLCC and DCC/SDCC cards have been known to fail. So, as a last resort, you can try replacing the DCC/SDCC card, then the LCC/SLCC card.

There is a cable that connects the LCC/SLCC, DCC/SDCC, TCQA and TCQB (which is an optional card, not present in many Mark V turbine control panels). Many times these cables can be not properly plugged in/seated in the connector. Especially if cards in that chain have been recently replaced. (GE did NOT put pull tabs on the connectors of this cable, so if care is not used the connections can be disrupted.... Also, sad, but true.)

If it's been a while (say, more than a year or so) since conductive grease was applied to the ribbon cable connectors, it's time to do so again. Remember, though: Too much grease is as bad or worse than too little.

If re-seating the 3PL cable and/or applying conductive grease doesn't solve the problem, after switching off the power from the <PD> core, waiting 30 seconds or so, then re-applying the power replace the TCQB card.

Hope this helps! Please write back to let us know how you fare in your problem resolution.
 
Top