Pro CompanionRevision 3.1
FNX-FANTHE FLIGHT COMPANIONS
PRO / REVISION 3.1

MESSAGES AND FAULT ISOLATION: REPAIR THE STATE THAT PRODUCED THE MESSAGE

Contents

The MCDU message is evidence about a state or attempted action. Type I messages in the source are associated with a pilot action; Type II messages can be queued and reappear when the scratchpad becomes free. Clearing a line therefore removes the display of a message, not necessarily its cause. Start recovery by recording the exact text, page, active flight phase and pending transaction. [66, PDF pp. 613-622,629-644] [83, Dated V3 NO-COMPUTATION and manual-hold issue snapshot]

1. Classify a rejected entry. FORMAT ERROR suggests type/grammar/width; ENTRY OUT OF RANGE includes range or state conditions. NOT IN DATA BASE and AWY/WPT MISMATCH point towards identity/cycle or route membership. Reinspect the receiving field and input. Do not replace a correct identifier with a guessed nearby one simply because the original did not fit the current route context. [66, PDF pp. 613-622,629-644] [83, Dated V3 NO-COMPUTATION and manual-hold issue snapshot]

2. Classify a blocked operation. INSERT/ERASE TMPY FIRST, DIR TO IN PROCESS or SELECT HDG/TRK FIRST describes a transaction or guidance-state boundary. Inspect and finish/cancel the existing proposal or establish the intended guidance before retrying. Repeating the same blocked keypress does not change the state; it can conceal which proposal or target is still pending. [66, PDF pp. 613-622,629-644] [83, Dated V3 NO-COMPUTATION and manual-hold issue snapshot]

3. Investigate predictions through prerequisites. Compare both sides where useful, accepted pilot inputs, route validity, actual mass/fuel and relevant sensor information. The older guide describes recomputation techniques for particular cases; they are not universal current Fenix remedies. A dated V3 NO-COMPUTATION report also limits confidence in an all-purpose reset answer. Preserve a reproducible case rather than applying unrelated edits until it disappears. [66, PDF pp. 613-622,629-644] [83, Dated V3 NO-COMPUTATION and manual-hold issue snapshot]

4. Distinguish display access from FM failure. The source's locked/blank MCDU investigation uses whether MCDU MENU responds to separate possible interface and FM issues. Exact reset/failure recovery belongs to the applicable current procedure and verified simulator support. Do not copy a circuit-breaker sequence or database crossload from a different standard merely because the screen looks similar. Maintain an understood guidance state while investigating. [66, PDF pp. 613-622,629-644] [83, Dated V3 NO-COMPUTATION and manual-hold issue snapshot]

5. Define what recovery preserved. After any accepted repair, read the active identity, route, current leg, mass, destination data and FMA. A restored screen can coexist with lost or stale flight data. If a clean parked rebuild is chosen, repeat the complete preparation deliberately. If a real software fault remains, retain build/platform, exact inputs and observed results for a useful report instead of describing only that the MCDU was wrong. [66, PDF pp. 613-622,629-644] [83, Dated V3 NO-COMPUTATION and manual-hold issue snapshot]

Back to contents