Reduce steppers current during homing

[agravelot]

It would be nice to reduce steppers current on homing macro like official prusa firmware. It will reduce this shock sound on homing, and will probably increase longevity of the hardware on the long run.

https://github.com/prusa3d/Prusa-Firmware/blob/2dcaae80d547259d17ae3b0aaaa11685d3168ef2/Firmware/variants/1_75mm_MK3-EINSy10a-E3Dv6full.h#L285

https://www.klipper3d.org/TMC_Drivers.html#using-macros-when-homing

[agravelot]

Also changing stallguard threshhold can be a good thing : https://github.com/prusa3d/Prusa-Firmware/blob/2dcaae80d547259d17ae3b0aaaa11685d3168ef2/Firmware/variants/1_75mm_MK3S-EINSy10a-E3Dv6full.h#L276

[confuzled-dev]

This seems relevant as I feel like the homing is far more aggressive on this setup of klipper relative to stock fw.

[confuzled-dev]

Agravelot, are you capable of implementing the worked needed for this change? If so, I can serve as a third party test.

[agravelot]

I'm currently running this config, you may increase currents because it's quite noisy.

# Source : https://github.com/Prutsium/3D-Druckerplausch-Klipper/blob/main/Klipper_cfg/Prusa_Universal_Config_Revised/Macros/homing.cfg
[gcode_macro _SENSORLESS_HOME_X]
gcode:
    {% set HOME_CUR = 0.13 %}
    {% set driver_config = printer.configfile.settings['tmc2130 stepper_x'] %}	
    {% set RUN_CUR = driver_config.run_current %}
    # There are two homes for X and Y to cover the case where we are already up
    # against the end-stop. The sensorless homing doesn't work well unless the
    # motor is in motion. So the first home, ensures we ARE up against the end-stop.
    # Then we move a short distance away from the end-stop, assured we won't crash 
    # into anything because we're starting on the end-stop, and then do a second homing. 
    SET_TMC_CURRENT STEPPER=stepper_x CURRENT={HOME_CUR}
    G28 X ; Zero X
    M400
    G1 X10 F1000
    M400
    G28 X ; Home X
    SET_TMC_CURRENT STEPPER=stepper_x CURRENT={RUN_CUR}

[gcode_macro _SENSORLESS_HOME_Y]
gcode:
    {% set HOME_CUR = 0.13 %}
    {% set driver_config = printer.configfile.settings['tmc2130 stepper_y'] %}	
    {% set RUN_CUR = driver_config.run_current %}
    # There are two homes for X and Y to cover the case where we are already up
    # against the end-stop. The sensorless homing doesn't work well unless the
    # motor is in motion. So the first home, ensures we ARE up against the end-stop.
    # Then we move a short distance away from the end-stop, assured we won't crash 
    # into anything because we're starting on the end-stop, and then do a second homing. 
    SET_TMC_CURRENT STEPPER=stepper_y CURRENT={HOME_CUR}
    G28 Y ; Zero Y
    M400
    G1 Y10 F1000
    M400
    G28 Y ; Home Y
    SET_TMC_CURRENT STEPPER=stepper_y CURRENT={RUN_CUR}

[homing_override]
set_position_z:0 # Make printer think Z axis is at zero, so we can force a move upwards away from build plate
gcode:
    G90  
    G1 Z10 F1000 ; move up to prevent accidentally scratching build plate 
    _SENSORLESS_HOME_X
    _SENSORLESS_HOME_Y
    G1 X3 Y0 ; move x-axis and y-axis slightly
    M400 ; wait to finish move
    G28 Z ; Home Z
    G1 Z1 F700 ;

[confuzled-dev]

meaning because of the very low current it is louder than normal? Assuming it is exchanging noise for a lighter homing crash?

[agravelot]

Exactly
Just noticed, it's my Z-axis that is noisy, so it has nothing to do with the currents.

[confuzled-dev]

Have you increased you z travel speed? I have found the noise does not scale linearly. I feel like the vibrations are far more intense when z is active. I am looking to insulate the bottom of my bed and hope that it may also dampen some of the vibration

…

On Wed, May 10, 2023, 18:17 Antoine Gravelot ***@***.***> wrote: Exactly Just noticed, it's my Z-axis that is noisy, so it has nothing to do with the currents. — Reply to this email directly, view it on GitHub <#25 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGDEE44EICFNQ2MQLRJTR3XFQHYDANCNFSM6AAAAAAXB2EQ64> . You are receiving this because you commented.Message ID: ***@***.***>

[agravelot]

You're right, that's what I did for the original speed. But now it needs to be set somewhere else. I'm going to have to look into that sometime.

[confuzled-dev]

I have enabled this on my end and it is working amazingly. There are conflicts with Safe_Home which should likely be called out in your opening statement but this seems all-around better than the current implementation in the repo. Can you think of situations (even if extreme) where your approach would be less effective?

If not, I would suggest a PR for this change.