FMS inputs and outputs (build 58)

Zibo's FMS scripts (B738.a_fms, B738.calc) run unmodified on the XLua host inside the systems module (docs/M5C_PLAN.md). They read about 460 datarefs they do not create, and create the numbers the displays draw.

Why (owner, build 57)#

TAKEOFF REF showed no N1 limit, no QRH V-speeds and no TOW; the route had no predictions. The scripts' inputs were filled by X-Plane's cold & dark values (the oracle's, data/fms/xplane_dataref_values.lua) except about 50: B738.calc (N1 limits, V-speeds, flap speeds) did not run at all, the fuel and weights, the AFDS's and MCP's values, the NAV receivers never reached the FMS. A test now goes through PERF INIT and TAKEOFF REF the way the pilot does (fms_perf_init_gives_takeoff_speeds).

Inputs, in the order they are bound (fms/fms.cpp Fms::bindInputs)#

1. MSFS's A:vars (kSim): position, air data, attitude, time, weights, engines' N1 / N2, NAV receivers (DME, radial, CDI / GSI as the NDs convert them), the AP reference airspeed / Mach / altitude of the glareshield.
2. IRS / GPS / FMC positions and the magnetic variation (from the IRS modes and MSFS's position).
3. The L:vars our systems publish: laminar/B738/<x> from L:LU737_<X>, sim/<x> from L:LU737_SIM_<X>.
4. Our ports' values (Systems::addFmsSources, systems_fms.cpp):
   • zibomod's globals in the ported modules (AfdsGen, SysGen, PressGen, HydGen field tables): the dataref's global from zibomod's own registrations (tools/re/zibomod_datarefs.json), X-Plane's datarefs from zibomod's handles (DRsim_<x> -> the value simDR_<x> the systems fill from MSFS);
   • the EFIS controls, the VOR / ADF switches, the MCP courses (NAV OBS), track up active, the glareshield's speed ratio, the payload (MSFS total - empty - fuel weight), the reversers, the ADF bearings, air / ground.
5. Datarefs the FMS creates that Zibo's IRS script writes (B738.LATLON, not run: our IRS is irs/irs.cpp; Fms::addOwnedSource, build 66): the IRS modes (irs/irs_mode, irs2_mode), alignment time left, the ND's alignment flags, the selectors and the source switch. Before build 66 the FMS saw both IRSs off: its B738_fmc_calc stopped the route's distances (lnav_dist_next, dist_to_dest, the T/D moved only at a leg change) and asked for LNAV / VNAV disconnect (found by vnav_descends_in_the_systems).
6. Anything else keeps X-Plane's cold & dark value.

fms_external_inputs_report writes the inputs still unfilled to wasm/out/fms_unbound.txt.

Still X-Plane's values#

The FMS writes some of its inputs too (autotune: NAV standby frequencies; the fuel loading of its ground services): our systems' values replace them each frame. The autotune reaching our NAV radios is open.

Outputs to the displays#

The numbers the scripts create that a display program reads (avionics/src/instruments/*/panel.json), 266 datarefs (436 values with the arrays' elements), are published as L:LU737_FMS_<NAME> (laminar/B738/ dropped, / -> _, upper case; an array's element _<i>), each FMS frame when they change. The list is generated with the scripts (wasm/tools/gen_fms_embed.py -> fms_embed.cpp kFmsExports and avionics/src/du/FmsExports.ts). A display source still pending reads the FMS's value (DuSource.ts); exact / msfs sources (our C++ ports, MSFS) stay. Examples: L:LU737_FMS_FMS_V1, _FMS_VR, _FMS_V2_15 (the PFD's V-speed bugs), the flap manoeuvre bugs (_PFD_FLAPS_*), the FIX page's circles (_ND_FIX_*).

The display tests (avionics/test/*_data.test.ts) feed these L:vars with the oracle's values (test/fms_vars.ts).

Strings the scripts create (station and fix identifiers on the NDs) are not published yet.