Backlash correction proposal

[nxperera]

This change will create intermediate (secret) plan_buffer_line() call when a backlash correction is required for a given motion and this correction motion is supposed to be hidden from the system as much as possible (this is achieved by skipping the motor_steps increment/decrement at Stepper::pulse_func() method for backlash steps). I have considered the risk of messing up Bresenham line algorithm by this skipping steps. Even if that's the case it is localized only to the backlash motion.
In order to define a backlash correction use /Axes/<x,y,z,a,..>/backlash=<correction_value> in config.yaml . Apart from system motions backlash correction is applied to all the cnc motions when defined it in the configuration. This implementation tracks the motion changes while probing and homing. Backlash correction is applied to probe moves.

[atlaste]

First off, thanks for your contribution; it's not every day that people attempt to contribute to the planner buffer, so that's interesting. I looked through the backlash correction proposal. Unfortunately, I'm not sure if it's going to work like this. A few things that come to mind:

• The steps in mpos and mm should be in sync. So if you correct in one direction for backlash, it should probably compensate that in a next move somehow. By doing small hidden moves, I would think there could be an error that gradually increases. However, mechanically, I would argue that backlash is a true constant that relates to the slack in the gearing.
• It's also interesting what would happen with a lot of tiny moves, like -say- milling a pcb.
• I'm also not sure about the ramp-up, ramp-down behavior and what would happen when the planner buffer is reset.
• Doing a reverse motion after a normal motion, has to inverse the direction pin of the stepper, which is usually a magnitude slower than the pulses themselves. Instead of compensating it - can't we just shorten the moves a tiny bit according to backlash?
• I can't remember where kinematics are being done, and I don't know how it relates to backlash compensation. That is something I would have to check though.

There's also minor details like clang-format, and that PR's should always target the 'Devt' branch.

[pagabee]

If this helps, the backlash correction is implemented in this GRBL fork:
https://github.com/Schildkroet/GRBL-Advanced

[nsiatras]

I often look to see if the backlash compensation feature has been Implemented in FluidNC.
But the FluidNC project development says

"Our current position...

We do not support backlash compensation at this time. It requires that the firmware know which side of travel the backlash is at all times. Lightweight machines that are prone to chatter tend to scramble the backlash. Backlash compensation can make things worse. Physical means of limiting backlash like preloading tend to work better. We prefer to spend our time on other features.

If you know of any research papers addressing backlash on lightweight machines, please send them our way."

After a google search for "lightweight cnc machines and backlash compensation" I found nothing. This makes perfect sense as there is no reason to have a lightweight CNC. CNC machines are machines that are built to perform precision movements. No sane person would build a CNC machine with the intention of being "light".

Anyway... The 2 photos I upload were taken by me. As you will see Backlash compensation is something that works. Siemens, Fanuc, Heidenhain and all CNC controller manufacturers worldwide have the same opinion, as they all have Backlash Compensation in their software.

Backlash compensation is a great feature that is still been missing from FluidNC. Hope FluidNC devs can see the photo.

PS. My tests are done using GRBL_ESP32. I implemented backlash compensation to GRBL_ESP32 but unfortunately I cannot make it work with Arcs. It only works with G0 and G1 commands.