The X-Plane autopilot knows three levels of operation:
Flight director off, no cues are generated
Flight director on, steering cues are generated, no servos are actuated
Flight director and autopilot on, servos act on steering cues
This is represented in the datarefs sim/cockpit2/autopilot/flight_director_mode and sim/cockpit2/autopilot/flight_director2_mode for the pilot-side and co-pilot side units.
Flight director switches
Depending on the specific aircraft, it might be necessary to turn off the steering cue display with a switch that does not switch off the autopilot computer. On some aircraft, it is possible to hide the flight director bars even if the autopilot is flying the aircraft. To facilitate that, the new datarefs sim/cockpit2/autopilot/flight_director_command_bars_pilot and sim/cockpit2/autopilot/flight_director_command_bars_copilot were added. These allow for turning off the command bars but let the autopilot keep flying the aircraft if desired.
Flight director master lights
When a flight director is generating cues, no matter if its bars are displayed or not, it can act as the master (generating the cues from its on-side altimeter, airspeed, attitude and heading instruments). If a flight director is on but not the master, it will copy the steering cues from the other flight director. During certain phases of flight, it is possible for both flight directors to act independently and both be considered master, see the article on auto lands for more information.
The datarefs sim/cockpit2/autopilot/flight_director_master_pilot and sim/cockpit2/autopilot/flight_director_master_copilot can be used to light up lights associated with the flight director switches.
Auto-throttle arming
Traditionally, X-Plane has always considered its auto-throttle to be “armed”. That is, when asked to provide reference N1 or EPR, or speed hold, it would always come on in response to a command like sim/autopilot/autothrottle_n1epr.
It is now possible to actually dis-arm the autothrottle so that commands for speed hold or thrust reference are ignored. This is reflected by the dataref sim/cockpit2/autopilot/autothrottle_enabled reading -1 when the system is disarmed, also the new dataref sim/cockpit2/autopilot/autothrottle_arm can be used which will read 0 when the system is dis-armed and 1 if the system is armed or active.
For compatibility with older aircraft that expect X-Plane’s autothrottle to be always available, X-plane defaults to loading aircraft with the system armed. Authors are advised to set the new datarefs as desired when their plugin is loaded if they want to take advantage of the new behaviour.
Comments Off on Flight director and autothrottle datarefs
NAV ID is no longer updated for DME-only reception
For each radio, X-Plane provides two data refs for ID (morse code) read-out: sim/cockpit2/radios/indicators/navN_nav_id and sim/cockpit2/radios/indicators/navN_dme_id where N is 1..10 for the 10 nav receivers X-Plane has by default. This is what allows you to hear the correct DME ID of a Nav radio in DME hold mode, where these IDs differ. These datarefs have been available since X-Plane 11.35. If you have not started using the DME_id datarefs, you are already not supporting DME hold functionality.
Starting with X-Plane 12, the nav_id datarefs will (correctly!) no longer reflect reception of stand-alone DMEs, and DMEs that are part of TACAN stations with no associated civilian VOR. Tuning a standalone DME will now only cause the navN_dme_id datarefs to show the ID, but not the navN_nav_id. This is important if you show the ID readout on the ND for bearing pointers. In this case, you will probably want to hide or park the bearing pointer and only display DME readout. Check the POH/FCOM of the airplane you are modeling for specifics.
Example: Tuning 108.50 at Paderborn airport (EDLP). This will cause the Paderborn/Lippstadt DME to be picked up. “PAD” will be displayed on nav1_dme_id but not nav1_nav_id, which will remain blank, along with the CDI remaining flagged as there is no VOR associated with that DME.
NAV radios can be used to pick up TACAN Azimuth with the new TACAN tuning datarefs
You might have noticed that in X-Plane 11.50, you can tune TACAN stations from the X-Plane map. For X-Plane 12, we added the datarefs for tuning TACAN conveniently using mode and channel. All 10 navigation radios can now be tuned to TACAN stations using the datarefs sim/cockpit2/radios/actuators/tacN_channel and sim/cockpit2/radios/actuators/tacN_mode, where N is 1 or 2 for the default radios. You can also use the array datarefs to access N=0..9. “Channel” is an integer between 1 and 126 inclusive. “Mode” is either 0 if the radio is operating as a VOR receiver (this is the default), or 88=’X’ or 89=’Y’ for a TACAN mode. Writing to these datarefs will cause the receiver to operate in TACAN mode, while writing to the frequency datarefs will cause the receiver to operate in VOR mode. Reading datarefs is always safe and does not change the mode of operation.
Example: Set 85X (channel=85, mode=’X’) near Pope AAF (KPOB). This will tune the Pope TACAN and give you Azimuth and distance information. This is the correct way to tune the TACAN for a military radio. A civilian radio would instead tune the paired frequency 113.80 using the frequency datarefs. This will cause you to only have DME, but not Azimuth.
Radio power is important when using a NAV receiver in TACAN mode: By default, the radio is powered on in receive-only mode and will not interrogate DME stations. You will only see the azimuth, not the distance. In real military applications, this is used to keep the plane under EMCON. You have to explicitly select transmit/receive (T/R) mode if you want to send out signals to interrogate DME stations and get a range reading: sim/cockpit2/radios/actuators/nav{1,2}_power 0 = Off, 1 = R, 2 = T/R. If operating in VOR mode (civilian frequency rather than military channel), this restriction does not exist and a power dataref value of 2 has no meaning.
NAV1 and NAV2 are multi-mode receivers
The receivers for NAV1 and NAV2 can supply GLS FAS guidance like a localizer and glideslope when tuned to a GLS channel between 20000 and 40000 and near a GBAS ground station. By simply writing the channel number to the frequency datarefs sim/cockpit2/radios/actuators/nav1_frequency_hz or sim/cockpit2/radios/actuators/nav2_frequency_hz (or the array dataref at indices [0] and [1]) the virtual localizer and glideslope of a GLS approach can be presented regardless of the load status of said approach in the FMS. Note that this only works for GLS approaches and not for any type of SBAS approach (WAAS, EGNOS, MSAS). These can still only be picked up by the augmentation receivers (array index [10] and [11]) which must be auto-tuned by the GPS or FMS.
SBAS (WAAS) is a privilege
In order to equip your plane with an SBAS receiver (which can receive WAAS, EGNOS and MSAS), go to the Plane Maker Systems page and open the Electrical bus configuration tab. Assign the SBAS receiver a bus (or multiple) to enable it to draw power from the electrical system. Note you probably don’t give it an amperage. The power consumption of a GPS unit does not change appreciably whether its SBAS portion is off or on. Therefore, if you have already set the power consumption of your whole GPS system in amps, the amps for the SBAS receiver portion should likely remain 0 or a nominal 0.1.
For basically all modern general aviation aircraft, you should simply assign the same busses as the primary GPS.
On airplanes equipped with this capability, upon loading an approach with LP or LPV minima, sim/cockpit2/radios/actuators/nav_frequency_hz[10] and [11] will be auto-tuned to a WAAS or EGNOS channel and present FAS guidance for an LP or LPV approach.
Note that surprisingly few airliners do have SBAS capability. It is not standard on any Boeing aircraft and only very recently a retrofit for the 737 was certified. For Airbus, it’s called ‘SLS’ and is available as an option that currently only exists in the A350 and A320NEOs of the 2020 or later model years. So it is highly unlikely that you need to set this if you are making a commercial airliner that represents the current fleet standard. Do NOT confuse this with the GBAS receiver, which is far more common in airliners. GBAS reception is not influenced by this setting.
Note that failing the SBAS receiver in flight will yield slightly different behavior than not installing it in the plane in the first place.
Baro VNAV no longer unflags the WAAS glidepath
sim/cockpit/radios/gps_has_glideslope and sim/cockpit/radios/gps2_has_glideslope have erroneously indicated 1 in the past when flying an RNAV approach with baro VNAV. This is no longer the case, these datarefs will show 1 only for SBAS and GBAS derived glide paths, not for barometric path deviation. Use the barometric flight plan target altitude sim/cockpit2/radios/indicators/fms_fpta_{co}pilot dataref to find out whether barometric VNAV is active. This dataref is parked at -1000 if no baro VNAV is available.
Note: This does not apply to aircraft equipped with integrated approach navigation. If IAN is active, the baro VNAV path will be available as glide path read-out.
Glideslope can be selected off
The glide path receiver normally automatically tunes the UHF frequency paired with the VHF LOC frequency that is selected on the NAV receiver. This can be selected off, if you explicitly want to de-select the ILS glideslope, for example to fly a LOC approach with baro VNAV guidance. The array dataref sim/cockpit2/radios/actuators/nav_receiver_glideslope_off[N] defaults to 0 for all 10 radios, which means they can pick up glide slopes. Set the dataref to 1 for a specific radio to disable glide slope reception.
NAV1 and NAV2 can be restricted to ILS+GLS
On some modern airliners, the receivers for localizer and VOR signals are split in such a way that the autopilot can only follow a localizer, but not a VOR deflection. In that case, the NAV signal can be presented on the navdisplay, but the ILS signal is received by a distinct receiver which is the only one with a connection to the autopilot. This setup can be selected in Plane Maker on the Systems page which allow autopilot configuration, by ticking the checkbox “ILS/Multimode receiver only”. This changes the behaviour of the NAV receivers as follows:
NAV1 and NAV2 can no longer pick up a VOR signal. They will only un-flag for the reception of an ILS or GLS localizer.
NAV1 and NAV2 remain the only ground-based navigation that can be selected to the HSI and thus the only ones that the autopilot can follow in NAVLOC or APP mode.
NAV1 and NAV2 will be displayed on the default navdisplay in APP (0) mode.
NAV3 and NAV4 (array indices [2] and [3]) will be displayed on the default navdisplay in VOR (1) mode.
NAV3 and NAV4 (array indices [2] and [3]) are considered the VOR receivers of the airplane when loading a VOR from the map or instructor station.
Use NAV receiver power to “park” receivers
The array dataref sim/cockpit2/radios/actuators/nav_power should be used to “park” needles that are de-selected, as it also works with receivers NAV3-NAV9. Do NOT write invalid frequencies, like -1 or 999 to a frequency dataref. The frequency datarefs are range-checked for valid TACAN, LOC, VOR or GLS VDB channels and writing a “magic value” like -1 will cause a range check to trip. If you want a receiver to not display anything, simply un-power it.
As we all know, the source for the autopilot “NAV” and “APR” modes is set with the datarefs sim/cockpit2/radios/actuators/HSI_source_select_pilot and HSI_source_select_copilot respectively for the autopilot side. But what EXACTLY supplies the lateral and vertical deviation indications we see on the PFD and that the autopilot sees? What should the Nav ID and DME distance readout be?
This article summarizes X-Plane’s capabilities when it comes to modern integrated approach navigation and sheds light on the new datarefs.
ILS approach
Tune the ILS on the NAV1 radio (for left autopilot, or NAV2 radio for right autopilot). Whenever a valid ILS signal is received by the on-side NAV receiver, it locks out ALL other approach modes!
RNAV (GPS) and RNAV (RNP) approaches and overlay approaches
This approach is loaded into the GPS or FMS. It is flown with either Baro-VNAV or SBAS-derived VNAV. No FAS block is provided. No channel is tuned into the WAAS or the GLS receiver.
This includes all cases of “overlay” approaches, i.e. VOR, DME, NDB and TACAN approaches that can be flown with integrated approach navigation, if the airplane is so equipped.
In this case, the DME ID of the GPS receiver tells you the approach ID (e.g. “RNV23LY”) and the DME ID of the augmentation receiver tells you the missed approach point (e.g. “RW23L”). The distance readout of the augmentation receiver tells you the distance to that point (usually the runway threshold).
This approach is loaded into the GPS or FMS. The FAS block determines the SBAS system to be used (WAAS, EGNOS or MSAS). The SBAS receiver is tuned to the respective channel and provides FAS navigation, both lateral and vertical.
In this case, the DME ID of the GPS receiver tells you the FAS block ID (e.g. “W05A”) and the DME ID of the augmentation receiver tells you the missed approach point (e.g. “RW05L”). The distance readout of the augmentation receiver tells you the distance to that point (usually the runway threshold).
This approach is loaded into the FMS. A FAS block is provided. The GBAS receiver is tuned to the GLS channel and provides the FAS navigation.
In this case, the DME ID of the GPS receiver tells you the FAS block ID (e.g. “G25A”) and the DME ID of the augmentation receiver tells you the missed approach point (e.g. “RW25R”). The distance readout of the augmentation receiver tells you the distance to that point (usually the runway threshold).
This approach is loaded into the FMS. No SBAS or GLS channel is tuned. No FAS block is provided. Final approach navigation comes from the localizer analogue signal. VNAV is provided by the FMS using baro altitude. The autopilot is in VLOC mode laterally, but GP mode vertically.
In this case, the DME ID of the GPS receiver tells you the approach ID (e.g. “LOC31”) and the DME ID of the augmentation receiver tells you the missed approach point (e.g. “RW31”). The distance readout of the augmentation receiver tells you the distance to that point (usually the runway threshold).
Hydraulic gear systems frequently have gear levers with a third “off” position that mechanically locks the gear in the up position without providing hydraulic pressure to keep it up. While various plugins or scripts have been used to animate this type of lever in the cockpit, interaction with X-Plane was always clumsy and did not necessarily work with commands.
The goal of the new gear datarefs is to enable a consistent user experience both with VR and traditional hardware
Gear lever with “off” position
To enable the new behavior, check the “hydraulic LDG gear with Up/Off” option in Plane Maker on the hydraulic systems settings.
The following datarefs are new: sim/cockpit2/controls/gear_handle_animation float y ratio
Gear handle position as float for lever animation. 0 is up, 1 is down, 0.5 is off (for planes that have that). sim/cockpit2/controls/gear_handle_request int y enum
Gear handle request. 0 is up, 1 is down, -1 is off. sim/cockpit2/controls/gear_handle_downlock_release int y boolean
Gear handle downlock release. If this is 1, the gear handle can be moved to up even if the squat switch reports weight on wheels
The commands sim/flight_controls/landing_gear_off and sim/flight_controls/landing_gear_downlock_release are also new.
You can use the animation dataref directly, and it will update the request enum if you are close enough to 0, 0.5 or 1 position. This is especially useful for large handles that have to act naturally in VR.
If you use the commands, the animation dataref is smoothly driven to the 0, 0.5 or 1 position. This is important if external cockpit hardware is used.
If you use the old int dataref, it will update the status to 0 or 1 (no way to achieve off with the old dataref) and the animation dataref will follow smoothly. This ensures that all legacy aircraft and also all new aircraft with no “Off” position work correctly.
Gear lever mechanical lock
Almost all retractable gear systems employ squat switches, that prevent gear retraction on the ground. This corresponds to the “gear can retract on ground” setting in Plane Maker, which would be unchecked for most aircraft.
The new setting “LDG gear lever dnlock” can be checked to configure the behavior of the gear lever in the cockpit. With this option checked, the gear lever in the cockpit is physically arrested in the down position and cannot be moved while the squat circuit is open. This can be overridden with the downlink release command sim/flight_controls/landing_gear_downlock_release.
With this option not checked, the landing gear lever can be moved, but simply won’t actuate the gear when the squat circuit is open. That is the same behavior as X-Plane 11, and appropriate for most small general aviation planes.
X-Plane can limit the power output of altitude engines (or flat-rated engines) in order to not overtemp or overtorque them. In addition to thrust or torque limiting, X-Plane 12 can also limit to N1 or EPR values.
Setting critical altitude or flat-rated temperature
Configuring an altitude or flat-rated engine starts with entering the rated power or thrust and then entering the critical altitude or flat-rated temperature. Pressure altitude is used on reciprocating engines while sealevel temperature is used on jet engines, but that’s merely a convention. Both are just different ways to express the air density up to which the engine will deliver full rated power or thrust without exceeding temperature limits. Without FADEC, if you opened the throttle/thrust lever all the way at sealevel and standard temperature, the engine would deliver way more than its rated power, along with exceeding its maximum ITT or EGT. If the “FADEC prevents engines from exceeding max allowable power” is not checked, the pilot must exercise caution advancing the throttle/thrust lever as below critical density altitude nothing prevents the engine from exceeding its limits.
FADEC prevents overboost below critical density altitude
In the simplest setup, with just having the checkbox checked, X-Plane will simply limit the power output when the throttle/thrust lever is all the way forward. Maximum power/thrust will not be exceeded up to critical altitude or corresponding temperature, over which the power will gradually fall off.
FADEC target paramaters and temp limiting
X-Plane 12 adds a few new options for a finer control over which parameter the FADEC limit controls. Configuring this starts with going to “Boost and Controllers” settings for the engine and configuring a thrust lever angle (TLA) expressed as a fraction of full forward, for FADEC to limit. In the simplest case, only a TLA of 1.0 is configured, in which case the FADEC will limit the maximum thrust setting. X-Plane will interpret any setting between 0.975 and 1.0 of TLA as being in the FADEC limited maximum thrust setting, though the precise angle for the throttle hardware can be overridden by a custom joystick curve to fit the user’s throttle control.
Next, the author chooses a limiting parameter the FADEC uses as primary parameter. This can be either be a direct indication value N1 or EPR, or a synthetic value of power or thrust. For the selected TLA, the author then enters the desired N1, EPR or power/thrust ratio for sea-level standard temperature conditions. X-Plane will modulate the actual target value at runtime for non-standard temperature and higher altitudes.
X-Plane 12 will always use the configured max EGT value (as set in the Limits tab in Plane Maker) as the secondary parameter that is limiting the engine. At runtime, X-Plane will actually limit the power/thrust output of the engine for the desired power and maximum EGT, whichever is lower and therefore reached first.
To achieve the target value, X-Plane 12 uses a PID controller that can be configured on the autopilot parameter configuration screen of Plane Maker, as it is the same controller that is used if the auto throttle is used to achieve an N1 or EPR target. Follow the same guidelines laid out in the article about autopilot parameter configuration for configuring this PID controller.
Assumed temperature
For power/thrust based FADEC, the outside air temperature can be overriden with a higher “assumed temperature” that will cause artificially lower power output by making the controller believe it is operating in less dense air than it actually is. This will cause the engine to run cooler and quieter, and is thus preferred for take-offs in situations where less than full rated power is required. Assumed temperature can be set by the dataref sim/flightmodel/engine/ENGN_assumed_temp[8] and will reduce the power output if it is higher than the actual outside air temperature (it will not increase power if set lower).
FADEC notches/gates on the power lever
Besides maximum output, X-Plane 12 allows configuring up to two more, lower power settings that can be governed by FADEC. Once one TLA is configured to be non-zero, the next lower TLA can be configured to represent a setting for MCT, FLEX or CLB power, depending on airplane type. The minimum distance required to the full power setting is 3% of total thrust lever angle. Another gate or notch can be configured below that, for CRZ or CLB power depending on type. Again, if left at 0 no gate or notch will exist in X-Plane and the thrust lever will not stick. If configured non-0 and at least 3% below the next higher TLA, the thrust lever will stick to the gate/notch.
It is important to select the TLAs for the throttle lever to stick so the keyframes match the animation in the 3D cockpit. That will cause natural interaction with the manipulator in the 3D cockpit. For hardware throttle quadrants, users can override the ranges of the FADEC gates to match their specific throttle hardware by configuring a joystick axis curve for the throttle. This way, one type of hardware throttle can be used with different virtual aircraft.
Plugin controlled FADEC
By reading the dataref sim/flightmodel/engine/ENGN_fadec_pow_req[8] plugins can find out the currently selected notch or gate the thrust lever for each engine is in. They can then override the current target power/thrust, N1 or EPR by writing the desired target to the corresponding spot in the array /ENGN_fadec_targets[3] which corresponds to the selected targets in Plane Maker, i.e. [0] is for the highest notch, [1] for the next lower notch if it exists, [2] for the notch below that if it exists. By writing the target value there, X-Plane will update the N1 or EPR targets sim/cockpit2/engine/actuators/N1_target_bug[8] or /EPR_target_bug[8] and the PID controller will actuate the throttle to achieve the plugin request, but still keep the engine below temperature limits by obeying maximum EGT limit. If this is also undesired, a plugin can resort to using the override throttle dataref sim/operation/override/override_throttles and use their own controller to set the sim/flightmodel/engine/ENGN_thro_use[8] dataref and control the engine directly. X-Plane will not provide any overboost over overtemp protection in this case.
X-Plane 12 changes the way directional gyro drift is calculated and the behavior of the directional gyro drift data refs. If your aircraft or plugin adjusts or watches these datarefs, you will want to check whether your code still works with the new drift.
Types of Error
Once spun up fully, the directional gyro tracks a fixed point in space (its axis is aligned with an imaginary star in the sky, if you will) rather than a course. The pilot initially aligns this axis with the magnetic north at his point of departure. From there on out, gyro drift is now comprised of three components:
apparent wander (the earth rotates while the gyro axis wants to stay fixed)
transport wander (caused by meridian convergence as you fly east or west)
random wander (caused by friction in the instrument itself, the only kind of wander previous versions of X-Plane simulated.).
Latitude adjustment screw
Apparent wander is counteracted by the instrument, which is calibrated to a latitude that it’s being operated at. This is a per-aircraft setting that is stored in the per-aircraft preference file in the _dg_lat_adjust_0 and _dg_lat_adjust_1 parameters for the pilot and copilot side instrument. If the aircraft stays close to the latitude set in the instrument, apparent wander will be very low. If the aircraft operates far away from the latitude setting, apparent wander will be higher. The screw can also be adjusted by datarefs (see below for data ref list).
Pilot adjustment
The pilot periodically needs to adjust the gyro to compensate for random wander, transport wander, and whatever apparent wander is left that is not compensated by the latitude compensation. Therefore, pilot adjustment must equal the sum of the errors, with a negative sign. Previous versions of X-Plane always had you set the dg_drift_*_deg datarefs to 0 for no error. Now, the drift dataref refers to the pilot adjustment and must instead equal negative gyr_total_error, rather than 0.
Automatic adjustment
In planes so equipped, the gyro is slaved to a magnetic sensing system, that keeps the gyro aligned with magnetic north. A new dataref has been introduced that measures the difference between the gyro and the magnetometer reading: gyr_magnetometer_diff Note that this dataref does not necessarily equal 0 all the time the system is working. In turns, the magnetometer is subject to dip error, which will cause this dataref to show an excursion, even though the directional gyro is tracking perfectly. This slight deviation especially in turns is visible on real compensator instruments as well and is not an error.
New Datarefs:
sim/cockpit/gyros/gyr_latitude_nut float[6] y degrees adjustment screw for the operational latitude of the directional gyro. Counteracts apparent wander of the gyro caused by rotation of the earth
sim/cockpit/gyros/gyr_total_error float[6] n degrees sum of directional gyro error due to earth wander, transport wander, and random wander. For calibration, the drift adjustment (what the pilot sets) must equal negative this value
sim/cockpit/gyros/gyr_magnetometer_diff float[6] n degrees detected difference between gyro heading and magnetic heading picked up by the magnetometer. Keep in mind that this is only accurate in sraight and level flight, as the magnetometer is subject to dip error (but not acceleration error)
Comments Off on Directional gyro drift and adjustment datarefs
X-Plane 12 revises the interaction of collective and throttle control in helicopters. Existing helicopters retain the default behavior of X-Plane 11 until modified in Plane Maker 12 to opt into one of the new governor systems. The joystick control assignments for collective and throttle don’t change, but there’s a new joystick curve available for Robinson-style throttle control.
Governor types
In Plane Maker 12, you can choose the type of throttle governor you can equip your helicopter with:
No governor – this corresponds to leaving the governor checkbox unchecked in Plane Maker 11. The throttle will be fully manual. This is helpful if you want to code your own governor in a plugin.
X-Plane 11 governor – this corresponds to checking the governor checkbox in Plane Maker 11 and preserves the behavior for legacy aircraft.
Robinson-style piston correlator and governor – This adds a correlator to the throttle, and adds the “detent” to the throttle range surpassing the correlator. The governor will only engage at 80% or more rotor RPM
Turbine governor – This changes the throttle to work like a condition lever in normal operation. It has a range below the idle release button where the engine is shut off. Above, you roll the throttle all the way on to enter governing range.
Correlator
The correlator is a linear collective to throttle linkage that automatically opens the throttle as collective input increases. In Plane Maker, you can set two control points to define the linear connection. The correlator is added after the throttle, and does not change the twist of the throttle grip. The correlator input is added to the throttle twist grip input whenever the throttle is out of detent, which by default is 5% throttle, but can be customized to your throttle hardware with a joystick control curve. By holding the throttle in detent (rolling it below 5% or the customized point on your hardware) it is possible to practice auto-rotations with the engine running, as the then the correlator will not kick in during the flare.
Piston Governor
The piston governor adds onto the throttle grip, so unlike the correlator the effect of the governor can be seen on the grip as the throttle will be twisted. When switched on, the governor will kick in once the throttle has been increased enough to go over 80% RPM. Because the governor adds to the correlator, the change in throttle grip caused by the governor will be relatively small, as big power changes are already absorbed by the correlator.
In case of governor failure, the governor fails in the current position, leaving the correlator intact, so it will require small adjustments by the pilot.
Turbine Governor
Unlike the piston governor, the turbine governor governs maximum RPM. The throttle twist grip works more like a condition lever, if the governor is operating normally. The throttle has an OFF range (fuel shut off), then ground idle and then flight range. The “shutoff” range is guarded by the Idle Release lock, preventing accidental engine shutdowns. By twisting the throttle towards flight mode, maximum fuel flow will be enabled, but the actual fuel flow will be adjusted by the governor. The governor works without actually twisting the handle itself, so the throttle handle will show no feedback that the governor is operating, unlike in the piston variant. By blipping the rotor RPM trim, the governed RPM can be adjusted slightly.
In case of governor failure, the fuel flow restriction is removed, so the throttle in flight mode will most likely cause the rotor to overspeed. The pilot will need to reduce the throttle to prevent that, and will then need to manually control the throttle to keep the rotor RPM in the desired range. If configured in Plane Maker, a correlator input will be added to the throttle in case of governor failure, to limit the need for large excursions with the throttle.
The Off-range of the throttle on the turbine helicopter corresponds to the “detent” on the piston helicopter. That is, if you set your hardware up with a response curve for detent, that detent will act as the shut-off position (beyond idle release) on the turbine throttle grip. The commands
sim/engines/collective_idle_release
(for collective twist throttle) and
sim/engines/collective_idle_release_1 to sim/engines/collective_idle_release_8
(for individual overhead levers)
need to be held while retarding the throttle into the off-range, in order to prevent accidental shut-downs.
If you don’t have a hardware throttle, the X-Plane default throttle commands prevent you from accidentally killing the engine by rolling off the throttle. To turn the engine off, you need to hold the command to fully roll off the throttle, release it, and then push it again to actually roll the throttle over the detent and shut the engine off.
Comments Off on Helicopter governor and correlator configuration
X-Plane 12 allows for three distinct ways of trimming the flight controls:
Non-reversible control trim, in which only a small Flettner-type trim control surface is actuated by the trim. This does not directly change the position of the flight control, but instead requires airflow over the control surface in order to move its centering point.
Reversible control trim, in which the flight controls are pre-loaded to modify the centering point. The flight control moves to the new centering point even if no airflow over the control is present
Trimmable horizontal stabilizer, in which the center point of the elevator itself does not change, but rather the incidence of the whole stabilizer is changed, providing up or down force.
X-Plane 12 allows assigning different types of trim to different axes, so it is possible to have a trim tab on the elevator, but a pre-loaded centering spring on the rudder, as is common with many general aviation aircraft like the Cessna 182.
For aircraft creators
If your aircraft is configured to have a trimmable horizontal stabilizer, there is no change in behavior from X-Plane 11. You continue to define the stabilizer deflection range, and set the amount of available elevator trim to 0. The “elevator trim” input is translated into a change in stabilizer incidence and the elevator itself remains untouched. You might want to look into changing the behavior of aileron and rudder trim for your aircraft though, as most airliners do not use tabs on ailerons and rudders, but change the center point of the flight controls instead. This won’t change the behavior in flight (with airflow), only the response on the ground (no airflow).
If you are using the control surface override sim/operation/override/override_control_surfaces to write your own control deflections to all surfaces you will need to actuate the THS directly with the dataref sim/flightmodel2/controls/stabilizer_deflection_degrees to set your trim. Your pitch trim input is no longer automatically applied to the stabilizer incidence if you are overriding the flight controls since you indicated you are responsible for it.
By default, aircraft will have non-reversible trim systems that require airflow to change the flight control deflection. This was the default behavior in X-Plane 11 and before. The only difference now is that the change in center point will be visibly reflected in the datarefs sim/cockpit2/controls/total_pitch_ratio, /total_roll_ratio and /total_heading_ratio
By ticking the checkbox for reversible trim in an axis, the trim is applied to the flight control directly even when there’s no airflow.
With sufficient airflow, there will be no difference in behavior whatsoever between both types of trim.
For hardware makers and cockpit builders
In the past, using control loading hardware in combination with anything but a trimmable horizontal stabilizer required editing the aircraft to have 0 elevator trim range to get realistic control loading behavior.
In X-Plane 12, the flight control hardware instead can configure an axis as control loaded, by adding the keyword “ffb” to the axis definition in its .joy file, like so:
This would signify a flight control hardware where the pitch axis is control loaded, but not the roll axis. The throttle axis is reversed. The keywords “reverse” and “ffb” can also be used together if necessary.
Signifying the axis as control-loaded, X-Plane will expect the control loading software to read the respective trim datarefs, and provide forces to center the axis according to trim. X-Plane will not try to second-guess the control loading software and will not apply any center offset due to trim on its own.
X-Plane knows two different types of VNAV, which can be described as “GA” and “Airliner”-type VNAV. The main difference is the availability of auto-throttle. “GA” without auto throttle can only do geometric descents – the vertical path is controlled by the autopilot, while the pilot controls the speed by the throttle (or speedbrakes). “Airliner” with auto-throttle uses the auto-throttle to set climb power in climb, hold the selected cruise speed in cruise, and comply with speed restrictions (if physically achievable) in descend.
VNAV climb and cruise
For Airliner-VNAV to be selected (dataref sim/cockpit2/autopilot/fms_vnav or command sim/autopilot/FMS) in the climb or cruise phase requires the plane to have auto-throttle. Upon selection in the climb phase, the autopilot vertical axis will be speed-by-pitch, and the autothrottle will go to REF mode. The target speed is provided by the FMS, and the target altitude will be the lower of sim/cockpit2/autopilot/altitude_dial_ft and sim/cockpit2/autopilot/altitude_vnav_ft. Upon level-off, the next climb will be automatic if the level-off was due to a VNAV restriction (ALTV) or must be initiated manually by altitude intervention if the level-off was due to pilot pre-selected altitude (ALTS).
If the selected cruise-altitude has been reached, the FMS goes into cruise phase. VNAV will be altitude hold on the vertical axis, and speed or mach hold on the auto throttle axis.
VNAV descent: G1000
VNAV descent works by arming the VNV PTH function on the G1000 by pressing the VNV button (sim/autopilot/vnav). The dataref sim/cockpit2/autopilot/vnav_status will indicate 1 for armed. The autopilot will monitor the vertical track error (sim/cockpit2/radios/indicators/fms_vtk_pilot) which must be intercepted from below. Also, the vertical track must be intercepted within 5 minutes (300 seconds) from arming VNAV. VNAV will not intercept a vertical track after that time, it needs to be re-armed in this case.
If the vertical track is intercepted within the time limit, VNAV will engage and follow the vertical path angle (sim/cockpit2/radios/indicators/fms_vpa_pilot) down to the flight plan target altitude (im/cockpit2/radios/indicators/fms_fpta_pilot). The descent rate will be modulated according to the forward speed and the vertical track error.
The autopilot will level off at the higher of pre-selected altitude (sim/cockpit2/autopilot/altitude_dial_ft) and VNAV target altitude(sim/cockpit2/autopilot/altitude_vnav_ft):
If the level off is caused by a pilot-selected altitude, the indicated level-off will be “ALTS” (selected) and VNAV will be disarmed. For a subsequent descent segment, VNAV needs to be re-armed.
If the lebel off is caused by the VNAV target altitude, the indicated level-off will be “ALTV” and VNAV will revert to armed. Thus, a new descent segment will be captured automatically.
VNAV descent: Airliner FMS
The behavior of the airliner FMS depends on the per-airplane setting “auto-arm VNAV descent” which is found on the autopilot settings page of Plane Maker. If Airliner-VNAV is selected (dataref sim/cockpit2/autopilot/fms_vnav or command sim/autopilot/FMS) and the plane comes close to the top-of-descent:
With “auto-arm VNAV descent” selected, the VNAV descent is armed automatically when the plane comes close to the calculated top-of-descent and VNAV will intercept the vertical track automatically, provided that a lower altitude is selected in the autopilot altitude window (sim/cockpit2/autopilot/altitude_dial_ft). This is the behavior found in Boeing airliners.
Without “auto-arm VNAV descent”, the autopilot must be allowed to initiate VNAV descent by either selecting “DES NOW” from the FMS or by pressing altitude intervention (sim/autopilot/alt_intv) following a lower altitude in the autopilot altitude window (sim/cockpit2/autopilot/altitude_dial_ft). Only then will the vertical track be intercepted. This behavior is found on Airbus airliners.
Note that the above mentioned behavior applies both to the initial descent from cruise altitude, and for all descents from intermediate level-offs, provided that those level-offs came from a VNAV altitude (ALTV) and not from a pilot pre-selected altitude (ALTS). In case of initiating descent from an ALTS level-off, the selected altitude must be lowered and altitude intervention must be pressed in order to re-engage VNAV descent.
Note that FMS VNAV uses geometric VNAV for the descent phase, so you will see both “sim/cockpit2/autopilot/fms_vnav” and “sim/cockpit2/autopilot/vnav_status” be used in that phase of flight.
Enroute vs Approach VNAV
Enroute VNAV is used up to the waypoint designated as the final approach fix. It will observe the pre-selected altitude (sim/cockpit2/autopilot/altitude_dial_ft) and never descend below it.
Approach VNAV is used after the waypoint designated as the final approach fix. It can be used to descend away from and under the pre-selected altitude, just like an ILS glide slope. This allows to set the pre-selected altitude to the missed-approach altitude while the airplane is descending to minimums.
LNAV/VNAV approach in general aviation aircraft
In small aircraft, approach guidance for RNAV (GPS) approaches is provided from the GPS unit or integrated glass cockpit (G1000) to the HSI source selector. It is imperative to set the source selector to GPS1 or GPS2 for an RNAV approach, and NAV1 or NAV2 for a VOR/LOC approach. In any case, the autopilot approach mode (LOC+GS) is used to track lateral and vertical paths. This is regardless whether the approach sensitivity is LNAV+V (advisory glidepath derived from WAAS altitude), LNAV/VNAV (WAAS-altitude glide path) or LP+V (localizer performance with advisory glide path, where the final approach course is derived from the FAS block and the glide path is derived from GPS altitude) or LPV (localizer performance with vertical guidance, both final approach course and glide path are provided by the FAS-block). In all cases, the lateral and vertical offset displayed on the CDI or HSI selected by the source selector will mimic and ILS and be intercepted by the autopilot as such. Height information in all cases is derived from WAAS altitude, so the barometric altimeter setting has no influence on the vertical path.
LNAV/VNAV approach in airliners
How the airliner autopilot tracks an approach not using ground-based (VHF) navigation depends on the setting of “Integrated Approach Navigation” on the autopilot system page in Plane Maker. This setting will be 0 for older 737s, 747s up to -400, 757, 767 and 777. It will be 1 for newer 737s, 747-800s, 787s and most Airbus airliners.
LNAV/VNAV approach without integrated approach navigation
In airliners, approach course guidance for RNAV and RNP approaches is provided from the FMS unit. Vertical guidance can be provided based on barometric altitude (baro-VNAV) or from WAAS depending on the type of approach. So whether the correct altimeter setting actually influences your vertical path, depends both on the type of approach selected and the preferred vertical source selected on the FMS arrival page.
Both lateral and vertical guidance are available through the GPS1 and GPS2 source, however, the source should never be selected with the HSI source selector. In most airliners, the HSI source defaults to the on-side VHF NAV receiver, and the autopilot VLOC/APP mode will follow only that source. To follow LNAV without touching the source selector, the autopilot should be in GPSS (LNAV) mode (dataref sim/cockpit2/autopilot/gpss_status and command sim/autopilot/gpss) which it will have been for most of the cruise flight. To follow approach VNAV, whether barometric or WAAS, the autopilot should be in FMS VNAV mode (dataref sim/cockpit2/autopilot/fms_vnav and command sim/autopilot/FMS).
Summary: To intercept and fly the final approach of an RNAV or RNP approach, the MCP will have LNAV (GPSS in X-Plane speak) and VNAV (FMS VNAV in X-Plane speak) selected, and the FMA will display LNAV and VNAV PTH. This type of approach navigation is found in older 737s, 747s up to and including the -400, 757, 767 and 777 airliners.
LNAV/VNAV approach with integrated approach navigation
A different way to deal with FMS-provided lateral and vertical cues during the approach phase is to “hijack” the LOC/APP modes of the autopilot and provide guidance “as-if” an ILS signal was present. Then, the pilot selects the approach button and the behavior will be the same for all types of approaches.
The corresponding on-side NAV signal will be overridden with FMS-provided LNAV/VNAV whenever an approach is loaded in the FMS that does not use VHF navigation and the active waypoint sequences to the final approach fix.
In this case, the autopilot will be in LNAV (GPSS) mode or in heading mode while approach is armed – the autopilot will automatically intercept the final approach course, deactivate LNAV (GPSS) mode and fly in APP mode laterally. Vertically, the autopilot can be in FMS VNAV mode or in altitude hold mode and will automatically intercept the vertical track, deactivate FMS VNAV mode and fly in APP mode vertically.
Summary: To intercept and fly the final approach of an RNAV or RNP or LPV or GLS approach, the MCP will have APP selected, and the FMA will display FAC and GP. This type of approach navigation is found in newer 737s, 747-800s, 787s and new Airbus airliners.
Comments Off on Autopilot VNAV modes and PlaneMaker settings
Real world ATC is all about efficiency – runway space at major airports is limited, so ATC aims to use the existing runways, taxiways, and airspace in the most efficient manner to arrive and depart as many planes per hour as possible. The “flow” system in WED/X-Plane aim to model real world procedures that were designed for real world efficiency.
An airport ATC “flow” defines how the runways in an airport are used. Each flow tells ATC:
Which runways are used, and in which directions
Whether the runway is used for takeoffs, landings, or both
What kinds of planes use which runways.
Real world flows are often named after the direction of traffic, e.g. “east flow” and “west flow” but these names are never exposed to pilots. In the same manner, WED’s flows are named for reference and log output only and are never displayed to X-Plane users.
Flows are picked based on wind and weather conditions so aircraft can land and take off into the wind. They are also sometimes based on noise abatement – the route the aircraft flies may be restricted to not fly over residential areas at low altitude and high power.
Only one “flow” is used at an airport at a single time – each flow is designed so that all of the runways used in the flow can be used at the same time safely to have maximum efficiency at the airport. A very common misconception is that you need to add one flow per runway; this is not true! You should add one flow per set of conditions, and each flow should contain all runways that are active under those conditions. This implies that a flow is not picked per-aircraft at the time when that aircraft requests runway access; flows do not reference aircraft properties at all.
While X-Plane doesn’t move as many airplanes as KORD, we support the same kinds of rules for realistic routings and flow.
A detailed example: KBOS
Boston Logan has five runways that it uses for major operations: two parallel runways (4L/4R), two near-parallel runways (33L and 32) and one additional runway (9). The airport also has a noise restrictions: no aircraft ever land on runway 14 or depart on runway 32.
Based on this, KBOS has four possible main flows:
“Northeast” VFR flow:
Jets land on 4R
Jets depart 4L and 9
Heavy jets depart 4R
Props land and depart 4L
“Southwest” flow:
Jets land on 27
Jets depart 22R
Heavy jets depart 22L
Props land 22L and hold short of 27
“Northwest” flow
Jets depart 27
Heavy jets depart 33L
Props depart 27
Jets land 33L and 27
Props land 34
“Southeast” flow
Jets land 15R
Props land 15R and 15L (15L is tiny)
Jets depart 15R
Props depart 14
These flows are ordered from most efficient to least efficient for the airport. The southeast flow is a huge bottleneck because KBOS can’t land on runways 9 or 14; all planes have to land on one runway. It is also hard for ATC to land a prop behind a jet because of wake turbulence rules and the difference in speeds. By comparison the northeast flow provides the highest operations rate, with jets landing parallel to props (with each stream of aircraft packed tightly) and room for completely independent departures on runway 9.
Flows in WED & X-Plane
Selection Rules and Priority
The main rules for flow selection in X-Plane are:
Only one flow may be active at a time.
X-Plane will evaluate each of your flows in the order they appear in WED – the top flow in the hierarchy is evaluated first.
The first flow in which all of its rules pass is selected. No further rules are considered.
This means flows should be arranged in WED with care, and generally with the most selective flow first. Where multiple general flows exist, they should be arranged with the most efficient first. In our KBOS example, you would want to arrange the flows in WED in the order they’re listed above (ordered by high to low efficiency).
If no flows are usable – that is, if none match the current conditions – then the airport will be seen as temporarily closed. X-Plane treats airports closed by time rules alone as if they are normal, overnight closures.
It is advisable to always have a “low wind” flow as your first flow, such as 000-360 at 5 knots or less. In light and variable wind conditions, this will ensure that the flow remains stable (i.e. the airport does not continually want to change the active flow) if the wind direction changes rapidly. With continual small wind variations, a wind from 035 at 1 knot may rapidly change to 220 at 2 knots, then back to 040 at 1 knot. With a low-wind flow as the first one, which effectively ignores wind direction, other flows which do depend on wind direction will not be active until the wind is at least 5 knots (in this example) which should be enough to not be affected by small-scale variation.
Each airport has flows evaluated at the point when it is fully loaded into the simulator, typically when it’s within 100 miles or so. Environmental conditions at each airport are re-evaluated frequently to detect if a flow change is needed, but the system will also not change flows too frequently since this is disruptive to aircraft operations. Flow changes may also be delayed by aircraft taxying out, or those within a short time of landing.
Flow basics & rules
Each airport in WED should have one or more flows, ideally more than one. If no flow is provided, X-Plane will generate a basic set of flows aligned to the longest runway and, if necessary, at 90 degrees to it. Parallel and near-perpendicular runways are handled, as are separate low-vis flows for ILS-capable only runways if they exist. To make sure that your airport moves traffic the way you intend though, you should define and test your own flows.
To create a flow in WED, select the airport and use the “Airport→Create Airport Flow” menu.
Flows contain two kinds of data. To add these in WED, select the flow first.
Restrictions that control whether the flow can be used at any given time in the sim (time, vis & wind rules)
Runway Use rules tell which runways will be usable by arriving and departing aircraft, if the environmental rules are passed.
Runway Use Rules
Each flow has one or more “Runway Use” entry that describes a particular runway with use restrictions. These can be added in WED by selecting a flow and using the “Airport→Create Runway Use” menu.
Runway Use rules describe:
The end of the runway to start from
Departure frequency for aircraft departing from this runway using this rule (mobile X-Plane only)
Whether it is used for arrivals, departures, or both
The type of aircraft operations
Departure direction range
Initial assigned heading range
Flows also have a “pattern” runway for VFR traffic patterns. You must still include a runway use – just having the traffic pattern runway will not make that runway used. (The VFR pattern runway on the flow doesn’t tell us what kinds of planes use the runway, etc.)
The runway use rule for the pattern runway should include both arrivals and departures. But do not set a flow to allow arrivals (or departures) on both ends of a runway, or you risk head on collisions! For example, do NOT arrive on 4R AND arrive on 22L. In the majority of cases, if a runway allows arrivals and departures at the same time they will go the same direction and use the same runway.
It is okay to have a runway in a flow more than once – you might need this for complex rules.
From X-Plane 12.1.3, ATC will try to use all available runways in a given flow; before 12.1.3, only the first runway in any flow that meets the current aircraft’s requirements is used.
A single flow containing runways which intersect is normal and expected.
In this case we need to use the 4R runway use twice. For arrivals jets and heavies land 4R, but for departure, ONLY heavies use 4R. The logic behind this case is the heavies need the long runway 4R for departure, but the jets can depart runway 9 for more operations.
You can set this example up in WED two different ways with the same result.
Option 1:
Create a use rule and set traffic type to Jets & Heavy Jets
Set Operations to Arrivals only
Create another use rule
Set traffic type to Heavy Jets
Set operations to departures
Option 2:
Create a use rule
Set traffic type to Heavy Jets
Set operations to departures & arrivals
Create a new rule
Set traffic to Jets
Set operations to arrivals only
The departure frequency field is required but is not fully implemented in X-Plane. In X-Plane desktop version, the relevant frequency at any moment is determined based on nearby controllers’ airspace and this value is ignored.
Runway Uses also include the departure direction range. This is the rough direction from the airport that the aircraft will fly (e.g. if we depart KBOS for San Francisco, our direction is west). This is specified in the Legal on-course hdg min/max in WED. Given two runways that can both depart an aircraft, X-Plane will pick a runway based on departure direction when possible. This lets you specify things like “north departures use 27R, south departures use 27L”, to avoid aircraft crossing in-air. Take care to specify these ranges clockwise; a range of 315 to 045 would mean aircraft departing within 45 degrees of north would be preferred, while a range of 045 to 315 would prefer aircraft departing within 135 degrees of south.
Runway uses also contain an initial heading. These are the ATC Assigned hdg min/max fields in WED. This is the heading that ATC will assign the aircraft off of the runway – it can be a range so that ATC can “fan out” aircraft for faster departures. This is another case where two runway uses can be used, e.g. from our example KBOS northeast flow:
In other words, most props will depart runway 4L and head directly north. But props departing to the south or east will depart runway 9 and immediately turn south-east, getting out of the way of jets. Jets will take off runway 9 and go straight.
(The southeast runway 9 heading lets small airplanes going to Cape Cod go straight out toward their destination – the jets fly straight to get out over water and to not make noise over the city of Boston.)
Note that departure direction and initial direction do not have to match. E.g. at KBOS a jet whose departure direction is West might still get an initial direction of East – this means the plane initially flies the wrong way (usually for noise abatement) and is then turned around.
Time, wind and visibility rules
Flow rules come in three flavors:
Time rules define during what times of day the flow may be used. Time is given in HHMI format in Zulu time, not local time.
Wind rules define under what wind conditions the flow may be used.
Visibility rules define what visibility is required to use the flow; this is defined as part of the flow itself rather than a separately-defined rule.
You can have more than one wind and time rule for a flow; if you do, the flow will pass if any of the rules of that type pass. In other words, you can do this:
Flow “northeast”
Wind < 4 knots, 0-360
Wind < 15 knots, 270 – 090
Flow “southwest”
Wind < 15 knots, 090 – 270
In other words, if the wind is less than four knots or the wind is coming from the north, we use the northeast flow. This “or” behavior is useful because often airports will use the most efficient flow when the wind is very low.
Similarly, the time rules can have more than one time, e.g. for two peak periods.
For all weather-related rules (wind, visibility), you specify the ICAO code of a METAR reporting station. For major airports, this is the airport’s ICAO, but for small satellite airports, you can use the ICAO code of a larger nearby airport. This is for cases where a small GA airport’s runway use must be changed to affect the runway use of the neighboring large airport, or where several airports must adjust their runway uses all at once due to proximity.
Typically an airport with multiple runways will have higher priority “VFR” flows with higher visibility requirements and multiple runways in use, and then lower priority “IFR” flows with no visibility requirements. This lets X-Plane’s ATC use more runways in good conditions and just one runway in bad conditions. The same may apply for low/high wind situations.
Manually Checking Flows
The best way to debug your flows is to set a number of AI aircraft running and watch them, occasionally manually changing weather conditions to those which you think should activate different flows. You can of course check ‘manually’ by disabling AI (just to prevent flows being held unexpectedly), setting appropriate weather conditions, selecting an aircraft of a given type (i.e. prop, jet etc.), and requesting departure clearance from a gate start – not an on-runway start because these are handled slightly differently – or landing clearance from an in-air start.
You can also perform a quick check using ATIS if the airport provides this, since this will give you the active runways. From 12.1.3 onward, active runways are also shown on the map if you zoom in to the airport you wish to check.
To work out which flow should be used, start reading from the top of the list in WED and work down one line at a time. Select the flow, and check that any conditions there are satisfied (i.e. ceiling and visibility). Remember to check the weather the airport is actually reporting, because even with static weather set in the simulator, there are local variations in wind direction, speed and visibility. You might have set a 3kt wind to check a flow which has a wind restriction at 4kt, but if the random local wind variation only adds a single knot then your ‘low wind’ flow will not be used.
If the flow itself passes, check any time or wind restrictions. As long as one restriction from each type passes, the flow is accepted. Of course, if no restriction is given, the flow is also accepted. For example, if you have two wind restrictions and no time restrictions, then the flow will be used if either wind restriction passes.
It is permitted to have flows that define periods when the airport is closed. For example, smaller airports may only be usable during business hours.
At this point, if the flow has passed all the restrictions then this flow is the one that will be used. No other flow will even be considered. If the flow has not passed, read the next flow in the list, in order. If you reach the end of the list without any flow passing, the airport is also seen as closed.
Once you have identified which flow is in use, check each individual runway inside the flow in order from top to bottom. To be usable for a specific aircraft, that aircraft has to match the Traffic Type restriction. If no runway exists in this flow which satisfies that aircraft’s type and the type of operation (i.e. arrival or departure), then the aircraft will be unable to land or depart. No other flow will be considered.
Before X-Plane 12.1.3, the first runway that matches will be used; from 12.1.3 on, any runways that are usable for this aircraft type and purpose will be considered based on other conditions such as proximity and usage levels.
Example
These flows are from an airport which has six flows defined for two usable and parallel runways, 05/23 and 05R/23L . The first two flows are shown here:
The first flow, “Runway 23”, declares that when the wind is at 4kts or lower from any direction or less than 40 knots from somewhere between 150 and 320 degrees, runway 23 and only runway 23 should be used. The runway is restricted to only Jets and Turboprops, which means that the airport is inaccessible for props, helicopters, heavies and fighters.
Firstly, the flow is probably incorrect, because there is also a runway 23L which will never be used at all. In fact, two additional flows exist – one for 23 and one for 23L – neither of which will ever be used because they have identical wind restrictions to “Runway 23” and come after it in the list. This particular airport is popular with GA, so disallowing props is also incorrect – but a likely explanation follows.
The next flow, “Runway 23 Light”, will never be used because there is no circumstance where it satisfies restrictions that are not also satisfied by “Runway 23”; the only difference is the wind restriction, and it is more restrictive (20kts vs 40kts). “Runway 23 Light” allows the runway to only be used by props and helicopters so even if this flow were to be used, which is impossible, it would prevent jets and turboprops from landing if the wind speed was less than 20 knots. Remember that only one flow is ever in use at any time so if no runway in the currently active flow can service your aircraft, you’re out of luck!
In general, if you have considered naming your flows after runways and you have more than one runway, the flows are probably wrong.
What would be more appropriate would be to define four flows for this airport:
W Light, covering runways 23 (a long tarmac runway) and 23L (a shorter grass runway), with “Wind 4@0-359” and “Wind 20@150-320”, with jets and turboprops assigned to runway 23 and props and helicopters assigned to 23L. Heavies should probably remain excluded; fighters are a trickier question because even a WW1 biplane could be defined as a fighter.
W Normal, covering runway 23 only, with “Wind 40@150-320”, again with jets and turboprops assigned to runway 23. This would close the airport to helicopter and small GA aircraft when the wind was above 20 knots, but leave it open for more powerful aircraft.
E Light, a copy of “W Light” but using runways 05 and 05R and with a single wind restriction for “Wind 20@320-150”. It would be pointless to include “Wind 4@0-359” because it has already been satisfied by “W Light”.
E Normal, a copy of “W Normal” using only runway 05 and the wind direction reversed to cover “Wind 20@320-150”.
Debugging Flows and Flow Changes
When the weather changes, X-Plane will wait at least one minute before beginning to change flows. When it starts to change flows, the sim goes through three phases:
Departure drain. All new departures are held, but existing departures are allowed to depart using the old flow. All arrivals continue to arrive using the old flow.
Arrival drain. Once the number of non-held departures falls to zero, all arrivals not on final are re-routed to the new flow. Existing arrivals are allowed to land on the old flow.
Complete change-over. Once the existing legacy arrivals have landed, the new flow is fully in effect and the ground hold is lifted.
Note that if the weather changes back to the old flow in phase 1, the old flow is resumed; if the weather changes back in phase 2, we continue to the new flow.
The logic behind step 1 is: we have to let all taxiing departures depart on the old runway because there might not be enough room for aircraft to turn around on the pavement. While this is happening we don’t re-route arrivals to avoid a head-on collision. The logic behind step 2 is: as long as pending arrivals are arriving in the old runway, we can’t release the gate hold because the departing aircraft might block the arrivals’ route to the gate.
By default the ATC system logs some information about flow changes to Log_ATC.txt, but you can turn on advanced and detailed logging by setting the art control atc/debug/rwy_flow to 1. Detailed logging starts after the art control is set. Log_ATC.txt can be viewed in real-time using the “developer console” menu item in the Special menu.
You can also view more details about runway selection by setting the art control atc/debug/rwy_selection to 1.
