Custom (Mixer) Scripts

WARNING - Do not use Lua Custom scripts for controlling any aspect of your model that could cause a crash if the script stops executing!
Overview
Each model can have several custom scripts associated with it, and these scripts are run periodically. They behave similarly to standard OpenTX mixers, but at the same time they provide a much more flexible and powerful tool. Custom scripts take one or more values as inputs, do some processing in Lua code, and output one or more values.
Please note: the firmware must be compiled with the option LUA_MIXER=Y for Custom scripts to be available.
Please note: the scripts should be as short as possible, to avoid delays. It is also important to keep in mind that other loaded Telemetry and Function scripts can add to the response time, or worse: hang the system!
Typical uses
replacement for complex mixes that are not critical to model function
complex processing of inputs and reaction to their current state and/or their history
filtering of telemetry values
Limitations
cannot update LCD screen or perform user input.
should not exceed allowed run-time/ number of instructions.
custom scripts are run with less priority than built-in mixes. Their execution period is around 30ms and is not guaranteed!
can be disabled/killed anytime due to logic errors in script, not enough free memory, etc...)
Lifetime
Custom scripts are loaded from SD card when model is selected
init __function is called first
run function is called periodically (about 30 times per second)
the script is killed (stopped and disabled) if it misbehaves (e.g. run-time error or low memory)
all Custom scripts are stopped while a One-Time script is running (see Lua One-time scripts)
Disabled script
If the script output is used as a mixer source , and the script is killed for whatever reason, then the whole mixer line is disabled ! This can be used for example to provide a fallback in case Lua Custom script is killed.
Example where Lua mix script is used to drive ailerons in some clever way, but control falls back to the standard aileron mix if script is killed. Second mixer line replaces the first one when the script is alive:
CH1  [I4]Ail Weight(+100%)
  := LUA4b Weight(+100%)
File Location
Place them on SD card in folder /SCRIPTS/MIXES/. File name length (without extension) must be 6 characters or less (this limit was 8 characters in OpenTX 2.1).
Interface
Every script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:
input table (optional)
output table (optional)
init function (optional)
run function
Example
local input =
  {
    { "Strength", SOURCE},           -- user selects source (typically slider or knob)
    { "Interval", VALUE, 0, 100, 0 } -- interval value, default = 0.
  }
​
local output { "Val1", "Val2" }
​
local function init()
  -- Called once when the script is loaded
end
​
local function run(Strength, Interval) -- Must match input table
  local v1, v2
  -- Called periodically
  return v1, v2                        -- Must match output table
end
​
return { input=input, output=output, run=run, init=init }
Input table
The input table defines what values are available as input(s) to custom scripts. There are two forms of input table entries.
{ "<name>", SOURCE }
SOURCE inputs provide the current value of a selected OpenTX variable. The source must be selected by the user when the script is configured. Source can be any value that EdgeTX knows about (inputs, channels, telemetry values, switches, custom functions etc.).
Note: the typical input range is -1024 thru +1024. Simply divide the input value by 10.24 to convert to a percentage from -100% to +100%.
{ "<name>", VALUE, <min>, <max>, <default> }
VALUE inputs provide a constant value that is set by the user when the script is configured.
name - maximum length of 8 characters
min - minimum value of -128
max - maximum value of 127
default - must be within the valid range specified
Maximum of 6 inputs per script (was 8 in 2.1)
Output table
The output table defines only name(s), as the actual values are returned by the script's run function.
{ "<name1>", "<name2>" }
Note: the above names are only visible as source values on the radio screen when the script is running. If the model is edited in Companion, then the values show as LUA1a and LUA1b etc.
Part I - Script Type Overview
Telemetry Scripts
Last modified 8d ago