[solved] AxID references wrong physical axis

[jukelo]

Issue: The AxID field in Profile > Axes > Logical axes no longer directly references the physical ID that should feed data to the logical axis.

The issue seems to have appeared with firmware 2.17.9, and persists in 2.18.E.
Tested with software versions 0.92.95 and 0.93.18.

Reproduction steps:

• Flash firmware 2.18.9 on Gladiator NXT/EVO base
• For Logical axis 1, set AxID = 2.
• For Logical axis 2, set AxID = 1.
• For Logical axis 3, set AxID = 1.
• Move the main axes, and observe in the Test tab that:
  
  • Logical axis 1 is controlled by physical axis 1 (roll), not 2.
  • Logical axis 2 is controlled by physical axis 2 (pitch), not 1. This is undistinguishable from the default config.
  • Logical axis 3 is controlled by physical axis 2, not 1.[list/]

Demonstration of the bug on firmware 2.18.9:
https://www.youtube.com/watch?v=Sx3mTpUWpEk

And the expected behaviour, on 2.17.6:
https://www.youtube.com/watch?v=ojVhUHl_9GY

It appears that whatever value for AxID is given is not interpreted directly as a physical axis index. Instead, it is a reference to the index in the list of logical axes. Whatever AxID value is given for *that* index is the physical axis that will be used.
Here's the breakdown per logical axis:

Logical axis 1 uses AxID = 2. This does not directly reference Physical axis 2, but the AxID value for the axis at the second index in the list of logical axes. This value is 1, Logical axis 1 is therefore fed the Physical axis 1 data.


Logical axis 2 uses AxID = 1. The AxID value at logical index 1 is 2. Logical axis 2 is therefore controlled by Physical axis 2.


Logical axis 3 uses AxID = 1, the same case as Logical 2, it is therefore controlled by physical axis 2.


This bug probably slipped under the radar because it is only noticeable when the values for the logical axis index and the AxID value differ. When they match, The AxID value simply references the same index as the logical axis holding the value:

[Alex Oz]

accepted
........

Check v2_18_F(3)

According to the calculation, the DZ block is actually located here

[jukelo]

At first glance this has fixed it!
Thanks a lot, this is one that has made my life harder a good many times

[jukelo]

According to the calculation, the DZ block is actually located here

dz.jpg

I see, this is new right? Until now deadzones could be defined per virtual/logical axis.
With this, the same deadzone is applied to all virtual axes sharing the same AxID. Will this change?

[Alex Oz]

Deadzones were in the area of ​​logical axes more for historical reasons, but they increasingly create problems and conflicts for the functions of axis manipulation, and sometimes it is not clear how to solve them.
But in fact, the DZ is always used to calculate normalized virtual axes, not logical ones.

I think it is right to bind them to a physical object with certain properties.
If several logical axes receiving input from one P.axis will also work with the same DZ.
Transferring the parameters of the DZ in the configurator in the area of ​​physical axes should provide an understanding of the processing sequence.
Are there any counterarguments?
(True, it was possible to manipulate the axes with a change in the DZ before, but I can hardly imagine the purpose of such use.)

[jukelo]

It makes sense in that deadzone parameters are usually down to the characteristics of the physical lever.

My one counterpoint is for cases where two logical axes with different functions do work off of the same physical axis:
For example my Omnithrottle Pitch axis (with spring) for Elite Dangerous can be used to axis swap between controlling Forward and Backward thrusters via Logical 2 (with a center deadzone of 1%), or Forward Throttle via Logical 7 (with no center DZ since the whole range is used for the same action).

Deadzones applied at the physical axis level would force me to choose which of the two DZ configs to keep. Not a big deal in my case, I would probably choose the 1% deadzone in the middle of both axes, but it is one example nontheless.

[Alex Oz]

Perhaps DZ switch will help?

[jukelo]

That would do it yup, so I have no more objection

[Alex Oz]

OK, I will make these changes and we will see what noise the community makes. Then we will have to roll back or make other decisions.
But the reason for this topic was the ambiguity and source of potential errors in the axis mapping.

Thank you for your help and cooperation.

There is still an unclear point with the combines - are there problems with the new ID binding engine?

[jukelo]

The Axis Combine functions appear to be working fine with the fixed AxID assignments, but the issue with the Combine AxisNN value being offset by one in the new UI remains.