Chapter 3: Customized variables using X-var
I thought that X-vars don’t exist. Later I realized that I’m wrong. If discovered in the documentation about the RPN notation that X is an existing Variable prefix.
I didn’t change my implementation (yet). In my tool, X-vars are variables that are executed with “execute_calculator_code” in the WASM module. This allows to make a kind of “macro’s” that even can combine more variables or create complex structures using RPN notation.
An example of an X-var is:
1 (>L:A32NX_EFIS_L_OPTION,enum) 1 (>L:A32NX_EFIS_R_OPTION,enum)
This sequence is setting both the left as right EFIS on CSTR.
In the meantime, you know the drill. We can first test the RPN string with the “execute_calculator_code” to see if it works. If it does, we can register the variable. Because we don’t need a value, we can use a VOID.
Now we can enable both EFIS_L and EFIS_R to CSTR (1) with one simple command “001”. Because we use VOID, we even don’t need to add the “=”-sign.
Using a value with X-var
X-vars support VOID (as in the example above) and INT32. Reason that other variable types are not supported is that an X-var is also using an Event, which only supports DWORD as parameter. The below example registers an X-var with an INT32 as a Write Only variable which allows you to set the EFIS_L. Using the command “003=5” sets it to ARPT (5).
Just be aware that the value is just been put in front of the X-var. This means that in the WASM module, the “execute_calculator_code” is executing the command:
5 (>L:A32NX_EFIS_L_OPTION,enum).
Remark 1: Even if we use VOID, the X-var will always be preceded with the value 0. That means that in the first example, the command sent with “execute_calculator_code” is:
0 1 (>L:A32NX_EFIS_L_OPTION,enum) 1 (>L:A32NX_EFIS_R_OPTION,enum)
The reason is that we use an Event to trigger the X-var, and the Event has always a DWORD parameter, which in case of VOID is just set to 0. But there is no way on the receiving side in the WASM module to know that this 0 should be ignored or not. I might improve this in the future, but the above 0 doesn’t really harm.
EDIT 05MAY2022: Adding 0 parameter in case of VOID has been solved. Actually, the WASM Module does know whether the parameter should be used or not, because it knows that it is a VOID variable. So in case of VOID, we just ignore the parameter. New source files pushed on GitHub.
Remark 2: My tool is converting to uppercase, but this is a bad idea, so I will need to change that. Reason is that RPN is case sensitive, and some operators are small cases. I tried for example to create the command:
INT32_W_X:d (>L:A32NX_EFIS_L_OPTION,enum) (>L:A32NX_EFIS_R_OPTION,enum)
The intention is to use a command like “004=3” which would then set both EFIS_L and EFIS_R to the value 3 (cfr. RPN notation documentation - “d” duplicates the stack). But when executed in the WASM module, the command is converted to uppercase, and “D” is not recognized as RPN stack operator.
EDIT 05MAY2022: Case sensitivity issue has been solved. New source files pushed on GitHub.
Avoid using “R” with X-vars that also write values
If you use “R” when registering an X-var, then the WASM Module will continue poll for this variable using “execute_calculator_code”. If in the same RPN code you also set a value, then this is also continuously executed.
Example: INT32_R_X:3 (>L:A32NX_EFIS_L_OPTION,enum) (L:A32NX_EFIS_L_OPTION,enum).
This will first set the value 3 to EFIS_L, and then read EFIS_L. Because of the Read, the variable is continuously executed with “execute_calculator_code”, but that also means that the EFIS_L is also continuously set to 3. This means that if in the below example, you use command “003=5”, this will set the EFIS_L to ARPT (5), but immediately after that it will jump back to WPT (3).
This is also the reason why you can not use “RW” with an X-var. It does not make sense to combine both a read and write action in the same X-var.