Sensorless Homing Macro suggested in Klipper docs

Macros
1

I am trying to understand this macro.

Using Macros when Homing/TMC_Drivers.html#using-macros-when-homing)

After sensorless homing completes the carriage will be pressed against the end of the rail and the stepper will exert a force on the frame until the carriage is moved away. It is a good idea to create a macro to home the axis and immediately move the carriage away from the end of the rail.

It is a good idea for the macro to pause at least 2 seconds prior to starting sensorless homing (or otherwise ensure that there has been no movement on the stepper for 2 seconds). Without a delay it is possible for the driver’s internal stall flag to still be set from a previous move.

It can also be useful to have that macro set the driver current before homing and set a new current after the carriage has moved away. This also allows a hold_current to be set during prints (a hold_current is not recommended during sensorless homing).

An example macro might look something like:

[gcode_macro SENSORLESS_HOME_X]
gcode:
    {% set HOME_CUR = 0.700 %}
    {% set driver_config = printer.configfile.settings['tmc2209 stepper_x'] %}
    {% set RUN_CUR = driver_config.run_current %}
    {% set HOLD_CUR = driver_config.hold_current %}
    # Set current for sensorless homing
    SET_TMC_CURRENT STEPPER=stepper_x CURRENT={HOME_CUR} HOLDCURRENT={HOME_CUR}
    # Pause to ensure driver stall flag is clear
    G4 P2000
    # Home
    G28 X0
    # Move away
    G90
    G1 X5 F1200
    # Set current during print
    SET_TMC_CURRENT STEPPER=stepper_x CURRENT={RUN_CUR} HOLDCURRENT={HOLD_CUR}

The resulting macro can be called from a homing_override config section or from a START_PRINT macro.

It appears to set the hold current to whatever the run current is set at. In this case 0.7 A . I presume this is an example value and should be set to the machines requirements.
There is also advice in the docs that the hold current should not be set during sensorless homing. Does not set imply 0.0 A ?

I also have a Corexy printer, and I have made a macro for x and one for y, would I need to not set hold current for both x and y in each macro ?

I am using BLTouch as my Z endstop and am working my way to having a homing overide macro that provides same as safe_z_home as I am aware that are mutually exclusive.

I see from various sources that people are happily doing corexy sensorless homing. I am using a board with integrated TMC22009 so no problems connecting uart and diag pins. Just need to get homing sequence right.

Will carry on RTFMing.

2

I just remembered something I read elsewhere. It appears I need a homing_overide section that does zy and then z homing in one go and there will be no individual homing of x, y or z.

That way I can turn off hold current for both x and y when homing and back on again for printing without going in logical circles.

3

I hope replying to oneself is within the guidelines.

Does “not set” mean revert to default, in which case hold_current would be the same as run_current.

Anyway watching the console output as the homing macro runs seems to show it is all working and x and y are set back to the printer.cfg values for run_current and hold_current.

Next question, why do I want a different run_current for homing and printing. I note that the threshold can be easier to tune with a different current.

Thanks for listening.

4

I will try to address some questions.

It appears to set the hold current to whatever the run current is set at. In this case 0.7 A . I presume this is an example value and should be set to the machines requirements.

With Trinamic drivers and sensorless homing, the settings are extremely printer specific. They can be “ballparked” but will ultimately require some tuning by the end user to work.

There is also advice in the docs that the hold current should not be set during sensorless homing. Does not set imply 0.0 A ?

In the macro example above, the 700mA setting is merely being used as an example for the macro. I personally use sensorless on a variety of machines and they all have different settings. I have not seen any difference between setting a hold current and not setting a hold current. In this particular macro example, you could replace

HOLDCURRENT={HOME_CUR}

with

HOLDCURRENT=0

if you wish to disable holding current during homing.

I also have a Corexy printer, and I have made a macro for x and one for y, would I need to not set hold current for both x and y in each macro ?

You would need to set the hold current for both X and Y with each homing call.

I am using BLTouch as my Z endstop and am working my way to having a homing overide macro that provides same as safe_z_home as I am aware that are mutually exclusive.

The way Klipper’s gcode system works is that commands are created as objects in the program. So the G1 move command is created and any time G1 is sent through the console, that object is called and executed. It is possible to override or replace G1 with a stand-in command and the old G1 command is renamed.

In the context of homing_override this is a specific module that simplifies the overriding process into a macro to handle some or all homing calls to some or all axes.

So this is possible to do via the macro system using homing_override. The override gcode section would need to examine specific machine states to determine what to do with regards to positioning the toolhead for Z axis homing. It would be less than straightforward due to how templates are evaluated within the macro system.

I see from various sources that people are happily doing corexy sensorless homing. I am using a board with integrated TMC22009 so no problems connecting uart and diag pins. Just need to get homing sequence right.

I am presently using sensorless on a CoreXY machine and it works just fine

That way I can turn off hold current for both x and y when homing and back on again for printing without going in logical circles

The way I have done this in the past is to sniff the parameters of the G28 command and have it handle each of the axes called in the order I want.

[homing_override]
axes:                             xyz
gcode:   
    {% set config   = printer['configfile'].config %}
        
    #bed mesh must be cleared prior to homing
    # if bed mesh reloading is requested, the current profile name
    # must be stored to be reloaded later
    {% if 'bed_mesh' in config %}
        {% if printer.bed_mesh.profile_name %} 
            {% set lastMeshProfile = printer.bed_mesh.profile_name %}
        {% endif %}
       BED_MESH_CLEAR
    {% endif %}
 
    #reset parameters
    {% set requested = {'x': False,
                        'y': False,
                        'z': False} %}
 
    #sniff gcode parameters for
    #which axes have been requested for homing
    {% if   not 'X' in params
        and not 'Y' in params 
        and not 'Z' in params %}
     
        {% set X, Y, Z = True, True, True %}
 
    {% else %}
        {% if 'X' in params %}
            {% set X = True %}
            {% set null = requested.update({'x': True}) %}
        {% endif %}       
        {% if 'Y' in params %}
            {% set Y = True %}
            {% set null = requested.update({'y': True}) %}
        {% endif %}     
        {% if 'Z' in params %}
            {% set Z = True %}
            {% set null = requested.update({'z': True}) %}
        {% endif %}        
    {% endif %}

    __Homing_Reduce_Motor_Current

    {% if X %}
        G28 X0
    {% endif %}
 
    {% if Y %}
        G28 Y0
    {% endif %}
      
    {% if Z %}
		#You can do your logic for safe z here
		G28 Z0
    {% endif %}
 
     __Homing_Reset_Motor_Current

    {% if 'bed_mesh' in config and lastMeshProfile %}
       BED_MESH_PROFILE LOAD={ lastMeshProfile }
       { action_respond_info("Loaded Bed Mesh Profile (%s)" % (lastMeshProfile)) }
    {% endif %}

Does “not set” mean revert to default, in which case hold_current would be the same as run_current.

I dont understand

Next question, why do I want a different run_current for homing and printing. I note that the threshold can be easier to tune with a different current.

I believe it has to do with how the driver detects the peaks in back EMF when the motor approaches a stall. It seems to be more sensitive at lower currents which offer a gentler homing experience. If the run current is too close the the max current then it might overflow the internal buffer or something.

5

Dear mental,

Thanks for your reply.

I am now rebuilding my hypercube with MGN12 rails for XY so my Mechanical Load will change and I will need to tune the sensorless homing properly.

I was interested to see that holding current may not be so important.

Thanks for posting the macro.

6

The recommendation is that the “hold current” be the same as the “run current” during sensorless homing. That is, you do not want to reduce the current to the motor when the driver detects that the motor is not moving - changing the current during sensorless homing (for any reason) causes odd and confusing behavior.

The example macros from the documentation demonstrate how one can ensure the “hold current” and “run current” are the same during sensorless homings.

-Kevin

7

Thanks for clarifying.

I have used the macro and watched the values for run_current and hold_current being set. I think I’ve got it now.

I like the instant feedback of changing printer.cfg and restarting compared to compiling and waiting.