Sensorless Homing Macro suggested in Klipper docs

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.