How to do skew correction (primarily on X/Y)?

[axxel]

Let's assume I have a 3 axis cartesian gantry setup (with a single motor + spindle for each axis) with a skew in the X/Y plane that I can't fix by physically adjusting the hardware. I'd like to correct this in software. I was not able to find proper information if/how this is possible in grblHAL. I found gcode processing tools, like goskew or gskewer, that try to do this outside of the controller. I have 3 issues with that:

1. it is an extra step to deal with in your pipeline
2. it does not work if you manually type in some gcode in the console of your random gcode sender software
3. it would not fix the skew in arcs (as far as I understood the problem and the goskew readme agrees)

All I need (I think), would be the option to tell the planner that for every step in Y it needs to add some (very small) fraction of a step to X. I found a discussion somewhere in an old GRBL forum where someone claimed that this would not be possible on the 8-bit cpu they were operating on. I'm currently using a RP2040 and would assume this limitation does not apply.

Is this implemented and I simply failed to find it? If not, is this planned / discussed already? If not, is there an obstacle implementing this, that I currently failed to see?

[terjeio]

Is this implemented and I simply failed to find it?

It is not implemented.

If not, is this planned / discussed already?

At least not asked for recently, could be it was some time back.

If not, is there an obstacle implementing this, that I currently failed to see?

Not that I know of. If someone wants to implement it go ahead - I will not add it to my workload for quite a while.

[axxel]

Thanks for the quick response! I'll work on it. A few questions though:

1. Can you maybe point me to the best spot (or area) in the code where this would fit? I have not looked at the code yet, but ideally there would be a place after all the "planning" is done, pretty close to the step generation but where we still know the current global position (relative to the homing coordinates). Then I'd either track 2 positions for X (a "virtual" one - the only one currently available, and a "real" one) or convert it back and forth as required.
2. I guess the way to transport this skew correction factor is via a $-setting. Is there a standard number for this info available, if not: do you have some grblHAL specific extensions already where this could be added?
3. Anything special required to make this new parameter non-volatile (survive a power cycle)?

[terjeio]

1. I think the best spot will be in plan_buffer_line().
2. No standard numbers yet - add Setting_AxisSkew = Setting_AxisSettingsBase1 + AXIS_SETTINGS_INCREMENT, after the jerk setting while testing. If/when a PR is forthcoming I'll assign a set for you (or a single one if only a single one is required).
3. You will have to add code to claim NVS memory for the setting(s) and handle them, I do that for additional PWM spindles here. The spindle code is a bit involved, take a look at some of the plugins for how to simplify it. Do not extend the current core settings since this will trigger a settings reset for those who add skew correction.