Normally one uses getValue() function with the source/filed name like so:
This works and is recommended method for portability. But if a particular script needs to get the value of certain field a lot, then it is faster to use this syntax:
Why is this method faster? With the function getFieldInfo(name) we get the numerical id
of the wanted filed. The function has to find the requested value by its name in the table of all available sources. That search takes some time.
When we use this syntax the search is only done once. In comparison in the first example the search must be performed every time getValue("bar")
is called.
So when the getValue(my_id)
is called the search can be skipped and the requested value if fetched directly.
Of course there is a trade-of, the second example uses little more memory (for variable my_id
).
OpenTX considers all function, mix, and telemetry scripts to be 'permanent' scripts that share the same runtime environment. They are typically loaded at power up or when a new model is selected. However, they are also reinitialized when a script is added or removed during model editing.
Any variable or function not declared local is implicitly global. Care must be taken to avoid unintentional global declarations, and ensure that the globals you intentionally declare have unique names to avoid conflicts with scripts written by others.
This example consists of three scripts
count-dn.lua - this is a mix script than can be run stand alone to announce time remaining based on a user-defined switch and duration. It updates two global variables (gCountUp and gCountDown). It also creates output values (ctup and ctdn) which are for demonstration purposes only.
count-up.lua - this is an optional function script which will do count up announcements based on harded coded values.
shocount.lua - this is an optional telemetry script which simply shows the current values of the gCountUp and gCountDown variables.
count-dn.lua
copy to /SCRIPTS/MIXES
configure on the transmitter CUSTOM SCRIPT page
suggested switch = "SA"
suggested mins = 3
suggested sw_high = 0
screen image:
count-up.lua
copy to /SCRIPTS/FUNCTIONS
configure on the transmitter SPECIAL FUNCTIONS page
suggested switch SA(down)
screen image:
shocount.lua
copy to /SCRIPTS/TELEMETRY
configure on the transmitter TELEMETRY page
screen image:
It is always good practice to check your code on syntax before even testing it. There are several good LUA editors on the market, some of them for free. The ZeroBrane (https://studio.zerobrane.com/) suite is quite powerful, and very simple to use. In the rest of this article we will assume you use ZeroBrane, but the same techniques can be used in any powerful code editor.
You can set ZeroBrane to use the Scripts directory of your simulated transmitter SDCard image as a default directory, and it will show you all the files in a nice navigation tree.
If you open a LUA file, you will already have some markup in your screen, indicating errors or important info. In ZeroBrane for instance, a not declared variable will always get underlined, so that you are made aware you forgot to declare it, or you redeclared it by accident afterwards again.
The editor will have an "execute code" option, that will try to run the code on it's own interpreter (code processing engine). If there are any syntax errors, it will not be able to execute the code, and inform you about the errors. A common error in LUA is using a single equal sign (=) in a condition in an 'if' statement, whereas in LUA that should be a double equal sign (==). The interpreter will inform you about such an error ocurring, and mention the line where you made the error.
Since the OpenTX LUA environment has some own functions, like lcd.drawText(), the interpreter will 'complain' it cannot call an unspecified function, but it will check the entire syntax nonetheless.
In zerobrane, if you tried to run the code, it will first save it if it could be interpreted correctly. A common workflow would be:
do some code corrections / additions
try to run the code in the editor
if the code gets compiled, the edited LUA file gets saved automatically
run the code in the transmitter simulator
check for the desired functionality
restart this cycle
In the later versions of the companion software, a LUA debug screen is available. So once you start your just syntaxically verified and saved LUA script, you can follow some of it's output and actions in the debug screen. It will tell you where and in what line an eventual crash occured.
If you made some code changes, chances are that you have to do a whole sequence of key-clicks and actions on the transmitter simulator in order to retest the same script after those changes.
You can substatially reduce the effort of all this by using a script loader in your transmitter. This is nothing more then a function that will load and run your code. If you press the enter button, it will unload the current code, and ask if you want to run the code again. So, with just two clicks, you can unload the running code and reload your updated code. On the Taranis simulator, you can also reload the LUA scripts environment with just a buttonclick.
An example of such a script is found under the notes. You can adapt it for other types of scripts of course.
This script loader will load the file /SCRIPTS/TELEM/telem1.lua, run it, and wait for an Enter Break event. Once received, it will unload the code and wait for a next Enter Break event.
The advanced topics section covers file I/O, data sharing, and debugging techniques