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)
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:
Axis 2: joy_use_roll
Axis 1: joy_use_ptch ffb
Axis 0: joy_use_thro reverse
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.
VNAV vs. FMS altitude
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.
The datarefs inside the sim/flightmodel2/wing/ are array indices for each wing on the plane. To understand how these array indices work, we need to consider how X-Plane manages “wings”.
Everything is a wing
In X-Plane, all airfoils (except for those that form propellers and pylons) are “wings”. This includes:
- 8 regular “wings”, each of which comes 4 pairs of left-right.
- 2 horizontal stabilizers, left and right.
- 2 vertical stabilizers (rudders).
- Up to 20 “misc” wings.
For the purpose of this tech note we will use the term ‘wing’ to mean any one of these airfoils.
Each wing is assigned as being on the left or right side of the plane – this is how X-Plane knows whether a left roll moves the ailerons on this part up or down. Left right assignment is automatic for the regular wings and stabilizers, and manual in Plane-Maker for misc wings. (Vertical stabilizers are categorized as right wings, but in practice you should assume that ailerons on vertical stabilizers is a poor idea in X-plane — use a misc wing if you really need this, or tilt the horizontal stabilizers up like the cirrus jet).
Each wing may or may not be used in the actual plane, and if it is used, it is defined into a fixed number of slices running laterally across the airfoil. The airfoil properties are fixed for each wing, but the control surfaces can be set per slice. The control surface deflections and longitudinal geometry (e.g. how deep are the ailerons, where on the wing do the flaps sit) are set globally.
Now here’s where the array comes in: X-Plane calculates one control deflection for:
- Each type of control (rudder 1, rudder 2, aileron 1, aileron 2) crossed by
- Each actual existing wing
Individual control surfaces are then deflected on a per-slice basis by looking up the deflection for that part.
Two sets of everything
X-Plane features two sets of most controls (flaps, ailerons, etc) to allow for different maximum deflections and longitudinal positions. A number of other advanced control surface options can act differently on each set. For example, a plane might have a “small” set of ailerons on the far edge of the wing with small deflections and a small longitudinal size. A second set might be on a different part of the wing with larger deflections and larger longitudinal length.
Wing to Array Index Table
The mapping of array indices to wings is:
0 Left wing 1
1 Right wing 1
2 Left wing 2
3 Right wing 2
4 Left wing 3
5 Right wing 3
6 Left wing 4
7 Right wing 4
8 Left horizontal stabilizer
9 Right horizontal stabilizer
10 Vertical Stabilizer 1
11 Vertical Stabilizer 2
12 Misc Wing 1
13 Misc Wing 2
14 Misc Wing 3
15 Misc Wing 4
16 Misc Wing 5
17 Misc Wing 6
18 Misc Wing 7
19 Misc Wing 8
20 Misc Wing 9
21 Misc Wing 10
22 Misc Wing 11
23 Misc Wing 12
24 Misc Wing 13
25 Misc Wing 14
26 Misc Wing 15
27 Misc Wing 16
28 Misc Wing 17
29 Misc Wing 18
30 Misc Wing 19
31 Misc Wing 20
Using the Wing Datarefs For Animation
The rules for animating via the wing datarefs is:
- use the control deflection array index that corresponds to the part of the wing you are really animating! This addresses several possible problems:
- If the wing you animate is not on the same side of the plane as the dataref index you use, you could have an inverted animation.
- If the wing is not present at all, the dataref might not move at all.
- use the right TYPE of dataref. To animate an aileron that matches aileron 1 in position, use aileron1_deg, not aileron2_deg, yoke_roll, or any other “proxy”. By using the exact right dataref, you guarantee that the animation matches all of X-Plane’s behaviors.
- Do not nest animations!!! X-Plane’s wing control deflection outputs in this dataref are the sum of all control surface activity. For example, if you have a plane that maps ailerons to spoilers at low speed and speed brakes to spoilers, then when both are in effect the spoiler1_deg dataref will be the sum of all deflections. You do not need to nest animations to add up multiple control influences.
- Use the special controls in PlaneMaker to achieve effects like roll spoilers – this way you can follow the rule above.
Custom Control Deflections Via Plugins
X-plane can write different controls deflections into different wings, if certain hydraulic system failures or other conditions apply. It is possible for plugins to override sim/operation/override/override_control_surfaces. At this point a large number of datarefs are under plugin control including the wing offsets. In this scenario, a single wing (but not a slice of a wing) could have a deflection that varies from all other parts.
In this way, it is possible to have up to 8 different speed-brake panel deployments (for example) on a single (4-part) airliner wing: a plugin would simply write a different value to each of speedbrake1_deg and speedbrake2_deg for each of the 4 left wings.
In this case it is particularly important for the animated model to match the right array index.
Sim/cockpit/autopilot/autopilot_state
The autopilot state dataref summarizes all state and mode information from the autopilot.
Summary of Values
The following table summarizes all bit-field values.
| Bit field (Decimal) |
Bit field (Hex) |
Name |
Axis |
Notes |
| 1 |
00001 |
Autothrottle Speed Engage |
Throttle |
When the pitch axis is NOT speed-by-pitch, holds airspeed or mach number by manipulating the auto-throttle servos. |
| 2 |
00002 |
Heading Select Engage |
Lateral |
Flies the selected magnetic heading. |
| 4 |
00004 |
Roll Hold Engage |
Lateral |
Holds the selected bank (roll) angle. |
| 8 |
00008 |
Speed-by-pitch Engage |
Vertical |
Holds the selected airspeed or mach number by manipulating pitch. Does not touch the throttle to do so. Note that when altitude is armed, this will be limited in pitch to the direction the pre-selected altitude is from the current altitude. For a true speed-by-pitch regardless of altitude, altitude hold must not be armed. |
| 16 |
00010 |
V/S Engage |
Vertical |
Holds the selected vertical speed. |
| 32 |
00020 |
Altitude Hold Arm |
Vertical |
Before X-Plane 8.11, altitude was “always armed” – that is, setting this would engage altitude immediately. In X-Plane 9.0, altitude was always armed. In 9.20 and 9.30, this was incorrectly mapped to “altitude engage” when written to. Now this correctly maps to the arm only. Note that an aircraft might still specify “altitude is always armed” in Plane Maker. |
| 64 |
00040 |
Flight Level Change Engage |
Vertical |
Speed-by-pitch in combination with altitude preselect armed. |
| 128 |
00080 |
Pitch Hold Engage |
Vertical |
Holds the selected pitch angle. |
| 256 |
00100 |
Nav Armed |
Lateral |
Arms tracker/coupler to track a nav source (VOR radial, localizer or GPS course). |
| 512 |
00200 |
Nav Engaged |
Lateral |
Tracker/Coupler tracks a nav source. Writable with overwrite – see below. |
| 1024 |
00400 |
Glideslope Armed |
Vertical |
Arms vertical track of a nav source (ILS glide slope or GPS glide path). |
| 2048 |
00800 |
Glideslope Engaged |
Vertical |
Tracks a vertical nav source (ILS glide slope or GPS glide path). Writable with overwrite – see below. |
| 4096 |
01000 |
VNAV Speed Armed |
Vertical |
Speed-by-pitch mode to achieve FMS-selected speed to climb or descend to VNAV altitude or MCP altitude, whichever is more restrictive. Armed below 400ft. |
| 8192 |
02000 |
VNAV Speed Engaged |
Vertical |
Speed-by-pitch mode to achieve FMS-selected speed to climb or descend to VNAV altitude or MCP altitude, whichever is more restrictive. Writable with overwrite – see below. |
| 16384 |
04000 |
Altitude Hold Engaged |
Vertical |
Starting with X-Plane 9.40, you can directly engage the autopilot in this mode. See below. |
| 32768 |
08000 |
TO/GA |
Lateral |
Since X-Plane 9.30. Holds wings level in take-off or go-around phase. |
| 65536 |
10000 |
TO/GA |
Vertical |
Since X-Plane 9.30. Holds pre-determined pitch in take-off or go-around phase. |
| 131072 |
20000 |
VNAV Path Armed |
Vertical |
Since X-Plane 9.40. Arms geometric descent. Use in conjunction with G1000 providing descent cues. |
| 262144 |
40000 |
VNAV Path Engaged |
Vertical |
Since X-Plane 9.40. Flies geometric descent. Use in conjunction with G1000 providing descent cues. Writable with overwrite – see below. |
| 524288 |
80000 |
GPSS Engaged |
Lateral |
Since X-Plane 11.10. Tracks GPSS regardless of HSI selected nav source. Use this to fly in LNAV mode while being able to arm Nav mode for localizer interception. |
| 1048576 |
100000 |
Heading Hold Engaged |
Lateral |
Since X-Plane 11.10. Holds Heading at the time of engagement, ignores heading bug. |
| 2097152 |
200000 |
Turn Rate Engaged |
Lateral |
Since X-Plane 11.30. Holds turn rate (as indicated by turn coordinator) instead of bank angle. |
| 4194304 |
400000 |
Track Engaged |
Lateral |
Since X-Plane 11.30. Holds magnetic ground track corrected for wind. |
| 8388608 |
800000 |
Flight Path Angle Engaged |
Vertical |
Since X-Plane 11.30. Holds flight path angle. |
Axis Exclusivity
The above table lists various “axes”. Basically the internal autopilot can be in only one mode per axis. Those modes are:
- Lateral – this mode controls the heading of the airplane.
- Vertical – this mode controls the pitch of the airplane. Note that speed-via pitch is a vertical mode, because the plane’s vertical path will change as necessary to hit a target airspeed.
- Autothrottle – this mode controls how the AP interacts with throttles – currently it is effectively boolean (autothrottle is “on” and will try to maintain target airspeed via thrust, or it is “off”). – For more modes, see sim/cockpit2/autopilot/autothrottle_enabled
FMS – the FMS mode is a hack: basically the FMS mode tells whether the FMS will copy current FMS target altitudes into the autopilot windows. No real-world airplane works like this, but X-Plane has had this ability as a poor-man’s way to fly a flight plan since X-Plane 6. Discontinued in X-Plane 12.
Note that back-course is not an axis – use the dataref sim/cockpit/autopilot2/backcourse_on or the command sim/autopilot/back_course.
Changing Dataref Values
Starting in X-Plane 740, this dataref can be written.
To change a dataref value, follow these rules:
- Write ONLY the bit you want to toggle! If you want to toggle altitude hold arm, write only “32” to the dataref.
- If you want to change modes in a certain sequence, write to the dataref multiple times. If you write a combined set of bits, the order that the commands are “executed” may not be predictable. For example, engaging heading mode normally clears localizer arm. So to set up for an approach, you want to first set only heading mode, then set only localizer arm. Otherwise, when setting both, there is a chance that the implementation could arm the localizer first, then set heading mode, which would clear the localizer arm.
- Some modes will cancel other modes automatically. In particular, the sim must maintain exactly one lateral and vertical mode. So for example, engaging heading mode will clear out any of: wing leveler, HNAV. So in order to sanely write to the autopilot, you need to understand the “operational” meaning of each change, not just what lights you want to light up. (See below on overrides for more info.)
If you are not using overrides to completely replace the AP logic, you can accomplish the same effect as any bit-set by using the command system – see XPLMUtilities for more info. We strongly recommend all 2.0 plugins use the command system for maximum compatibility. If you are trying to simulate the pilot pressing a button, use the command system!
Starting in X-Plane 940, it is possible to set the “engage” bits directly – see Overriding the Autopilot Mode below.
Arm Vs. Engage
Some autopilot modes can be “armed”. In armed mode, when the AP mode changes are not overridden (see below) the AP will remain in its old mode, but will be “armed” – that is, listening for a chance to change modes later.
The most typical example is the localizer. When you arm HNAV mode to join a localizer, your lateral mode does not change. (That is, you are still flying via wing leveler or heading.) At a later time, when the localizer signal becomes available to the nav receiver that the AP is listening to, the AP will automatically engage HNAV mode, which naturally replaces the old lateral mode.
Arming state is not a mode on an axis, so arming is not mutually exclusive with other AP functions. You can arm everything at once if you want. Arming is permission for X-Plane to change modes later under certain conditions.
- Altitude hold arm will engage altitude hold when the plane reaches the target altitude dialed into the AP dash.
- NAV arm will engage when the AP crosses the lateral path we are going to follow (a localizer, GPS course line, etc).
- Glideslope arm will engage when we cross the glide slope or GPS glide path from below with signal.
- VNAV arm will engage when the AP crosses the vertical path we are going to follow (a geometric descent as part of a STAR for example).
Arm Vs. Engage For Altitude Hold
Unlike most other “arm” functions, it is actually possible to either arm or directly engage altitude hold mode, via two different commands (or bits in this dataref). Here is the difference in their operation:
- Altitude hold engage: when altitude hold is engaged and we are not currently in altitude hold mode the autopilot will automatically stop climbing/descending and set the altitude-to-hold to the current altitude. Think of this as a “stop now” button.
- A plane-maker setting will cause X-Plane to optionally reset the altitude hold window on the AP dash to the current altitude.
- Altitude hold arm: this simply arms altitude hold but does not engage altitude hold mode. The current altitude in the AP dashboard window is not changed.
- Plane-Maker has an option to always engage pitch-hold mode when altitude arm is commanded.
- Plane-Maker has an option to re-arm altitude hold mode in a wide variety of situations. Real G1000 planes are like this: you can’t turn off altitude arm unless you are on a glide slope or GPS vertical approach. This can be thought of as a safety feature: because alt-hold is always armed, the airplane can never climb or descend in an unbounded manner – there is always a set “stop point”.
Aliasing of Flight-Level Change With Speed Change
Starting with X-Plane 860, speed via pitch (vertical speed mode) and flight level change are no longer the same dataref. There is only one mode (“speed” mode) and the flight level change bits are aliased for compatibility. For the rest of this paragraph, we will refer to speed via pitch mode as “FLCHG” mode.
FLCHG mode interacts with the auto-throttle in the following ways:
- For legacy aircraft, When FLCHG is engaged, if the autothrottle is enabled, power is increased to 100% throttle (climb) or 0% throttle (descent). This is a throttle position – FLCHG does not target an N1 or other engine output metric. Autothrottle is disabled.
- For aircraft with the “Airliner” type autopilot selected in Plane Maker, When FLCHG is engaged, if the autothrottle is in speed mode, autothrottle goes to REF mode (climb) or RETARD (descent).
- When altitude arm moves to engage, if FLCHG had been engaged, the autothrottle was disabled or in REF or RETARD for the FLCHG mode, the autothrottle speed hold is resumed.
Overriding the Autopilot Mode
You can use the dataref sim/operation/override/override_autopilot to disable X-Plane’s ability to spontaneously change autopilot modes.
When the override is set, the sim will still change AP modes in response to plugins and user-induced commands. However, the sim will not change modes automatically in response to reaching target altitudes, arm states, etc. These must be done manually by your plugin.
Additionally, starting in X-Plane 940, if this override is set, you can write the following engage modes directly into X-Plane:
- 512 (engage HNAV mode)
- 2048 (engage glide slope mode)
- 262144 (engage VNAV mode)
Note that engaging a mode when the sim is not ready for this mode (e.g. engaging the glide slope when there is no signal) will have unpredictable consequences.
Overriding the Autopilot Nav Heading
In X-Plane 940 you can override the heading the airplane flies in “NAV” mode with sim/operation/override/override_nav_heading
When this override is set you can:
- Write to sim/cockpit/autopilot/nav_steer_deg_mag to control which way the plane flies.
- Write “512” (engage HNAV) directly into the AP state. NAV mode will go from ARM to engage immediately to fly your heading.
IMPORTANT: There is a “gotcha” about overriding only the AP nav heading: when the autopilot mode is not overridden (see above) then the sim will automatically change from “hnav engaged” to “wing leveler” when there is no signal on the current receiver as selected by the CDI.
So if you are trying to override HNAV to fly a heading while the CDI is selecting NAV1 or NAV2 radios, and those radios have no signal, your write of “512” to engage HNAV will immediately be counteracted by X-plane, which will disengage HNAV completely due to no signal.
The solution is to override both the autopilot nav heading AND the entire autopilot mode states.
Avoiding Infinite Loops
Writing to this dataref works by issuing a sim command in most cases.
This means that if you write this dataref from a command-handler that is overriding an autopilot command, there is a good chance that you will put the sim into an infinite loop, like this.
- User presses AP button.
- Panel code issues AP command.
- Plugin receives “first chance” at the command.
- Plugin writes to autopilot_state dataref.
- Dataref write handler issues an AP command. (Go back to step 3.)
To avoid infinite loops:
- Trigger commands when possible, rather than writing this dataref. This will at least make it clear when there is an infinite loop risk.
- To re-trigger the “default behavior” (e.g. user hits “hdg”, you change data, then you want X-Plane to really arm hdg) simply use the return value from the command handler to indicate that x-plane should receive. See XPLMUtilities for the command API.
- If you need to cross-call a different AP mode (e.g. user hits “HNAV” but you want to go into “HDG” mode) be sure to set a recursion-check flag if your plugin can recurse back into the original command handler code! The sim will not detect this infinite loop, it will simply hang.
Deprecated Datarefs
These are the enum mappings for the older datarefs. Please avoid using them whenever possible; they will be discontinued!
sim/cockpit/autopilot/airspeed_mode
sim/cockpit/autopilot/heading_mode
sim/cockpit/autopilot/altitude_mode
sim/cockpit/autopilot/mode_hnav
sim/cockpit/autopilot/altitude_gls
X-Plane 11.36 adds a new parameter to the steering/castor setup for nose and tailwheels, that makes it possible to add a castoring range onto a steered wheel.
Up and including to 11.35, a wheel could be one of three things:
- Fixed: a main gear wheel is usually fixed and does not steer.
- Steered: a nose or tail wheel that is actuated with a tiller or rudder linkage is steered up to a certain angle, where the maximum angle can be dependent on the speed.
- Free Castoring: on many taildraggers and also some modern tricycle aircraft like the Cirrus SR22 or Columbia 400 there is no wheel steering at all, they instead rely on rudder and differential braking to steer on the ground, with the wheel just trailing.
11.36 adds another option, that is commonly found on aircraft like the C152, C172, etc.:
- Non-rigid steering with castoring range: The wheel can be steered through rudder linkage up to a (small) deflection angle. By using differential brakes, the plane can turn tighter, in which case the wheel deflects further than it would from rudder linkage alone.
The new parameter is found in Plane Maker as: “castor limit (deg) This is the maximum amount that the nosewheel or tailwheel of the aircraft can steer from full rudder deflection and pulling the plane into a turn with differential brake. Enter zero if the nose wheel does not steer more than the rudder-linked values or the tail wheel is not limited in castoring at all.”
That means, the nose wheel steering limit (fast and slow) for the 172 is 10 degrees, as can be found in the TCDS of the aircraft (or the POH).
However, the new castor limit is 45 degrees.
Now what happens is:
- With the rudder pedal, the nosewheel is deflected with the rudder up to 10 degrees left or right.
- At 10 degrees deflection, differential braking can be used. If the differential braking causes a tighter turn, the wheel will turn in, following the steering impulse from the differential braking, and allow a tighter turn without slipping the nose wheel, to a maximum of the “castor limit” of 45 degrees.
- While in this situation, relaxing the differential braking will not immediately cause the wheel to spring back to 10 degrees. It will come out of this deflection depending on the forces that turn the plane. So you can get the plane out of the turn by relaxing the rudder pedal deflection – once the rudder is not hard over one way anymore, the springs will pull on the wheel once again, or you can increase thrust, apply brakes or even diff-brake in the other direction.
Note that all of that also works on a tailwheel as well.
For users without brake pedal axes, the “auto-toe brakes” follows the existing “left and right brake power to help with steering (if no rudder pedals present)” setting. This way, the toe brakes can be activated on full rudder deflection, leading to the tighter turn naturally.
If that parameter is 0, no auto-toe braking happens. The parameter is ignored if the user has hardware pedals with independent toe-brake axes.
Do not use the “tailwheel spring force” parameter on anything but a tailwheel any more. In the past, you could abuse it to get auto toe-braking, but you can get this explicitly with the toe brake parameter. The tailwheel spring force has unintended side effects if used on planes that aren’t tail-wheel configuration, so it must be 0 unless you actually have a taildragger with a spring steering.
Use the deflection time parameter to model the delay introduced into the nosewheel steering by a non-rigid linkage (bungee cords in a Cessna). Wheel deflection follows the rudder (or tiller) deflection with the speed constant “nosewheel steering full deflection time (sec)”. This can be used for a hydraulic actuator that takes time, or the bungees pulling the wheel around rather than a fixed linkage. That time would be 0 in a Piper with fixed linkage.
If the castor limit is 0 (which it is for existing planes not modified in Plane Maker 11.36) the nosewheel steering will work as it did before, so it is suitable for Airliners or Pipers.
If the castor limit is non-zero and applied to a castoring wheel (which has no steering angle) it will limit how far the wheel can be deflected by castoring. While not particularly useful for tail-wheels, this is useful for castoring nose-wheels, like on a Grumman or Cirrus.
X-Plane 11.35 comes with a few additions to the fuel system, in order to make it more flexible for third-party developers, hopefully removing the need to override it in many cases.
Fuel-arm for oddly shaped tanks
New to X-Plane 11.35 is the possibility to enter two longitudinal arms for the fuel tank position, one for empty and for full (by default, X-Plane just copies the arm of the empty tank to the full tank). Normally, the moment of the fuel in a tank is expressed by the arm of the fuel tank, multiplied by the fuel weight. On some planes the arm itself changes as fuel is used from an oddly-shaped tank, and the moment changes by both the weight difference and the arm difference. King Airs are notable examples of where the fuel arm changes with fuel level. By setting a different arm for the full tank, X-Plane will accurate simulate the mass and balance effect of the fuel in such tank arrangements.
Fuel pump pressure per tank setting
This is a setting in Plane Maker that has existed for a long time, even before X-Plane 11. By giving tanks individual fuel pump pressures, designers can control the order in which X-Plane is going to empty the tanks.
When multiple tanks are available according to the fuel selector setting (e.g. fuel selector to “left” with multiple tanks on the left side), the pump with the highest pressure will supply the fuel until its tank is empty. This is comparable to the system of override pumps, found for example on a 747.
New to X-Plane 11.35 is the ability to change fuel pump pressure at run-time via a dataref, allowing precise control over which tanks will be providing fuel at any given time.
For example, on a 737 the center tank pumps provide a higher pressure than the wing tanks, therefore, the center tank is first emptied before any fuel is taken from the wing tanks.
Firewall shutoff valves
Commands for the left and right firewall shutoff valves (sim/fuel/fuel_firewall_valve_lft_open, etc.) have existed in X-Plane since before version 11. X-Plane 11.35 adds data refs, too. Use them to your advantage.
Fuel tank Role – NEW to X-Plane 11.35
In addition to the pressure, a tank can now be assigned a role:
- Normal – this is the default and retains the logic directed by the pump pressure
- Feeder – this is a tank that feeds an engine and is always kept full from the other tanks on this side with an automatic transfer pump. If a feeder tank exists, the engine will only get its fuel from the feeder, while other tanks can provide fuel to keep the feeder full.
- Aux – this is the opposite of a feeder tank: it cannot feed the engine directly, but it is used to keep the feeder tank full as long as possible with the automatic transfer pump
- Trim – like an AUX tank, but never automatically transferred to or from. You need to use “fuel transfer from” or “fuel transfer to” to change this tank’s fuel level
Note that this is not necessarily what the POH calls the tank! For example, in a Cessna Golden Eagle the tip tank is called “Aux” tank, but it can be selected to feed the engine directly, with the fuel selector. Therefore, it is not an “Aux” tank for X-Plane, since that would mean it is not selectable to feed the engine directly. In order to model the preference for main or aux tank, one would use the new pressure dataref.
Note that a stabilizer tank on a 767-400ERX or a 747-400 is not a “trim” tank. Despite being in the stabilizer, it contains useable fuel for both in flight or on the ground. On the other hand, Tank 11 in a Concorde is a “trim” tank, because it cannot be filled on the ground without the plane tipping over!
Automatic transfer pumps
With tanks on each side of the airplane being configured as Feeder and Aux, the transfer pump on each side will keep the feeder tank full until the aux tank runs dry, and then turn on the “NO TRANSFER” warning light.
A feeder pump can be operated in automatic mode (where you can specify a difference that triggers the pump to operate) or override mode, where the pump runs continuously.
Automatic cross feed
This is also new for 11.35. The common crossfeed manifold allows an electric boost pump to supply pressure to the engine on the other side and thus cross-feed an engine if the on-side boost pump has failed.
If the cross feed is operated in auto mode, the same limit value that triggers the low fuel pressure annunciator will also trigger the crossfeed valve. In manual mode, the crossfeed valve can be open or closed.
Datarefs
sim/cockpit2/fuel/transfer_pump_left int y enum Transfer from left AUXes to left FEEDers: 0: Off, 1: Auto, 2: On/Override
sim/cockpit2/fuel/transfer_pump_right int y enum Transfer from right AUXes to right FEEDers: 0: Off, 1: Auto, 2: On/Override
sim/cockpit2/fuel/transfer_pump_activation float y kg Automatically transfer from AUXes to FEEDers in auto mode when feeder has more than X kg left to full
sim/cockpit2/fuel/fuel_level_indicated_left float n kg Indicated fuel level left, shows total or only nacelle tanks depending if user is holding down the aux-tank button.
sim/cockpit2/fuel/fuel_level_indicated_right float n kg Indicated fuel level right, shows total or only nacelle tanks depending if user is holding down the aux-tank button.
sim/cockpit2/fuel/firewall_closed_left int y boolean Firewall valve closed, left
sim/cockpit2/fuel/firewall_closed_right int y boolean Firewall valve closed, right
sim/cockpit2/fuel/auto_crossfeed int y enum 0=Off 1=Auto 2=On - If fuel pressure on one side is low, due to fuel pump failure for example, cross-feed is opened to allow one pump to supply pressure to both engines.
sim/cockpit2/fuel/no_transfer_left int n boolean Warning light, will illuminate when transfer from aux to feeder is requested, but aux tank is empty
sim/cockpit2/fuel/no_transfer_right int n boolean Warning light, will illuminate when transfer from aux to feeder is requested, but aux tank is empty
sim/cockpit2/fuel/transfer_test int y boolean Transfer test switch. 0 = normal, -1 = test left, +1 = test right
sim/cockpit2/fuel/tank_pump_pressure_psi float[9] y psi Pressure generated by the fuel pump per tank. If multiple tanks are accesible per the fuel selector, fuel will be consumed from the tanks in order of pump pressure
Commands
"sim/fuel/left_xfer_override" ,"Aux to feeder transfer left override."
"sim/fuel/left_xfer_on" ,"Aux to feeder transfer left on."
"sim/fuel/left_xfer_off" ,"Aux to feeder transfer left off."
"sim/fuel/left_xfer_up" ,"Aux to feeder transfer left off->on->overide."
"sim/fuel/left_xfer_dn" ,"Aux to feeder transfer left override->on->off."
"sim/fuel/right_xfer_override" ,"Aux to feeder transfer right override."
"sim/fuel/right_xfer_on" ,"Aux to feeder transfer right on."
"sim/fuel/right_xfer_off" ,"Aux to feeder transfer right off."
"sim/fuel/right_xfer_up" ,"Aux to feeder transfer right off->on->overide."
"sim/fuel/right_xfer_dn" ,"Aux to feeder transfer right override->on->off."
"sim/fuel/left_xfer_test" ,"Aux to feeder transfer test left."
"sim/fuel/right_xfer_test" ,"Aux to feeder transfer test right.
"sim/fuel/auto_crossfeed_on_open","Crossfeed valve open."
"sim/fuel/auto_crossfeed_auto" ,"Open crossfeed valve when pressure difference detected."
"sim/fuel/auto_crossfeed_off" ,"Close crossfeed valve and turn off auto-crossfeed."
"sim/fuel/auto_crossfeed_up" ,"Auto-crossfeed off->auto->on."
"sim/fuel/auto_crossfeed_down" ,"Auto-crossfeed on->auto->off."
We have always had independent left and right fuel selectors for twins as datarefs, but not as commands. These are the new commands:
"sim/fuel/left_fuel_selector_none"
"sim/fuel/left_fuel_selector_lft"
"sim/fuel/left_fuel_selector_ctr"
"sim/fuel/left_fuel_selector_rgt"
"sim/fuel/left_fuel_selector_all"
"sim/fuel/right_fuel_selector_none"
"sim/fuel/right_fuel_selector_lft"
"sim/fuel/right_fuel_selector_ctr"
"sim/fuel/right_fuel_selector_rgt"
"sim/fuel/right_fuel_selector_all"
Finally, we can now distinguish between center and aft tanks in the transfer logic, so these commands are added for the transfers:
"sim/fuel/fuel_transfer_to_aft"
"sim/fuel/fuel_transfer_from_aft"
to enable fuel transfer to and from an aft trim tank.
X-Plane 11.35’s bleed air system is an extension of the earlier X-Plane bleed air system, designed both for versatility and compatibility.
At the center of the new bleed air system is the center manifold which serves as the backward-compatible portion that is used by all airplanes, designed to provide basic bleed air and pressurization capabilities for existing aircraft.
Aircraft modernized for X-Plane 11.35 and later can make use of the left and right extensions of the bleed air system, and opt to use 1, 2 or 3 air conditioning and pressurization packs.
The system design is best understood with this diagram:
The center components provided for compatibility are clearly marked.
X-Plane legacy aircraft know only one pressurization pack, and one selector that selects the sources for this pack: left hand side of the aircraft, right hand side of the aircraft, and APU. Both APU and the center engine in a one- or three-engined plane are considered to be providing air from the center of the aircraft.
New to X-Plane 11.35 are: GPU bleed, left pack, right pack, wing-anti ice supply, and per-engine shut-off valves.
Another way to understand the system is as a Lancair (legacy X-Plane) overlaid with a King Air overlaid with a 747 – you will then understand how to design many more aircraft types with it:
1. Single-engine plane (Lancair Evolution or similar)
The center pack is the single source of cabin pressure. Packs L and R are always off because they don’t exist.
The bleed selector doesn’t care for left or right or both, the isolation valves have no function, the only available settings are: Bleed “off” meaning engine shut-off valve off and Bleed “on” (any of L, R or BOTH) meaning engine shut-off valve on. Bleed “auto” adds APU valve on (the single engine plane most likely doesn’t have an APU, but if it has, it would work), GPU adds GPU off or on. There’s only one duct, and only one available pressurization pack, center.
2. Two-engine plane with single pressurization (old King Air or similar)
The center duct supplies the one center pack that provides air to the cabin. The pack can be fed from the left engine, the right engine, or both. The bleed air mode thus maps to the isolation valves: left bleed air means left isol valve open, right bleed means right isol valve open, bleed both or auto mean both isolation valves open. If an APU was installed, it would feed into the center duct regardless of the isolation valve settings, controlled by the APU valve, just like the GPU.
3. Four-engine plane (resembling 747)
The system operates exactly like a 747 would: Three packs are available, per-engine SOVs, APU SOV and GPU SOV and two isolation valves work exactly like you’d expect when comparing the above graphic to the schematic of a 747.
4. Twin engine plane (737, A320, CRJ, ERJ, etc.):
Here’s where it gets interesting. For correct operation, one must turn off the legacy center pack and never turn it on again. That must be done actively by script or plugin, since X-Plane will never turn off the center pack – that would break existing aircraft!
The plugin can turn pack C off and pretend it doesn’t exist.
One can then turn on pack L and pack R as per the pack switches.
One can turn off or on the per-engine SOVs as per the engine switches.
Now the only remaining switch is the (single) isolation valve found in such aircraft.
This is where it gets airplane specific and one needs to look at a diagram for the specific airplane: Look up whether the APU and GPU feed into the left or the right from the single isolation valve. For the sake of explanation, let’s assume we are looking at the 737, where the APU feeds into the left duct and GPU feeds into the right duct.
For operation with the APU, the isolation happens to the right of the APU. That is, the isolation valve of the 737 with APU feed is the ISOL R valve in the X-Plane system (and ISOL L is always open). This way, center and left duct belong together, and are fed by left engine and APU. To the right of the isolation valve is the right engine.
For operation on GPU, the isolation happens to the left of the GPU! That is, the isolation valve of the 737 in GPU feed is now the ISOL L valve in the X-Plane system (and ISOL R is always open). This way, the left engine is to the left of the isolation, and GPU and right engine are to the right of the isolation.
Note that GPU and APU can never feed together – in real planes, the APU load control valve is also a one-way check valve. If theAPU valve was commanded to open while the system is pressurized from the GPU, it simply wouldn’t open. In that case, the system operates as GPU-fed until the GPU is off.
5. Twin engine plane (McDonnell-Douglas)
For a plane like the MD-80, which has two isolation valves, operation becomes very simple:
The center pack is turned off (by script or plugin) and never turned on again.
Pack L and pack R are turned on as per the Air Cond Cockpit and Air Cond Shutoff switches.
One can then turn off or on the per-engine SOVs as per the supply switches and fire handles. Both pulling a fire handle or turning off a supply switch should close the engine valve.
The left and right isolation valves separate the side systems with their respective packs from the center duct, into which the APU and GPU feed. These valves are thus direct mappings between X-Plane and and the MD-8x cockpit.
6. Three engined-planes
Because three-engined planes are very dissimilar in design between a 727, DC-10 or Tu-154, X-Plane makes no effort to resemble either – it is expected that custom plugin code will be needed to accurately simulate a three-engine plane.
Electrical power consumption
Having covered the pneumatic side of the system, let’s look at the electric side.
X-Plane has one electrical consumer for “HVAC” that until X-Plane 11.34 could not be controlled via datarefs or commands. From X-Plane 11.35 onwards, the following electrical loads are simulated with the various components of the system:
- AC compressor and fan take 100% of the amp load that is specified
- Fan only takes 10% of the amp load that is specified
- Fan and heater in flight mode take 100% of the amp load that is specified
- Fan and heater in ground mode take 200% of the amp load that is specified
Note that most of this is only relevant to GA planes, not airliners. Airliners do neither have electrical AC compressors nor electric heaters. Heat is supplied by the bleed air alone, it comes out of the engines so hot that it does not need to be heated. The cooling is provided by an air cycle machine driven by bleed air pressure itself, so it does not need lots of electrical power to run the air conditioning to cool it down.
So in an airliner, one would only ever use the fan function, so in Plane Maker, the amp load of the fan times 10 needs to be specified for the whole system, since we are never going to use the remaining 90%.
In a GA plane, the AC compressor is driven by electrical power, so using it will put you in the situation where X-Plane will use 100% of the specified amps.
Some turboprop planes, notably the King Airs and Cheyennes, have not enough heat from the engines to sustain cabin heating alone, so they use an electric heater grid consisting of 8 grids at 36amps each (that is the value for a King Air 90), four of them operate in flight, and an additional four can be activated on the ground when enough power is supplied either by both generators running, or by a GPU. That “ground max” heat setting will double the power consumption, as explained.
Datarefs
sim/cockpit2/pressurization/actuators/air_cond_on int y boolean Electrical air conditioning compressor on, consuming all the amps of rel_HVAC - not needed on airplanes with air cycle machines that drive the air conditioner off the bleed air power itself.
sim/cockpit2/pressurization/actuators/heater_on int y boolean Electrical heater grid on, 0 = off, 1 = flight max (consumes rel_HVAC amps), 2 = ground max (consumes 2x rel_HVAC amps, turned off by weight-off-wheels) - not needed on airplanes that are using hot bleed air and have no heaters
sim/cockpit2/pressurization/actuators/fan_setting int y enum Electric fan (vent blower) setting, consuming 0.1 of rel_HVAVC amps when running. 0 = Auto (Runs whenever air_cond_on or heater_on is on), 1 = Low, 2 = High
sim/cockpit2/bleedair/actuators/engine_bleed_sov int[8] y boolean Engine bleed air shut off valve, close or open
sim/cockpit2/bleedair/actuators/apu_bleed int y boolean APU bleed air valve, close or open. APU must be running at 100%N1 to provide bleed air
sim/cockpit2/bleedair/actuators/gpu_bleed int y boolean GPU bleed air valve, close or open. A GPU is supposed to be always available.
sim/cockpit2/bleedair/actuators/isol_valve_left int y boolean Isolation Valve for left duct, close or open. This separates all engines on the left side of the plane, the left wing, and the left pack from the rest of the system
sim/cockpit2/bleedair/actuators/isol_valve_right int y boolean Isolation Valve for right duct, close or open. This separates all engines on the right side of the plane, the right wing, and the right pack from the rest of the system
sim/cockpit2/bleedair/actuators/pack_left int y boolean Left pressurization pack, off or on. The left pack is supplied from the left side of the plane or through the left isolation valve and only available for airplanes made for 11.35 or newer
sim/cockpit2/bleedair/actuators/pack_center int y boolean Center pressurization pack, off or on. The center pack is supplied from center duct, which can be supplied from a center engine, APU, GPU, or, via the isolation valves, the left and/or right ducts. This pack is the only pack available for airplanes made for X-Plane 11.33 or older
sim/cockpit2/bleedair/actuators/pack_right int y boolean Right pressurization pack, off or on. The right pack is supplied from the right side of the plane or through the right isolation valve and only available for airplanes made for 11.35 or newer
sim/cockpit2/bleedair/indicators/bleed_available_left float n ratio Bleed air available in the left duct, which can come from left engines or through the left isolation valve.
sim/cockpit2/bleedair/indicators/bleed_available_center float n ratio Bleed air available in the center duct, which can come from a center engine, APU, GPU, or, via the isolation valves, the left and/or right ducts.
sim/cockpit2/bleedair/indicators/bleed_available_right float n ratio Bleed air available in the right duct, which can come from right engines or through the right isolation valve.
sim/cockpit2/bleedair/indicators/engine_loss_from_bleed_air_ratio float[8] y ratio Bleed air being sapped from the engine, stealing efficiency from the compressor. Writeable only with override_pressurization set
Commands
sim/bleed_air/engine_1_off
sim/bleed_air/engine_2_off
sim/bleed_air/engine_3_off
sim/bleed_air/engine_4_off
sim/bleed_air/engine_5_off
sim/bleed_air/engine_6_off
sim/bleed_air/engine_7_off
sim/bleed_air/engine_8_off
sim/bleed_air/engine_1_on
sim/bleed_air/engine_2_on
sim/bleed_air/engine_3_on
sim/bleed_air/engine_4_on
sim/bleed_air/engine_5_on
sim/bleed_air/engine_6_on
sim/bleed_air/engine_7_on
sim/bleed_air/engine_8_on
sim/bleed_air/engine_1_toggle
sim/bleed_air/engine_2_toggle
sim/bleed_air/engine_3_toggle
sim/bleed_air/engine_4_toggle
sim/bleed_air/engine_5_toggle
sim/bleed_air/engine_6_toggle
sim/bleed_air/engine_7_toggle
sim/bleed_air/engine_8_toggle
sim/bleed_air/gpu_off
sim/bleed_air/gpu_on
sim/bleed_air/gpu_toggle
sim/bleed_air/apu_off
sim/bleed_air/apu_on
sim/bleed_air/apu_toggle
sim/bleed_air/isolation_left_shut
sim/bleed_air/isolation_left_open
sim/bleed_air/isolation_left_toggle
sim/bleed_air/isolation_right_shut
sim/bleed_air/isolation_right_open
sim/bleed_air/isolation_right_toggle
sim/bleed_air/pack_left_off
sim/bleed_air/pack_left_on
sim/bleed_air/pack_left_toggle
sim/bleed_air/pack_center_off
sim/bleed_air/pack_center_on
sim/bleed_air/pack_center_toggle
sim/bleed_air/pack_right_off
sim/bleed_air/pack_right_on
sim/bleed_air/pack_right_toggle
sim/pressurization/aircond_on
sim/pressurization/aircond_off
sim/pressurization/heater_on
sim/pressurization/heater_grd_max
sim/pressurization/heater_off
sim/pressurization/heater_up
sim/pressurization/heater_dn
sim/pressurization/fan_auto
sim/pressurization/fan_low
sim/pressurization/fan_high
sim/pressurization/fan_up
sim/pressurization/fan_down
Datarefs of the form:
sim/flightmodel2/wing/dataref_name[N]
give you information about the wings – in particular, they tell you the degrees of deflection of the flaps, elevators, etc. etc.
But what number do you use for N?
The answer is: you pick “N” depending on which airfoil you are animating!
In X-Plane, the horizontal and vertical stabilizers are “wings” too – we call anything that has an airfoil a wing. So you use this table to pick an N that matches what you are doing.
Good:
sim/flightmodel2/wing/aileron1_deg[0] # left aileron
sim/flightmodel2/wing/aileron1_deg[1] # right aileron
sim/flightmodel2/wing/elevator1_deg[8] # left elevator
sim/flightmodel2/wing/elevator1_deg[9] # right elevator
sim/flightmodel2/wing/rudder1_deg[10] # rudder
Usually not good:
sim/flightmodel2/wing/aileron1_deg[8] # aileron on an hstab??
sim/flightmodel2/wing/aileron1_deg[10] # aileron on a rudder?!
sim/flightmodel2/wing/elevator1_deg[0] # elevator on a wing?
sim/flightmodel2/wing/elevator1_deg[10] # elevator on a rudder?
sim/flightmodel2/wing/rudder1_deg[0] # rudder on a wing??
The moral of the story is: pick an array index that matches the part of the plane you are trying to animate!
Unusual Airplanes
The second list is titled “usually not good” above because there are airplanes with rudders on the wings (think of a flying wing) or V-tails where the tail is half-rudder, half-elevator. The rule still applies: use the index that you are animating! So if you have a rudder on your wing, then use index 0 (left wing 1) for the left wing, etc. The important thing is to pick an array index that matches the Plane Maker part.
Why Is It Like This?
X-Plane is a completely flexible simulator: it lets you put any control surface on any flying surface. If you want to make an experimental design with elevators on the wings, X-Plane is not going to stop you.
In particular, because any flying surface can have any control surface, the datarefs are set up with array indices for all flying surfaces for all control surfaces.
But if your airplane does not have rudders on the wings, the value of those daterfs won’t be useful – they might be ‘correct’, they might be zero, they might be wrong. Don’t trust them! Use the correct array index for the correct wing and your plane will work correctly.
