Better support for "infinite" axes: Enable G92.9 (directly set current position) for rotational axes

[DerAndere1]

Description

• In principle, rotational axes can be infinite. But with Marlin, the user needs reset the current position of that axis to 0 regularly to prevent overflow of the position variables. The best configuration for an "infinite" rotational axis can be found below.
• Suppose we had rotational A axis and //#define NO_WORKSPACE_OFFSETS. In this scenario there was no way for the user to prevent overflow of the position variables. With this PR, G92.9 A0 can be used to directly zero the positions of the rotational axes (A axis in this example).
• This PR Includes a hotfix (simplified) for rotational axes until a decision on PR LCD menu_move: Treat rotational axes in angular degrees #24334 is made

Requirements

Best to be used with an axis that can rotate infinitely.

#define AXIS4_ROTATES
#define I_MIN_POS -9999999
#define I_MAX_POS  9999999
//#define MIN_SOFTWARE_ENDSTOP_I
//#define MAX_SOFTWARE_ENDSTOP_I

For rotational axes without a homing switch, this is required in addition:

#define I_HOME_DIR 0
#define MANUAL_I_HOME_POS 0 

For full testing, use a display with MarlinUI and also this:

#define INCH_MODE_SUPPORT
//#define NO_WORKSPACE_OFFSETS
#define CNC_COORDINATE_SYSTEMS

Benefits

allow rotational axes to rotate without end

Configurations

Config.zip

Related Issues

• Fix [BUG] 8 Axis on Octopus, no longer compiles #26220
• Fix 5 axis with rotation fails to compile. #26335
• [FR] (disable homing independent axis's I, J, K, U, V, W) #24901
• Disable MIN/MAX pin for 4th axis #24196
• LCD menu_move: Treat rotational axes in angular degrees #24334

[thinkyhead]

Ideally the manual feed rate for rotational axes will already be expressed in degrees-per-second. And then, rotational axes will not be affected by the mode being "inches" or "mm" because the axes are rotational. This is distinct from an axis that is part of a kinematic system (SCARA) where we convert mm to degrees behind the scenes.

[thinkyhead]

The general problem remains that G-code commands only supply a single feed rate in terms of current units per second, but not all axes have a meaningful conversion from degrees to linear units. So a move that only involves a rotational axis and no others should be able to get its feed rate in terms of degrees-per-second (or radians-per-second if the machine is in Radians Mode). And on the LCD display an axis rotational position should be shown in degrees/radians too, or in some unit that is more pertinent to the application. It's challenging to devise a general approach to this.

[DerAndere1]

Indeed, I would say that #24334 is the more complete solution regarding the feedrate for linear moves vs. rotation. I have not tested that PR in a while but it was working at some point. With PR 24334 merged, this PR would be simplified to just add G92.9 for machines with rotational axes.

[thinkyhead]

Indeed, I would say that #24334 is the more complete solution regarding the feedrate for linear moves vs. rotation. I have not tested that PR in a while but it was working at some point. With PR 24334 merged, this PR would be simplified to just add G92.9 for machines with rotational axes.

I agree that PR has the completeness advantage, but this PR can still be merged first and then we can take another look at #24334 and decide how best to apply it. With #24334 I was mainly stuck on how janky our support for rotational axes is in the planner, and I wonder if we could come up with a superior design.

This PR is largely non-disruptive and should only affect code size when there's one or more rotational axes and/or inches units support is turned on.