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.

[kutukvpavel]

@nxperera Did you test this code on an actual machine? Can it be used if simply merged?

Overall, I second that backlash compensation is an important feature for FluidNC. While I agree that backlash compensation is more or less useless for, let's say, a "conventional" lightweight CNC router that uses ballscrews, this is not the only application of FluidNC. In my experience, retrofits of old mills and lathes are common, and those machines use leadscrews that introduce up to 1mm of repeatable backlash, which renders the whole retrofit with FluidNC useless.

Another approach to this issue would be to implement backlash compensation in a G-Code postprocessor. However, this approach requires the postprocessor to keep track of the position, which is not always trivial to implement (for arcs an helixes, for example), and essentially repeats controller's functionality.

[MitchBradley]

The developers do not want to support backlash compensation considering all of the caveats about configuring and using it correctly, and situations where it does not work correctly. Feel free to maintain a fork and support it.

[nsiatras]

@ kutukvpavel

Another approach to this issue would be to implement backlash compensation in a G-Code postprocessor. However, this approach requires the postprocessor to keep track of the position, which is not always trivial to implement (for arcs an helixes, for example), and essentially repeats controller's functionality.

This solution is wrong and should not be advised.
CNC machines have tool change procedures, probing, canned cycles and other procedures that cannot be tracked in post processing.

Backlash compensation is related to the machine and the motion controller.
Therefore backlash compensation should be performed on the motion controller and on the motion controller only.

[MitchBradley]

Backlash compensation is related to the machine and the motion controller. Therefore backlash compensation should be performed on the motion controller and on the motion controller only.

The motion controller does not have information about milling strategies such as climb vs conventional milling, so it cannot account for tool side loading, which affects actual position on sloppy machines. The most effective compensation strategy depends on many assumptions and details. Conundrums like this are the reason why the FluidNC developers decline to support backlash compensation. As I said, if anyone else is willing to take it on, feel free to maintain and support a fork.

[nsiatras]

@MitchBradley

Backlash compensation minimizes the small gaps or slack between mating components, such as gears, lead screws, or ball screws. These gaps cause a delay in movement when reversing direction, leading to inaccuracies in positioning. Backlash compensation is not related to milling strategies.

Backlash compensation can be achieved with the following methods

1. Software Compensation (Motion Controller)
2. Mechanical Compensation (Preloaded Ballscrews, Anti-Backlash Gears etc.)
3. Electronic Compensation (Servo Systems with Linear encoders)

Here we discuss Method 1 - Software Compensation.

In software compensation, the motion controller's software keeps track of the backlash amount and offsets movements accordingly. When the system reverses direction, the software commands an extra movement equal to the measured backlash to ensure accurate positioning.

If you take a look at the photos I uploaded 3 years ago, you can see that software compensation, when used with a machine that has been built to milling machine specifications, gives good results. Sloppy and lightweight machines are not intended to be milling machines. Perhaps someone could build a lightweight machine and use it as a laser or plasma cutter. Even in this case, the software compensation would be useful with machines using rack and pinion.

PS. I 've implemented the Backlash Compensation algorithm in RabbitGRBL.
It is not difficult to implement it on FluidNC

Code: https://github.com/SourceRabbit/RabbitGRBL/tree/main/RabbitGRBL/src/Backlash
Demo Video: https://www.youtube.com/watch?v=-t-U46T7R6s