Zero reference positon overide broken with Klipper update

General Discussion
1

Basic Information:

Printer Model: Custom Built
MCU / Printerboard: Manta M5P
Host / SBC Raspbery Pi 5
klippy.log

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

The recent update to Klipper has broken the mesh zero_reference+position override. I tap the bed within my adaptive mesh but outside the print. I then zero the mesh to this saved position. This does not work anymore. I can replace the dynamic values with x,y coordinates, but it does not work. It will only zero the mesh to the static values in the mesh configuration section. Please help resolve this issue.

gcode_macro TAP_MESH

gcode:
{% set x = (printer[“gcode_macro TAP_POINT”].tap_x | float) | round(1) %}
{% set y = (printer[“gcode_macro TAP_POINT”].tap_y | float) | round(1) %}
RESPOND MSG=“BED MESH ANCHORED AT TAP ({x},{y})”
BED_MESH_CALIBRATE ZERO_REFERENCE_POSITION={x},{y} METHOD=rapid_scan ADAPTIVE=1 ADAPTIVE_MARGIN=15

klippy (4).zip (1.3 MB)

2

Hello @flynut and welcome to the forum!

You may try a pristine version of Klipper.

...
Git version: 'v0.13.0-608-gf3db41c6-dirty'
Untracked files: klippy/extras/autotune_tmc.py, klippy/extras/gcode_shell_command.py, klippy/extras/motor_constants.py
...

See: The "dirty" Flag and the Team's Position

The CB2 runs a different version of Klipper.

...
Loaded MCU 'CB2' 119 commands (v0.12.0-249-ga19d64fe / gcc: (Debian 10.2.1-6) 10.2.1 20210110 binutils: (GNU Binutils for Debian) 2.35.2)
...

BTW: Please, when posting code, use the Preformatted text feature of the forum editor.
Format

3

Thank you for the welcome and reply.

I am currently running v0.13.0-610-g35ace529 and it is clean according to the Klipper interface. That must be in the logs from before I updated Klipper.

4

Please try and run the troublesome macro then grab the current klippy.log and upload it.

5

Alas, I’m not sure what you are doing or where you got such sophisticated macros.

I strongly suggest that you update further, because there are sanity checks for the untap logic.

I can guess that your macro is broken because of high LIFT_SPEED:

PROBE METHOD=tap PROBE_SPEED=5 LIFT_SPEED=15 SAMPLES=3 SAMPLES_RESULT=median SAMPLES_TOLERANCE=0.015 SAMPLES_TOLERANCE_RETRIES=5

I’m not sure that untap logic will happen to have enough samples, so I suggest you to reset it to the default 5 at least.

Otherwise, I doubt there is ZERO_REFERENCE_POSITION available in the code: Code search results · GitHub

There is some code to allow overriding bed mesh parameters, but I’m not sure it allows overriding everything, and alas, I did not extensively use it.

Hope that helps,
-Timofey

6

FWIW, Bed Mesh does not support a dynamic zero_refererence_position and never has. When the relative_reference_index was an option it could be changed dynamically, however this was an error which was corrected several years ago when it was deprecated in favor of the zero_reference_position.

The zero_reference_position is determined when you calibrate the endstop_position for the z endstop. Its the position on the bed used to perform the calibration (this position will be Z=0 after homing). This is a value that should not change unless you recalibrate, which is why it isn’t possible to set it dynamically via gcode. If you are homing with a probe then you shouldn’t set a zero reference position, as its necessary that the probe’s z_offset be accurate and that value will be used to zero the mesh.

1 Like