Fixed PID tuning sliders disabling on certain values.

[mikeller]

Fixes #2049. There is bugs, damn bugs, and rounding errors.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
1.0% Duplication

[McGiverGim]

Good work @mikeller !!

[asizon]

Yes good work! Maybe the last 10.7.0 bugfix??

[asizon]

i have tested it,the behiavour with PD Balance slider seems that is solved, but trying to find behiavours in other slider i can see some break points with PD Gain slider.
To reproduce:
1-disable dmin
2-put Master slider on 0.5
3-put PD Balance slider at 0.5
4-put PD Gain slider on 1.3 or 1.6
5.save

[McGiverGim]

I think we have some rounding error with this... 1 / D_MIN_RATIO = 1.176470588235294 that produces all this problems.

[asizon]

Yes, maybe we need to aply * 0.85 to this.PID_DEFAULT[2], now is aplying to P, it doesnt makes much sense

[asizon]

Here, I think that we are wrong aplying D_MIN_RATIO to P and not D

[mikeller]

@asizon:

i have tested it,the behiavour with PD Balance slider seems that is solved, but trying to find behiavours in other slider i can see some break points with PD Gain slider.
To reproduce:
1-disable dmin
2-put Master slider on 0.5
3-put PD Balance slider at 0.5
4-put PD Gain slider on 1.3 or 1.6
5.save

This happens in master as well, so this is a different bug.

[mikeller]

I've had another look at this, and for what I can tell what we are seeing here is inherent to how this is implemented: It tries to determine if individual PID values have been adjusted by comparing the PID values to the calculated PID values based on the sliders. But because the two calculations are slightly different, with rounding in different places, the rounding will cause the results of these two calculations to be different in some cases.
If we want to fix this we will have to rewrite the logic to determine if the sliders should be on or off to actually keep track of the PID values, and 'remember' if the user has ever manually changed one - this will obviously also have to be persisted in the firmware.

[McGiverGim]

Yes, I remember the discussion before 10.6. I always prefered that this was implemented in firmware first, to reduce the complexity and maintainability of the Configurator, but a lot of users wanted this so we released it.

Is clear that it has been a success, a lot of users like it, but the way it is implemented is a headache for us.

Now I don't know what to do with this. Try to fix it? Release it as is? I'm ok with what you decide @mikeller .

[mikeller]

@McGiverGim: I think accepting that we have now is not perfect, and trying to get the firmware based implementation done is the best approach - we could probably play whack-a-mole with these irregularities until the cows come home.