Device config: Advanced topics

Add functionality to inputs and outputs

Input Routing

Basically every device input is a separate control for SPAD.neXt, however you can re-route inputs in the SPAD.neXt UI to add functionality to one input in the UI.

An additional input is created, and the following options are added to it:


Input will not be exposed in the UI


Events from this input will not be handled by the input, but routed to the input associated with <targettag>


Example: An Encoder with a Pushbutton

First the Encoder is configured


Then the pushbutton is configured, telling SPAD.neXt to route it to the encoder


SPAD.neXt will now add the pushbutton-events to the encoder in the UI, and not expose the pushbutton I_HDG_PUSH in the UI at all. Whenever the device sends now an inputevent (8,7,1;) for that pushbutton, the according events on the encoder will be executed.

Example: An encoder that can be pulled out as a switch

Again,just configure the encoder and the additional switch


Complex Examples

Example: Encoder that can be pushed and pulled as a pushbutton

Now things get a bit more complicated.

First, as before the encoder is configured


Now 2 additional inputs shall be attached to the encoder that will use the same events. SPAD.neXt needs to know what to do and how to separate the events. To achieve this, additonal options can be added to the input(s) to create diffrent events for each of them:












Literally every event from an input can be rerouted this way. For a switch the options would be ROUTETO.ON , ROUTETO.OFF , for stateful input (rotary/3-way) those would be ROUTETO.<positionname>

The option-value will be used as event name in SPAD.neXt. If it does not exist yet, it will be automatically created.

But back to the example, now create the 2 additional input buttons (simple ones to keep this short and simple):



Note that the INHERIT for the button are ommited, to prevent SPAD.neXt to add any default events to the buttons.

For the pull-button SPAD.neXt is instructed to ignore the release event and only support the push event. The value "IGNORE" can also be ommited which will have the same effect.

In the SPAD.neXt UI the E_HDG encoder will now have the events CW / CCW / PUSH_PRESS / PUSH_RELEASE / PULL_PRESS

Note: This can become quite long configuration commands and should be done in the device editor/ device xml configuration to preserve device space

Important! Routed inputs still have their own variables to hold their current value!

Example: Airbus FCU Altitude encoder

The Airbus FCU altitude encoder has following addtional functions: Push , Pull and a ring-switch for 100 / 1000 steps





The E_ALT encoder will have the events

CW / CCW / PUSH / PULL / ALT100 / ALT1000

Note that the INHERIT for the buttons/switch are ommited, to prevent SPAD.neXt to add any default events to the buttons.

Output routing

The other way around is an output that physically located on a button (e.g. MCP / FCU). Here SPAD.neXt needs to know not to expose the led in the UI, but add it to another input, while keeping the output events separated. This is curretntly only supported for leds.

Again the led will need to have the HIDDEN=1 option so it will not be exposed in the UI, but now the button needs an option to associate it with the led. This is done by adding the option LED=<ledtargettag> to it.

Example: FCU AP1 button



This will add the led-control actions to the button, but when executed they will be routed to the L_AP1 led using the led-update channel (6)

Last updated