protoloft / klipper_z_calibration

Klipper plugin for self-calibrating z-offset
GNU General Public License v3.0
1.05k stars 151 forks source link

z_tilt_adjust #35

Closed jp8311 closed 2 years ago

jp8311 commented 2 years ago

I'm pretty new to macros, I had some working fine for magprobe that I lifted from someone's config and edited for mine - but I'm pretty sure it's causing the z height to be redefined somewhere and I can't seem to find it.

On my first nozzle probe during my start print routine I get the expected value of my position_endstop = -2.504 After z_tilt adjust, moving through to calibrate_z it seems to change to reading values of -7.xxxx, which is subsequently wildly out of the expected tolerance and errors out. Performing calibrate_z without the other macros behaves as expected.

I'm trying to swap to your macros, but they are obviously set up for QGL. I am happy to have a tinker and see if I can get it working, but for the sake of sanity - is there any other "gotchya" code I need to look at than just swapping out QUAD_GANTRY_LEVEL references for "z_tilt_adjust" & rewriting/editing the QGL macro to perform z_tilt_adjust?

I'm slowly getting my head around it but there's plenty of things I don't know the benefit of or effects of that I'm taking at face value. Thought I'd post before I go to work so I can be well equipped when I come home to tackle it!

Neat program, love the idea.

TitusLabs commented 2 years ago

This is strange. The QGL or Z-Tilt should behave the same. So yes, just exchange the QGL routine with the one of the Z-Tilt. It can also be a good thing to home Z again after QGL/Z-Tilt...

jp8311 commented 2 years ago

Yep, I just needed a G28 Z after Z_Tilt in the macro series to fix the issue.

I also didn't quite have enough buffer set to avoid hitting the switch on the probe, so if it attached slightly to the side it was hitting the trigger on the bedprobe and getting inconsistent results. Must have retested that 50 times before I actually managed to observe it happening, always seemed to happen when I was watching something else.

I was going to do a PR but honestly ctrl+f & replace "QUAD_GANTRY_LEVEL" with "Z_TILT_ADJUST" & add the 'G28 Z' after Z_Tilt sorts it out.

For those googling my issues:

[gcode_macro Z_TILT_ADJUST]
description: Level a flying bed to a stationary gantry
rename_existing: BASE_Z_TILT_ADJUST
gcode:
  #####  get user defines  #####
  {% set park_pos = printer['gcode_macro _USER_VARIABLE'].park_bed %}
  {% set z_hop = printer['gcode_macro _USER_VARIABLE'].z_hop|float %}
  ##### get toolhead position #####
  {% set act_z = printer.toolhead.position.z|float %}
  #####  set default  #####
  {% set park = params.PARK|default('true') %}
  #####  end of definitions  #####
  # home all axes if not already
  {% if "xyz" not in printer.toolhead.homed_axes %}
    _CG28
  {% endif %}
  SAVE_GCODE_STATE NAME=STATE_Z_TILT_ADJUST
  _SET_ACC VAL=HOME
  _CG28 RESET_SETTINGS=false
  {% if act_z < z_hop %}
    G1 Z{z_hop} F900 ; move head up to ensure Probe is not triggered in error case
  {% endif %}
  ATTACH_PROBE 
  BASE_Z_TILT_ADJUST
  G28 Z
  {% if params.CALIBRATE|default('false') == 'true' %}
    CALIBRATE_Z RESET_SETTINGS=false
  {% else %}
    DETACH_PROBE
  {% endif %}
  {% if params.RESET_SETTINGS|default('true') == 'true' %}
    _SET_ACC
  {% endif %}
  {% if park|lower == 'true' %}
    G90
    G0 Z{park_pos[2]} F1800           ; move nozzle to z high first
    G0 X{park_pos[0]} Y{park_pos[1]} F18000 ; home to get toolhead in the middle
  {% endif %}
  RESTORE_GCODE_STATE NAME=STATE_Z_TILT_ADJUST
TitusLabs commented 2 years ago

Nice to hear that it works for you!

A second homing is not necessary. The auto calibration is able to compensate this. But, it can be a good advice to do so if the adjustments by the Z-Tilt/QGL are too high. And my probe is mounted to the bed. So, a correct Z is need to fetch it.

Thanks! I will add your macro to the example configuration...

TitusLabs commented 2 years ago

I added the macro to the examples.