Basic Information:
Printer Model: Custom CoreXY
MCU / Printerboard: rPi 4B, Octopus V1.1 & FLY SHT42
klippy.log (851.2 KB)
I have two issues that need to be addressed when trying to implement sensorless homing that will allow SAVE_CONFIG updates from functions like SHAPER_CONFIGURATION. This is a continuation to Problem with SHAPER_CALIBRATE & TMC2209s with Sensorless Homing
1. Updating printer.toolhead.homed_axes after single axis homing:
I’m using the following code to implement TMC2209 sensorless homing on a CoreXY printer by overriding the G28 gcode. I want to be able to home individual axes (which is problematic to do when using [homing_override] - I couldn’t get reliable single axis requests received):
[gcode_macro _HOME_X]
gcode:
M118 Execute _HOME_X
# Always use consistent run_current on A/B steppers during sensorless homing
{% set RUN_CURRENT = printer.configfile.settings['tmc2209 stepper_x'].run_current|float %}
{% set HOME_CURRENT = 0.7 %}
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={HOME_CURRENT}
# Wait just a second… (give StallGuard registers time to clear)
G4 P1000
# Home
G28.1 X
# Move away
G91
G1 X-10 F1200
# Wait just a second… (give StallGuard registers time to clear)
G4 P1000
# Set current during print
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={RUN_CURRENT}
[gcode_macro _HOME_Y]
gcode:
M118 Execute _HOME_Y
# Set current for sensorless homing
{% set RUN_CURRENT = printer.configfile.settings['tmc2209 stepper_y'].run_current|float %}
{% set HOME_CURRENT = 0.7 %}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={HOME_CURRENT}
# Wait just a second… (give StallGuard registers time to clear)
G4 P1000
# Home
G28.1 Y
# Move away
G91
G1 Y+10 F1200
# Wait just a second… (give StallGuard registers time to clear)
G4 P1000
# Set current during print
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={RUN_CURRENT}
[gcode_macro G28]
rename_existing: G28.1
gcode:
{% if "x" == printer.toolhead.homed_axes %} #### - Output Current State
M118 X Homed Upon Entry
{% elif "xy" == printer.toolhead.homed_axes %}
M118 XY Homed Upon Entry
{% elif "xyz" == printer.toolhead.homed_axes %}
M118 All Homed Upon Entry
{% else %}
M118 Nothing Homed Upon Entry
{% endif %}
{% if 'X' in params %} #### - Output G28 gcode
M118 "G28 X"
{% elif "Y" in params %}
M118 "G28 Y"
{% elif "Z" in params %}
M118 "G28 Z"
{% else %}
M118 "G28"
{% endif %}
{% set MOVEUP = true %} ### Specify Z Axis movment
{% if MOVEUP %}
SET_KINEMATIC_POSITION Z=0
G0 Z10 F600
{% else %} ### Move Down
SET_KINEMATIC_POSITION Z=10
G0 Z0 F600
{% endif %}
{% if 'X' in params %}
_HOME_X
# printer.toolhead.homed_axes = "x"
{% elif "Y" in params %}
{% if ('x' != printer.toolhead.homed_axes) and ('xy' != printer.toolhead.homed_axes) and ('xyz' != printer.toolhead.homed_axes) %}
_HOME_X
{% endif %}
_HOME_Y
# printer.toolhead.homed_axes = "xy"
{% else %} ### Either "Z" in params or no params which means all three axes
{% if ('xy' != printer.toolhead.homed_axes) and ('xyz' != printer.toolhead.homed_axes) %}
{% if ('x' != printer.toolhead.homed_axes) and ('xy' != printer.toolhead.homed_axes) and ('xyz' != printer.toolhead.homed_axes) %}
_HOME_X
{% endif %}
_HOME_Y
{% endif %}
G28.1 Z ### This was put in for a test to see if "safe_z_homing" has returned
{% endif %}
The start of the [gcode_macro G28] code displays on the console the request and the current homing state of the printer. Next, the gantry is moved up to ensure no collisions with parts of the printer (something other people don’t do as I discovered to my great anger) - I can set it to go down when the gantry starts hitting the upper limit while I was testing the macros.
Next, I look for specific axes to home after first looking to see that the prequisite axes have been homed (ie “X” must be homed before anything else, “Y” must be homed before “Z”) and if they aren’t (based on the information that comes from printer.toolhead.homed_axes) then the code homes them before doing the requested homing.
For example, homing the “Y” axis without the “z” axis being homed first executes like (note the sequence of the action takes place from the bottom up):
In which the X axis is homed first. This is exactly what should happen.
BUT, if I home the X axis first and then home the Z axis, when the macro invocation polls printer.toolhead.homed_axes, it returns the information that all the axes are homed and moves along merrily as if BOTH X AND Y were homed as you can see in this console log:
I believe that the reason for the gantry crash I experienced in Problem with SHAPER_CALIBRATE & TMC2209s with Sensorless Homing.
So either printer.toolhead.homed_axes needs to be updated correctly when working with sensorless homing or there needs to be a way to update it from the macro code. Maybe there is a way to define a global variable that works across macro invocations (which would be an acceptable work around for cases like this), but I haven’t found a reference to being able to do that.
I would consider this a moderate to severe issue because it can result in damage to the printer.
2. Getting the Z axis probe to check the surface height twice:
This one is really confusing to me. My other printers (Voron and my other custom design) probe the bed surface twice, once at a fair clip and a second time much slower to get an accurate reading of the bed position. Any time I’ve made any changes to the X/Y homing to support sensorless homing, G28 (and the built in homing function) just goes down once at the faster speed with the resulting position information being quite inaccurate.
I can’t find any reference to a different gcode for function call for the dual probing operation. This seems to have been discussed in a couple of bug identifications (the one that discussed multiple Z axis probing is Multi samples support for safe_z_home · Issue #3573 · Klipper3d/klipper · GitHub).
Could somebody please point me in the right direction or explain how I can add this functionality to my homing macro(s) myself?
