Aircraft checklists: Difference between revisions

Jump to navigation Jump to search
Switch to {{readme file}} to remove a broken Gitorious link and abstract the SourceForge link, and switch to {{fgdata source}} to remove a dead and old Gitorious link.
(Switch to {{readme file}} to remove a broken Gitorious link and abstract the SourceForge link, and switch to {{fgdata source}} to remove a dead and old Gitorious link.)
Line 128: Line 128:
For example, you could define a sequence called "startup" that runs the sequence of checklists: "Before Starting Engines" and "Start Engines". Calling the <tt>autochecklist.nas</tt> script from a menu item binding with "startup" as the argument creates an autostart menu.
For example, you could define a sequence called "startup" that runs the sequence of checklists: "Before Starting Engines" and "Start Engines". Calling the <tt>autochecklist.nas</tt> script from a menu item binding with "startup" as the argument creates an autostart menu.


When you invoke the <tt>autochecklist</tt> script, it executes the checklists defined in the named sequence in the order that they are listed. Starting with the first item in the first checklist, it checks the [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.conditions condition] associated with the checklist item. If false, it runs the binding. It then moves onto the next item and checks if the condition from the previous item has been satisfied. If it is still false, it waits for a number of seconds -- maybe the binding was interpolated or the condition is waiting for something to start, e.g. APU spooling up. Once the condition from the previous item is satisfied, it looks at the condition on the current item and runs the binding if the condition is false. Execution continues like this until all checklist items have their bindings satisfied.
When you invoke the <tt>autochecklist</tt> script, it executes the checklists defined in the named sequence in the order that they are listed. Starting with the first item in the first checklist, it checks the {{readme file|conditions}} associated with the checklist item. If false, it runs the binding. It then moves onto the next item and checks if the condition from the previous item has been satisfied. If it is still false, it waits for a number of seconds -- maybe the binding was interpolated or the condition is waiting for something to start, e.g. APU spooling up. Once the condition from the previous item is satisfied, it looks at the condition on the current item and runs the binding if the condition is false. Execution continues like this until all checklist items have their bindings satisfied.


In some cases, e.g. checks on maximum takeoff weight, bindings will never cause the condition to be satisfied. To cover these cases, the script will consider the checklist to have failed if the condition associated with a checklist item does not become true within a timeout period. In these cases, the pilot needs to review the checklist manually and work out why the aircraft will not start. Once the condition has been corrected, e.g. they removed some fuel or payload to get below MTOW, the checklists can be executed again and should be successful. Because the script checks the condition of each item before running the binding, the automated execution is re-entrant; it just picks up where it left off and does only what needs to be done.
In some cases, e.g. checks on maximum takeoff weight, bindings will never cause the condition to be satisfied. To cover these cases, the script will consider the checklist to have failed if the condition associated with a checklist item does not become true within a timeout period. In these cases, the pilot needs to review the checklist manually and work out why the aircraft will not start. Once the condition has been corrected, e.g. they removed some fuel or payload to get below MTOW, the checklists can be executed again and should be successful. Because the script checks the condition of each item before running the binding, the automated execution is re-entrant; it just picks up where it left off and does only what needs to be done.
Line 260: Line 260:


== Development ==
== Development ==
the docs for this particular feature are to be found in $FG_ROOT/Docs/README.checklists: https://gitorious.org/fg/fgdata/source/1415eef7a43fed664e46815a8595bcb1d6ebb829:Docs/README.checklists
the docs for this particular feature are to be found in {{readme file|checklists}}.
This is also where you can read that the c172p is considered the reference implementation.
This is also where you can read that the c172p is considered the reference implementation.
The system itself is located in [https://gitorious.org/fg/fgdata/source/1415eef7a43fed664e46815a8595bcb1d6ebb829:gui/dialogs/checklist.xml#L18 $FG_ROOT/gui/dialogs/checklist.xml (embedded Nasal)], but -at least for now- that should not matter to you - unless you want to extend the system to add support for new features (in which case, you'll also want to check out $FG_ROOT/Nasal/checklist.nas).
The system itself is located in {{fgdata source|path=gui/dialogs/checklist.xml|line=18|pre=$FG_ROOT|post=(embedded Nasal)}}, but -at least for now- that should not matter to you - unless you want to extend the system to add support for new features (in which case, you'll also want to check out $FG_ROOT/Nasal/checklist.nas).
Whatever is added to the Nasal code should never be aircraft-specific - aircraft specific stuff needs to be expressed via your own XML files - if something is missing, just extend the Nasal file, or ask for help so that we can post some pointers/snippets.
Whatever is added to the Nasal code should never be aircraft-specific - aircraft specific stuff needs to be expressed via your own XML files - if something is missing, just extend the Nasal file, or ask for help so that we can post some pointers/snippets.
<ref> {{cite web
<ref> {{cite web

Navigation menu