Axis_twist_compensation: compensation applied at wrong coordinates due to probe offset

[RamonSaboya]

Basic Information:

Printer Model: Voron 2.4 R2
MCU / Printerboard: Manta M8P V2.0
Host / SBC: CM4
klippy (10).log (76.8 KB)

klippy.log

Describe your issue:

I found a bug in axis_twist_compensation where Y-axis compensation is applied at the wrong bed coordinates when the probe has a non-zero y_offset. The same bug also affects X compensation for probes with x_offset != 0.

The Bug

In _update_z_compensation_value, the compensation lookup uses pos.test_x and pos.test_y (probe coordinates). However, compensation_start_x/y and compensation_end_x/y are stored in nozzle coordinates during calibration. This means the lookup is shifted by the probe offset amount, and compensation gets applied at the wrong physical location.

How I Found It

I took bed meshes with and without Y twist compensation enabled and compared them. The X compensation diff clearly matched the stored z_compensations pattern. But the Y compensation diff did not match zy_compensations at all — it was shifted by my probe’s y_offset (22.9mm).

Who It Affects

Any probe with y_offset != 0 using Y-axis twist compensation: Beacon, Cartographer, offset BLTouch, etc. X compensation is similarly affected for probes with x_offset != 0, though many common probes have x_offset=0.

This was independently reported by @Murdo in topic #21633 with a Cartographer probe (y_offset ~23.7mm), though that thread was closed without a fix.

The Fix

Change pos.test_x to pos.bed_x and pos.test_y to pos.bed_y in _update_z_compensation_value. This makes the lookup use nozzle coordinates, matching the coordinate space of the stored boundaries. Two-line change.

I’ve submitted a PR: https:/ /github.com/Klipper3d/klipper/pull/7246 (Can’t add links as it’s a new account)

[mdewayne7]

Hi RamonSaboya, and welcome. I see that the topic you linked only had Murdo responding to himself, and I would be surprised if you get much of a response as well.

Primarily because The "dirty" Flag and the Team's Position

The Klipper bros don’t have time for anything that isn’t ‘theirs’ and pretty much disregard or dismiss anybody seeking help with the dirty flag.

It’s disappointing, because obviously there are talented people with the skill and desire to implement and incorporate many of these extras so they wouldn’t be quarantined.

But there is obviously a disconnect somewhere…

Hence Kalico…

Additional reading here…

Possible Klipper "plugins" instead of macros?

The current Klipper macro system has shown impressive results. Impressive, both in a “terrific” way and in a “terrible” way. Terrific in that I’ve seen macros used to implement very impressive functionality that can directly improve user printing experience, and terrible in that some macros have grown to a level of complexity that makes them very hard to troubleshoot. One of the weaknesses of Klipper macros is that they rely on Jinja2 and G-Code - both of which are very “quirky”. They both a…

New submission process for feature enhancements

I believe that this is a commendable strategy. However, I’d like to offer some additional thoughts from my support perspective: Handling Macro Utilization My interpretation is that a primary objective in the design is to ensure that the intricacy of features and settings remain manageable. Regrettably, the current frequent usage of macros by users to circumvent absent features or enhance flexibility seems to contradict this goal. To illustrate, many of the klippy.logs we encounter (even from no…

[3dcoded]

Hi @RamonSaboya ,

According to your log, you’re using custom code for the beacon probe AND custom beacon axis twist compensation code. If the behavior can be reproduced on plain Klipper (maybe you can configure the beacon as an eddy current probe), then we can deduce the error is in Klipper. If the error goes away, the issue is in the beacon custom axis twist compensation code.