Backlash Compensation and M425

[marcio-ao]

This implements backlash compensation on X, Y and Z. This version implements a more advanced algorithm than proposed in #7579 and is a result of months of internal testing as we led up to the release of our Mini 2.

The original implementation proposed in #7579 worked by inserting a new planner block that would cause the motors to rapidly take up any backlash immediately following a motor direction change. Our testing indicated that while this got rid of the backlash, it caused a significant seam on the print due to the momentary pause and vibrations caused by the discontinuity in velocity and acceleration. The new algorithm presented here is less aggressive and has two modes:

1. The backlash correction steps are added to the planner block in which the direction change takes place. This reduces the appearance of seam by spreading the correction over one segment, but may still show a seam if the segments are very short.
2. When BACKLASH_SMOOTHING is enabled, the backlash correction is applied over one or more segments, reducing the appearance of a seam even for short segments. However, BACKLASH_SMOOTHING requires more storage and CPU overhead, so this is optional.

This PR also adds a new "M425" command. When enabled, it makes backlash compensation tunable at run-time:

   M425: Enable and tune backlash correction.
   
      F[fraction]     Enable/disable/fade-out backlash correction (0.0 to 1.0)
      S[smoothing_mm] Distance over which backlash correction is spread
      X[distance_mm]  Sets the backlash distance on X (0 to disable)
      Y[distance_mm]                         ... on Y
      Z[distance_mm]                         ... on Z

  Type M425 without any arguments to show active values.

Additionally, MEASURE_BACKLASH_WHEN_PROBING allows the backlash to be measured while probing during G29. If the G29 is followed by "M425 F1 Z" it enables backlash compensation with the measured value of backlash on Z.

There is the possibility of a similar feature called MEASURE_BACKLASH_WHEN_HOMING that could work on X, Y and Z but this PR does not implement it yet.

There is also a MEASURE_BACKLASH_WHEN_HOMING that reads hysteresis when homing using G28. If the G28 is followed by "M425 F1 X Y Z" it enables backlash compensation with the measured value of backlash on X, Y and Z. Although this measurement method also ends up measuring any hysteresis of the switch, so it may not be sufficiently accurate to be measure backlash. Manual tuning may be required.

UPDATE: I removed MEASURE_BACKLASH_WHEN_PROBING and MEASURE_BACKLASH_WHEN_HOMING since I think the better way to do this is to implement a separate GCODE G425 that runs an auto-calibration routine.

-- Marcio

[marcio-ao]

@thinkhead: In "probe.cpp", I added some code to measure the backlash, however, I am not happy with the crazy #ifdefs. It seems like there should be a better way to read the probe and/or endstop pins. Looking for suggestions on how to make this code better:

#if ENABLED(MEASURE_BACKLASH_WHEN_PROBING)
  #if ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
      #if defined(Z_MIN_ENDSTOP_INVERTING)
          #define TEST_PROBE_PIN !READ(Z_MIN_PIN)
      #else
          #define TEST_PROBE_PIN  READ(Z_MIN_PIN)
      #endif
  #else
      #if defined(Z_MIN_PROBE_ENDSTOP_INVERTING)
          #define TEST_PROBE_PIN !READ(Z_MIN_PROBE)
      #else
          #define TEST_PROBE_PIN  READ(Z_MIN_PROBE)
      #endif
  #endif

  extern float   backlash_measured_mm[];
  extern uint8_t backlash_measured_num[];

  /* Measure Z backlash by raising nozzle in increments until probe deactivates */
  static void measure_backlash_with_probe() {
    if(backlash_measured_num[Z_AXIS] == 255) return;

    float start_height = current_position[Z_AXIS];
    while(current_position[Z_AXIS] < (start_height + BACKLASH_MEASUREMENT_LIMIT) && TEST_PROBE_PIN) {
        do_blocking_move_to_z(current_position[Z_AXIS] + BACKLASH_MEASUREMENT_RESOLUTION, MMM_TO_MMS(Z_PROBE_SPEED_SLOW));
    }

    /* We average the backlash from all probe points, so keep track of number of measurements */
    backlash_measured_mm[Z_AXIS] += current_position[Z_AXIS] - start_height;
    backlash_measured_num[Z_AXIS]++;
  }
#endif

This is also the reason I did not implement MEASURE_BACKLASH_WHEN_HOMING yet ... the #ifdefs would have to account for homing direction as well as bit inversion and it would be pretty hairy.

[TheSFReader]

Great Feature ! Thanks ! I wanted (once again) to use Marlin as firmware for a "not so 3Dprinter" drawing machine with crappy BYJ stepper motors which have massive backlash, and didn't know how to compensate for that. This feature seems to fill my need beautifully ! Thanks !

(Edit : Urghhh,I see how this comment coud be seen as comparing your hardware to crappy motors, but that's clearly not the case !!!!)

[marcio-ao]

@TheSFReader : No problem! Glad this feature is useful to you!

[hectori4502]

hello marcio-ao Thank you very much
(Rostock Max V2 MKSv1.4 TMC2208)
in my first test the gcode 425 works fine, but when I turn off the printer the values are reset.
Another thing that happens is when I use 3 decimals the backlash is reset to zero.

[marcio-ao]

@hectori4502: Yes, the values are not stored to EEPROM. This would need to be implemented. It's not probably something I will implement since our printers will probe for the backlash. As for the three decimal place limitation, I don't know about that either. Possibly some limitation on parser.value_float. Perhaps @thinkyhead can comment on this.

[hectori4502]

Hello, I want to share these tests. I am very happy with the results
#define BACKLASH_SMOOTHING 3 // mm (the steps changed from 100mm to 98mm and duplicates the backlash. Can it be for my 8bits board?)

[marcio-ao]

the steps changed from 100mm to 98mm and duplicates the backlash. Can it be for my 8bits board?

@hectori4502 : I don't understand what you mean by this. The backlash compensation should not change the steps/mm. Earlier I had encountered an issue in which Marlin was discarding certain segments due to the check against MIN_STEPS_PER_SEGMENT, and if this happens on segments to which the backlash compensation was applied, it will cause an accumulation of errors and the print will be shortened in Z. However, this was fixed by putting the call to add_backlash_correction_steps after it has already been determined that at least one of the axis steps is greater than MIN_STEPS_PER_SEGMENT.

I have not tested my code in delta printers, so it is possible there it is not working correctly with deltas.

[hectori4502]

marcio-ao
the steps changed from 100mm to 98mm and duplicates the backlash. Can it be for my 8bits board?
only when I set // #define BACKLASH_SMOOTHING 3 // mm.

[thinkyhead]

I am not happy with the crazy #ifdefs.

Z_MIN_ENDSTOP_INVERTING is a true or false value, so this should be used:

#if ENABLED(Z_MIN_PROBE_ENDSTOP)
  #define TEST_PROBE_PIN (READ(Z_MIN_PROBE_PIN) != Z_MIN_PROBE_ENDSTOP_INVERTING)
#else
  #define TEST_PROBE_PIN (READ(Z_MIN_PIN) != Z_MIN_ENDSTOP_INVERTING)
#endif

(Same as _TRIGGERED_WHEN_STOWED_TEST.)

[thinkyhead]

Rebased and added a commit with some optimizations, bugfixes, and stylistic adjustments.

[MasterPIC]

Do you think a "systematic" backlash should be expected on cheap 3D printers?

[GMagician]

@MasterPIC backlash exists pratically in every machine. No backlash means machine stuck, the difference is only "entity".

[MasterPIC]

@GMagician I was referring to the characterization of backlash.
If its variance is huge then I don't know if compensation is worth it. This is the reason why I asked about what we should expect from a cheap 3D printer...

[GMagician]

@MasterPIC sorry, I think I bad translated your post. English is not my language

[MasterPIC]

@GMagician No need to say sorry... ;-)

[forkoz]

I look forward to trying this w/ a 32 bit board. You can auto measure Z backlash with the probe but how can it measure X/Y?

[marcio-ao]

I look forward to trying this w/ a 32 bit board. You can auto measure Z backlash with the probe but how can it measure X/Y?

@forkoz: If you have endstops, you could use them to measure backlash in X and Y. If you're using Trinamics and sensorless homing, then it would not be possible, alas.

[marcio-ao]

I added an implementation of MEASURE_BACKLASH_WHEN_HOMING, but have not tested it because our printers no longer have endstops. If anyone is willing to give it a go, I'd appreciate it.

[thinkyhead]

There was a commit labeled "Keep this planner change?" which I guess should have been removed.

[marcio-ao]

@thinkyhead: Ah. It looks correct now. If anything got missed, I can submit a patch on Monday.

I'm taking off now, so you can have it without us stepping on each other toes ;)

[thinkyhead]

Have a fab weekend, and I'll try not to break anything too badly! Thanks for being patient on this PR and others that have hung around for a long time. I have more time to play catch-up now, so these should go a lot quicker.

[VanessaE]

I've been watching this one for a while, glad to see it's been merged. Has anyone come up with a test pattern (along the lines of the linear advance test) to help tune this feature?

EDIT: This model does the job beautifully: https://www.thingiverse.com/thing:2256550

[MasterPIC]

I'm testing it on my cheap printer (Anet A8) by a dial indicator.
Sending the same G1 command - after G91 - (e.g. G1 X1 F20 several times) I found the position error affected by high variance (obviously it's not related to the firmware).
Anyway it seems that backlash compensation makes better precision achievable when trying to move the nozzle to the previous positions. Without backlash compensation frankly I was not able to figure out what was happening...
So I like the feature; but it made me realize my printer is not as good as expected: I had never tested my printer by a dial gauge, except for leveling purposes...

[hectori4502]

I tested, works fine.
but M425 M500 do not save yet.
Compiling give this warning:

[marcio-ao]

@hectori4502: Yup. It won't save to EEPROM. This is a project for someone who understands the EEPROM stuff better than I do.

I can probably make a patch for the warning. non-zero is only used when BACKLASH_SMOOTHING_MM is enabled.

[hectori4502]

Hi marcio-ao,
I uncomment:
#define BACKLASH_SMOOTHING_MM 3 // (mm)

the warning was gone.
Thank you so much for everything.

[ManuGithubSteam]

Is this still in Marlin 1.09 ? I cant find the command in the config.h
I need it for my snappy printer as it is all self printed and has massice x backslash.

[thinkyhead]

@ManuGithubSteam — Marlin 2.0 is required.

[marcin-ose]

This is great work. It seems that backlash correction would make 3D-printed stepper motors (such as this amazing split-ring planetary stepper motor that runs on RAMPS - https://www.thingiverse.com/thing:1362555 ) practical for accurate drive applications. This opens up the possibility of DIY at the level of precision drive - yet one more step in making 3D printers more accessible in resource-scarce scenarios. Thoughts?

[marcio-ao]

@marcin-ose: It may help, but I don't know whether it will help enough. If you ever get a chance to try, please share your experiences!

[marcin-ose]

@marcio-ao Will do. What is the version of Marlin to use for a fresh start with backlash correction? I'm on Ubuntu 16.04, still using Marlin 1.0.

[marcio-ao]

We haven't tested or released Marlin 2.0 in any of our older printers, but if you want to try it, the FW files are here:

http://devel.lulzbot.com/software/Marlin/2.0.0.110

Use at your own risk!

[InsanityAutomation]

FWIW ive moved a few Taz 6 machines to various 2.0 snapshots from the repo above and most dates work fine. A few have extra menu items or things not meant for the machine, or other oddities but overall nothing major.

[VanessaE]

This has worked nicely on my i3 since its inception. Now I have a CoreXY as well -- any chance of getting backlash compensation for it as well?