Sensorless Homing has a delay between tripping the limit sensor and clearing the limit sensor when retracting.
Many people that use sensorless homing have stopped using ‘homing_retract_distance’ from the stepper_x to avoid ‘Endpoint still triggered after retract’ errors or have gone the route of homing_override which comes with a number of unintended consequences. I use the safe_z_home and need to keep the function (Voron 2.4).
‘stepper_x’ already implements homing_retract_speed and homing_retract_dist, would it be possible to implement homing_retract_delay?
The intent is to wait x ms to give the axes time to clear the tripped state.
Of note, when testing, if I retract only 1mm, the axis backs up 1 mm and then hits the stop again but does not trigger the endpoint still triggered, if I retract 5mm, it only retracts and stays there. Guessing that there is no check for less than x mm on retract?
Not sure what you are reporting:
- Your points are well covered in the documentation including not to use
homing_retract_distance - Sensorless homing is not recommended for z-homing
safe_z_homeis only related to z-homing
thanks Sineos, I am not using sensorless homing for z, this is only x and y.
as mentioned in the documentation you linked, a pause and retract are recommended for the X and Y. The only way I can do this without homing_retract are to either override G28 and individually home each access in the macro, this works but does a safe_z for each G28.0 command. result is 3x safe_z hops on a home, but with this I can do a delay and retract. The preferred option is to pass through the original G28 rawparams and only do a single G28, this only gives a single safe_z hop but leaves no opportunity to do a retract outside of the stepper_x.
to clarify, I am not trying to do a second home on the axis, I am trying to move it away from the stop. If I set a value of 5 for the retract distance, the axis homes and moves away from the stop without an attempt to rehome.
I’m not really able to follow you. The process should be quite straightforward:
- Use sensorless homing along with the settings/macros from the documentation or from the Voron docs here
- Use
[homing_override]to combine this with your z-homing procedure, e.g., by usingG1 X... Y...to move to the desired location and then call the z-homing. This, of course, then depends on your Z-homing method.
I spent a day with homing_override and had a number of issues mainly around it marking axes as homed when they were not etc, so if I homed only x, all axes were marked as homed leading to undesirable outcomes.
The only reason to go to homing_override is to put in a pause before a direction change on home, but the cure (homing_overrride) introduces many other issues.
I use a cartographer probe so need to use safe_z (it is not pretty when it tries to home and the sensor is hanging over the side, who thought a 10mm build plate could flex that much!) The current combination of safe_z homing with an G28 macro rename to adjust the current along with the retract settings on the stepper_x has exactly the right behaviour, its just not reliable with the endstop still triggered error, if stepper_x and stepper_y had the option to put in a retract delay then the sensorless homing users would not need to override the homing function.
The current operation at the moment with the stepper config below is that the axes homes, touches the stop, backs up 5mm and then does the next axes. Its only the enstop error that occurs that is causing issues.
[stepper_x]
step_pin: PF13
dir_pin: PF12
enable_pin: !PF14
rotation_distance: 40
microsteps: 16
full_steps_per_rotation:200 #set to 400 for 0.9 degree stepper
endstop_pin: tmc2209_stepper_x:virtual_endstop
position_min: -2
position_endstop: 350
position_max: 350
homing_speed: 20 #Max 100
homing_retract_dist: 5
homing_positive_dir: true
if it helps to understand, this G28 replacement macro works as needed but has the undesirable save_z hop for each axes, i.e 3 hops.
(must set retract distance to 0 in the stepper config)
[gcode_macro G28]
#Replacement for G28 to enable current changes for sensorless homing.
rename_existing: G28.0
gcode:
M118 G28 Entering
# Detect homeall (no params)
{% set home_all = 'X' not in params and 'Y' not in params and 'Z' not in params %}
# Reduce homing current for X and Y steppers
{% if home_all or 'X' in params or 'Y' in params %}
M118 G28 _HOME_XY
{% set RUN_CURRENT_X = printer.configfile.settings['tmc2209 stepper_x'].run_current|float %}
{% set RUN_CURRENT_Y = printer.configfile.settings['tmc2209 stepper_y'].run_current|float %}
{% set HOME_CURRENT = 0.49 %}
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={HOME_CURRENT}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={HOME_CURRENT}
# Set relative movements
G91
{% endif %}
{% if home_all or 'X' in params %}
G28.0 X
G4 P1000
G0 X-5 F1200
{% endif %}
{% if home_all or 'Y' in params %}
G28.0 Y
G4 P1000
G0 Y-5 F1200
{% endif %}
{% if home_all or 'Z' in params %}
G28.0 Z
{% endif %}
# Reset homing current for X and Y steppers
{% if home_all or 'X' in params or 'Y' in params %}
M118 G28 _HOME_X RESET
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={RUN_CURRENT_X}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={RUN_CURRENT_Y}
G90
{% endif %}
111I still do not really get, what you are up to and the macro seems not suited to achieve proper homing.
I’d suggest the following approach:
- Delete all homing related items from your config, e.g. the above macro, homing overrides, safe z home etc.
- Replace them with the following code:
# Global Variables sensorless homing
[gcode_macro global]
variable_xy_run_current: 0.8
variable_xy_home_current: 0.6
gcode: #intentionally left empty
#### Homing macros for sensorless homing
[gcode_macro _HOME_X]
gcode:
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_home_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_home_current}
# Wait for StallGuard registers to clear
G4 P500
G28 X
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_run_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_run_current}
G91
# Back-off a little
G1 X15 F1200
[gcode_macro _HOME_Y]
gcode:
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_home_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_home_current}
# Wait for StallGuard registers to clear
G4 P500
G28 Y
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_run_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_run_current}
G91
# Back-off a little
G1 Y-15 F1200
[homing_override]
axes: xyz
gcode:
{% set home_all = 'X' not in params and 'Y' not in params and 'Z' not in params %}
# Set a preliminary z-position and get some z-headroom
# Make sure the bed is not fully at z-max
# May or may not be needed
SET_KINEMATIC_POSITION Z=0
G1 Z4 F1200
{% if home_all or 'X' in params %}
_HOME_X
{% endif %}
{% if home_all or 'Y' in params %}
_HOME_Y
{% endif %}
{% if home_all or 'Z' in params %}
G90
G1 X150 Y150 F1200 # <-------- set this to the middle of your bed
G28 Z
G1 Z10 F1200
{% endif %}
Observe the comments and set the values according to your needs.
When it does not work, post a klippy.log
I will test as soon as the printer is free.
thank you.
Hi Sineos,
I have tested the configuration you have provided and it works correctly for a “home all” from restart.
If after a restart I just home say the X axis, all axes show as being homed when they are not, I understand the I can just not home a single axis but it may catch someone out.
If I rehome (using home all) after the printer has been homed, it does a Z hop again, this is not the end of the world, just proving the feedback.
Please post the log.
klippy (9).log (368.4 KB)
Log attached as requested, on the last restart of the host, after the reboot i homed just X and all axes showed homed. I then performed a home all.
The effect of all axes being homed is caused by this statement. SET_KINEMATIC_POSITION causes all axes to be considered homed, which can be dangerous. There are ongoing discussions about whether this can be improved, but it is not a trivial task. This command is considered a “debugging” or “diagnostic” command.
You will need to evaluate if this is necessary for your machine and workflow.
An option could be to move this statement down to:
{% if home_all or 'Z' in params %}
SET_KINEMATIC_POSITION Z=0 # <-------- !!
G1 Z4 F1200 # <-------- !!
G90
G1 X150 Y150 F1200
G28 Z
G1 Z10 F1200
{% endif %}
This has the “negative” effect that the X/Y movement starts without first getting a bit of z-headroom. This is something you will need to decide.
Thank you Sineos, The current macros while not fool proof enable the printer to be home correctly.