Closed Ibot-11 closed 1 year ago
What was your goal with making changes to the script?
I haven't done Tap yet (parts are on the way) but it shouldn't be any different than other probes. Please check that you met the requirements: https://klipper.discourse.group/t/build-sheet-manager-adjust-live-z/4013 Especially the last one, you need to Z-home and reset the Z-offset on every print.
With Tap you don’t have a variable offset that changes anymore, because there is no AutoZ. It would be much better to use a fixed offset you load from the variables.cfg. This way you can’t stack multiple APPLY_BUILD_SHEET_ADJUSTMENT. I’ll also would use the OFFSET_LOAD in my delayed gcode to already load it at startup. Of course you have also to add this to the different sheet presets. Simply said it's just a synchronization of the gcode offset and the saved variables.cfg offset.
You also don’t have to reset the offset before every print/home. When Klipper does the homing sequence or bed mesh it takes that into account. I already have done this dozens of times without any issues
Normally you don’t really need this with tap anymore. But I still have a bit different offset when soaked (ABS) and unsoaked (PLA). I also like to squish my ABS a bit more.
My plan is to set the probe offset once with PROBE_CALIBRATE at ambient temperature and on a plank steel sheet once. The tuning for all other plates is then done on top of that refrence with the sheet manager. An alternative would be to set the absolute probe offset. But i don’t think you can change this that easily “on the fly”
If you want consistent first layers on every print, you should home Z and bed mesh for every print. The only thing that the build sheet system is storing is the extra amount of "squish" you want for a given build surface. But do as you want.
To use the script, just do this in print start:
SET_GCODE_OFFSET: Z:{my_offset_here}
APPLY_BUILD_SHEET_ADJUSTMENT
You can set it to whatever number your come up with from PROBE_CALIBRATE
.
When I get my Tap setup running I can share what I came up with. I wont be using PROBE_CALIBRATE
. My plan is to clear the offset, home Z, lift the nozzle 0.5mm off the bed and set that as Z=0 with G92. That's a safe height to start offset tuning from.
I’m still not 100% sure if you understand what my plan is. I already use this: SET_GCODE_OFFSET Z=0 APPLY_BUILD_SHEET_ADJUSTMENT
and don’t get me wrong. It works. But I think there is simply a better solution now because you don’t have the AutoZ offset anymore. For me it doesn't make any sense to set it first to 0 to then add the offset. Why not directly set it to the offset value?
I used printer.gcode_move.homing_origin.z to directly get the current set offset mainsail also shows in the gcode offset menu. This way I want to ensure both are always the same. When you currently use SET_GCODE_OFFSET Z=0 for example the current macro just ignores that. It already kind of works. My only issue is that it saves the variables to the variable.cfg before the new offset change is applied. Thats why its alway one step behind.
I know you should do heatsoak, quad gantry level, home z, bed mesh etc. every print. But the heated chamber still affects the offset a bit. Even with tap.
APPLY_BUILD_SHEET_ADJUSTMENT
does an ADJUST_Z=
instead of Z=
so you can use it with either a probe like Tap or one like Euclid/Clicky that requires a an offset be measured for each print with something like CALIBRATE_Z
. If I did an absolute Z=
then users with a probe measuring process wouldn't have a way to measure and set an offset independent of the sheet squish.
GCODE_OFFSET
contains 2 values summed together: the squish for the build sheet and the nozzle offset. So something like 0.12 + 1.5. Once they get added together you can separate them. Tracking ADJUST_Z
is how I'm keeping track of the sheet squish separate from the nozzle adjustment. If you "simplify" the script you will break it for everyone that doesn't want to use it with a nozzle offset of 0. You can do that if you like, go ahead and explore/play around and learn how Klipper works, don't let me stop you. I just wont pull that as a PR.
I'm probably going to set some fixed nozzle offset with Tap. There is going to be some hysteresis the cancel and I want to add some safety margin so the nozzle doesn't crash on a new build plate (say 0.5mm). This is what Prusa does, on a new plate the nozzle is always too high for safety. So even with tap there is a reason to have some fixed nozzle offset.
I think I have an idea about your "one step behind" comment. Read this section: http://www.klipper3d.org/Command_Templates.html#the-printer-variable Particularly: "Important! Macros are first evaluated in entirety and only then are the resulting commands executed. If a macro issues a command that alters the state of the printer, the results of that state change will not be visible during the evaluation of the macro." You cant read back the results of the applied Z offset from the printer variable in the same macro where they are applied.
Of course the macro then no longer works with AutoZ! But it's also not my intention to support that. But I still think this is a more elegant way to use/set the value for users that don’t use AutoZ. You’ll always see your variable value as the current applied gcode offset.
Please don’t get me wrong. I don’t want to force you to use this method instead. It's just the way I would like it to be. Thank you for your tip! I’ll try this when my printer finishes printing!
Thank you for your tip! It finally works exactly how I wanted it.
What I came up with:
[gcode_macro SET_GCODE_OFFSET]
rename_existing: _SET_GCODE_OFFSET
gcode:
_SET_GCODE_OFFSET {% for p in params %}{'%s=%s '% (p, params[p])}{% endfor %}
SAVE_GCODE_OFFSET
[gcode_macro SAVE_GCODE_OFFSET]
description: Save current offset as variable
gcode:
{% set svv = printer.save_variables.variables %}
{% set sheet_key = (svv["build_sheet installed"] | string) %}
{% set sheet = (svv[sheet_key] | default(None)) %}
{% if sheet is defined %}
{% set _ = sheet.__setitem__("offset", (printer.gcode_move.homing_origin.z | float)) %}
SAVE_VARIABLE VARIABLE="{sheet_key}" VALUE="{sheet | pprint}"
SHOW_BUILD_SHEET
{% else %}
{action_respond_info("Sheet not defined")}
{% endif %}
[gcode_macro LOAD_OFFSET]
description: Loads the sheet offset for the installed build sheet
gcode:
# get the offset from saved variables
{% set svv = printer.save_variables.variables %}
{% set sheet_key = (svv["build_sheet installed"] | string) %}
{% set sheet = (svv[sheet_key] | default(None)) %}
{% if sheet %}
# log this to the console so if there is an issue with the print the user can see which sheet the printer thought it had installed
{action_respond_info("Applying offset: %.3fmm for build sheet: %s" % (sheet.offset, sheet.name))}
_SET_GCODE_OFFSET Z={sheet.offset}
{% else %}
{action_respond_info("No build sheet installed, offset adjustment: 0.000mm") }
{% endif %}
[gcode_macro INSTALL_BUILD_SHEET]
description: Install a build sheet and save settings
variable_parameter_NAME: "Unknown Build Sheet"
variable_parameter_OFFSET: 0.0
gcode:
{% set svv = printer.save_variables.variables %}
{% set sheet_name = (params.NAME | default("Unknown Build Sheet") | string) %}
{% set sheet_offset = (params.OFFSET | default(0.0) | float) %}
{% set sheet_key = ("build_sheet " ~ (sheet_name | lower | replace(" ", "_"))) %}
{% set sheet = (svv[sheet_key] | default(None)) %}
{% if not sheet %}
# the sheet does not exist, create it
{% set sheet = {"name": sheet_name, "offset": sheet_offset} %}
SAVE_VARIABLE VARIABLE="{sheet_key}" VALUE="{sheet | pprint}"
{% endif %}
SAVE_VARIABLE VARIABLE="build_sheet installed" VALUE="'{sheet_key}'"
**LOAD_OFFSET**
SHOW_BUILD_SHEET
Also added LOAD_OFFSET to my delayed gcode on startup. This way my offset is always synchronized with the saved variable value.
I'm currently editing the sheet manager for my voron tap. I changed it to get the offset value from printer.gcode_move.homing_origin.z and save it to the variables.cfg. But I still have one weird behavior I can’t fix. I think it's because of the upper part of the macro I don’t really understand. The variable saves always one step behind.
The LOAD_OFFSET macro works fine. Would be nice if you could help me with this. I’m still a "macro rookie"
Thanks!