klipper
klipper copied to clipboard
docs: Clarify homing_override gcode: requirement
The previous wording made it seem like you could not implement a G-Code macro that handled single-axis homing, and instead had to home ALL axes every time. Hopefully the updated text is less misleading, as single-axis homing works fine if your G-Code macro is smart enough to do so.
This doesn't look right to me. It's a common confusion among users that if they have axes: z
then they only need to home z in the gcode
- which is definitely not the case. The gcode
must home all axes regardless of the axes
option. The updated wording in this PR I fear would lead to confusion. I'm not sure we need to change the wording, as someone doing an advanced macro may not need a more detailed description.
Cheers, -Kevin
Okay, so it looks like I've fallen into the common confusion pitfall here.
To clarify: if I implement a homing_override
gcode macro that allows G28 X
to home only the X axis, leaving printer.toolhead.get('homed_axes')
returning 'x'
… am I doing it right, or wrong? Is this supposed to work, or have I hit some weird corner case? Assuming that the same macro properly homes X, Y, and Z if I just issue a G28
with no arguments.
EDIT: Also for the sake of this question, let's assume the axes
option is set to xyz
please.
I'm not really sure what you are asking. Some people have tried to set axes: z
and only home z in the gcode. That fails to work correctly as the gcode
must home all axes. The failure, for example, is that G28 Y0 Z0
would invoke the requested gcode
but if that gcode
doesn't home all axes then Y isn't homed even though it was requested to be homed. So the documentation tries to make it clear that the user must home all axes in gcode
regardless of the axes
setting.
I'm not really sure what one could ultimately obtain with macros. I do think the documentation should be clear on the above point even if there is some intricate way of accomplishing something else.
Cheers, -Kevin
Some people have tried to set
axes: z
and only home z in the gcode
Yes, I understand your concern about the axes: z
case. But I'm not asking about this case, I'm asking about axes: xyz
.
I want to know if it's okay to have a [homing_override]
gcode macro that allows single-axis homing if the user sends G28 X0
or G28 Y0
, without also homing all of the other axes. Because this works for me, today.
The reason I'm asking is, the way the documentation is currently worded makes it sound like I may be "breaking the rules" of what Klipper expects of a homing_override macro. If this functionality working is some unexpected corner case that you consider a bug, I want to stop doing it.
I don't know if it will work properly, but it is fine with me if you want to do it!
For the documentation, I think it best to keep it simple - the gcode
parameter is intended to home all axes.
Cheers, -Kevin
I will simply add that using a homing_override that only homes one axis will also lead to problems when using G28
with no parameters. That will always run the override gcode, and the expectation is that all axes will be homed.
It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.
Best regards, ~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being.
I found the documentation confusing too, but after reading the code I think something like this would allow overriding a single axis, right? Am I missing something?
Edit: Corrected the gcode, since jinja doesn't allow list comprehensions. I tested this and it works for me.
[homing_override]
gcode:
{% set axes = params.keys() | map("list") | sum(start=[]) %}
{% set home_all = 'X' not in axes and 'Y' not in axes and 'Z' not in axes %}
{% if home_all or 'X' in axes %}
# do the x homing here
{% endif %}
{% if home_all or 'Y' in axes %}
# do the y homing here
{% endif %}
{% if home_all or 'Z' in axes %}
# do the z homing here
{% endif %}