AndrewJ
New member
- Printer Model
- Voron 2
- Extruder Type
- Clockwork 2
- Cooling Type
- Stealthburner
Hopefully it's ok to post in this forum....
I have installed and configured Klicky to my 2.4. I can attach/dock/QGL/Calibrate_Z successfully with no issues. However, I do have an issue with Homing. Klicky provides a Homing Override implementation in its Macros and I'm not sure it's working properly so I'm interested in seeing if this is a problem with my setup or not.
What is happening that when a full home is initiated, where no axis has been homed previously, then "Homing Override" is setting a Kinematic Position to X=Y=Z=0, irrespective of the toolhead's actual position. Normally, this isn't an issue except when the toolhead is already at a high Z position, e.g. Z=250. After redefining that position as Z=0, it then wants to set a Safe_Z = 25 and thus try and raise the toolhead to an actual Z=275. This obviously causes the toolhead to crash into something - I couldn't tell what, I was too busy panicking trying to find the emergency stop button and I don't want to try that again!
I guess, generally, it wouldn't be an issue as long as the toolhead was at a height < max_z - safe_z (250 - 25 in my case) but if the printer does lose axes' homes at that high Z, the only thing I can think of to resolve it is to (a) remember it is going to happen; and (b) turn off steppers and manually lower the gantry before homing.
Here's the relevant bit of code from Klicky Macros:
Now, according to the comment this runs because Z_Hop is enabled in Klicky_Variables as per instructions in the Klicky GitHub:
BUT, I can't see anything in the code that checks whether Z_Hop is enabled or not. In any case on a 2.4 it should be True. I set toolhead position to the middle of the bed, reset Klipper then ran a home all with debug on and this is the console output:
You can see what is happening at lines 14 and 13.
Any ideas? Is this just me or does it look like a problem? Is there some other configuration I may have missed - it's a new build so I may have missed something else.
I have installed and configured Klicky to my 2.4. I can attach/dock/QGL/Calibrate_Z successfully with no issues. However, I do have an issue with Homing. Klicky provides a Homing Override implementation in its Macros and I'm not sure it's working properly so I'm interested in seeing if this is a problem with my setup or not.
What is happening that when a full home is initiated, where no axis has been homed previously, then "Homing Override" is setting a Kinematic Position to X=Y=Z=0, irrespective of the toolhead's actual position. Normally, this isn't an issue except when the toolhead is already at a high Z position, e.g. Z=250. After redefining that position as Z=0, it then wants to set a Safe_Z = 25 and thus try and raise the toolhead to an actual Z=275. This obviously causes the toolhead to crash into something - I couldn't tell what, I was too busy panicking trying to find the emergency stop button and I don't want to try that again!
I guess, generally, it wouldn't be an issue as long as the toolhead was at a height < max_z - safe_z (250 - 25 in my case) but if the printer does lose axes' homes at that high Z, the only thing I can think of to resolve it is to (a) remember it is going to happen; and (b) turn off steppers and manually lower the gantry before homing.
Here's the relevant bit of code from Klicky Macros:
Code:
...
#On the first G28 after motors losing power, moves the Z to safe_z distance, if z_hop is enabled
{% if 'x' not in printer.toolhead.homed_axes and 'y' not in printer.toolhead.homed_axes and 'z' not in printer.toolhead.homed_axes%}
{% if verbose %}
{ action_respond_info("No axis homed") }
{% endif %}
_KlickyDebug msg="homing_override no axis homed, setting position as X=Y=0 Z={kinematic_z}"
SET_KINEMATIC_POSITION X=0 Y=0 Z={kinematic_z}
M400
_KlickyDebug msg="homing_override moving toolhead to {safe_z}mm from {printer.gcode_move.gcode_position.z}mm"
{% if verbose %}
{ action_respond_info("moving to a safe Z distance") }
{% endif %}
G0 Z{safe_z} F{z_drop_feedrate}
...Now, according to the comment this runs because Z_Hop is enabled in Klicky_Variables as per instructions in the Klicky GitHub:
Code:
...
variable_safe_z: 25 # Minimum Z for attach/dock and homing functions
# if true it will move the bed away from the nozzle when Z is not homed
variable_enable_z_hop: CHECK_COMMENT # True on the v2.4, False on v1.8, Trident and Legacy
...BUT, I can't see anything in the code that checks whether Z_Hop is enabled or not. In any case on a 2.4 it should be True. I set toolhead position to the middle of the bed, reset Klipper then ran a home all with debug on and this is the console output:
Code:
15:50 _klicky_status_ready activating the LED STATUS_READY
15:50 probe: TRIGGERED
15:50 _Home_Z_ toolhead too low, raising it to 25.0mm from 25.0mm
15:50 _Home_Z_ Homing Z G28 Z
15:50 _Home_Z_ moving to Z endstop position G0 X205 Y305 F12000
15:50 _Home_Z_ XY Axis homed
15:50 probe: TRIGGERED
15:50 Dock_Probe probe already docked, doing nothing
15:50 Probe already docked
15:50 homing_override backing off Y endstop, G0 Y295.0 F12000
15:50 homing_override Homing Y, G28 Y0
15:50 homing_override backing off X endstop, G0 X287.0 F12000
15:50 homing_override Homing X, G28 X0
15:50 homing_override moving toolhead to 25mm from 0.0mm
15:50 homing_override no axis homed, setting position as X=Y=0 Z=0
15:50 _klicky_status_homing activating the LED STATUS_HOMING
15:50 homing_override goint to home all axes
15:50 probe: TRIGGERED
15:50 Homing Z
15:50 Homing Y
15:50 Homing X
15:50 X or Y not homed, forcing full G28
15:50 moving to a safe Z distance
15:50 No axis homed
15:50 G28
15:49 Klipper state: Disconnect
15:49 RESTART
15:49 G1 Z100 F1500
15:49 G1 Y150 F6000
15:49 G1 X150 F6000Any ideas? Is this just me or does it look like a problem? Is there some other configuration I may have missed - it's a new build so I may have missed something else.
