Z offset is different every time in back to back meshes. first layer wrong every time

[tastyratz]

This has been plaguing me for a while but I think I made some progress here in identifying the macro tie to my root cause.
https://discord.com/channels/460117602945990666/969563854071799818/1179114475891216424

This is on a trident. I'm talking about preheating the bed and printer for hours, home, z tilt, g28 z, bed mesh - then back to back ztilt, g28 z bedmesh. I'm doing virtual endstop with klickyPCB. This was an issue before when I had a regular endstop.

I did this, in a row, 4 times. You can especially see the difference between default and default_2.

Generally, the shape seems the same but the probed height changes. I see this in first layer inconsistency across prints.
Probe accuracy seems great to me.
probe accuracy results: maximum 1.721875, minimum 1.718750, range 0.003125, average 1.720000, median 1.720000, standard deviation 0.000968

The 0,0 position should always be z=0mm, yeah?
Because for me, it never is using the bed mesh with the macro.

[bed_mesh]
speed: 300
horizontal_move_z: 4
mesh_min: 20,29
mesh_max: 280,279
probe_count: 7,7
fade_start: .5
fade_end: 10
split_delta_z: .025
move_check_distance: 3.0
mesh_pps: 0,0
algorithm: bicubic
#relative_reference_index: 24
zero_reference_position: 149.99, 153.98
bicubic_tension: 0.1

I tried moving back to relative reference index, no improvement.
I changed probes, soaked them in alcohol, babystepped my print till it was perfect then saved it multiple times, checked my motors/steppers but realized it's not those if the entire bed mesh keeps the same shape and only varies in height.

The dead giveaway though has been someone suggesting I just straight run
_KM_BED_MESH_CALIBRATE_BASE

and when I do that? repeatable bed mesh zero reference position every time back to back.

The strange part is that the offset is not predictably off. If I run it over and over it is different every time and I don't understand why.
I've seen multiple people with similar issues but not so much fixes found.

I've got a git with my full config backup just note there are orphaned configs there not in use (like Kamp) https://github.com/tastyratz/VoronTrident/tree/master

[jschuh]

The bed mesh macro simply adjusts the layout of the XY probing matrix before passing it on to BED_MESH_CALIBRATE. So, it can't be the cause of the problem you're seeing, because it simply has no way to alter the Z position of the probes. However, I wonder if there may be an issue elsewhere.

Currently the _PRINT_START_PHASE_PROBING macro runs a G28 Z to rehome the Z axis before running the Z_TILT_ADJUST or QUAD_GANTRY_LEVEL. But in retrospect, it seems that anything adjusting the gantry or bed angles could also move the point on the bed used to establish the Z axis home position. That would mean a rehoming is needed after any such adjustments, and before the BED_MESH_CALIBRATE is run. This could also explain why what you're seeing appears random; because it would be based entirely on whatever random physical shift occurs in the lead screws when the steppers shut off between prints.

As a bit of validation, I see that the stock PRINT_START macros for both the Voron Trident and Voron 2 place a G28 immediately before and after the Z_TILT_ADJUST and QUAD_GANTRY_LEVEL (respectively). That certainly gives the impression a full rehoming is needed.

Unfortunately, I can't test this because I've never had a printer that uses z_tilt or quad_gantry_level. I added that support at someone else's request and accepted their suggestion on the ordering of commands. You could, however, test it yourself by just adding a G28 line immediately before these lines:

klipper-macros/start_end.cfg

Lines 204 to 208 in 01c0d8a

	{% if start_level_bed_at_temp %}
	_KM_PRINT_STATUS ACTION=CHANGE STATUS=meshing RESET_STACK=1
	_km_mesh_if_needed {% if MESH_MIN %} MESH_MIN={MESH_MIN}{% endif
	%}{% if MESH_MAX %} MESH_MAX={MESH_MAX}{% endif %}
	{% endif %}

That would force a rehome to run after Z_TILT_ADJUST and QUAD_GANTRY_LEVEL, but before BED_MESH_CALIBRATE. If that solves the problem I'll update the macros with something that accounts for the need to fully rehome after a the gantry or bed position is adjusted.

[tastyratz]

Well, 2 things:

1.
In this test scenario, I'm not yet at the point of printing a part but running the commands directly from mainsail.
It's manually initiated:

G28
Z_TILT_ADJUST (which performs a g28 immediately after)
BED_MESH_CALIBRATE 
Z_TILT_ADJUST 
BED_MESH_CALIBRATE 
Z_TILT_ADJUST 
BED_MESH_CALIBRATE 

Wouldn't in this scenario the steppers not shut off back to back without an additional full g28? and in that instance the only G28 of z is after ztilt and before a bed mesh.

If that is the case then
2.
Why is the 0 point of the bed mesh not always 0 and what is shifting that around by these arbitrary amounts? Shouldn't that always be the zero reference point of a bed mesh? It is when I bypass the macro. I think this offset is what's taking me down.

[jschuh]

As I explained:

The bed mesh macro simply adjusts the layout of the XY probing matrix before passing it on to BED_MESH_CALIBRATE.

You can look at BED_MESH_CALIBRATE_FAST and even read through Klipper's native implementation of BED_MESH_CALIBRATE to verify. You'll find there's simply no way to alter the Z offsets in the manner you're claiming. It's just not how Klipper works.

As for the variance you're seeing in comparing the Z offsets of the zero reference points from the two meshes: it's a red herring. Your bed mesh config has your center probe point set to roughly the same coordinates as your zero reference point. However, BED_MESH_CALIBRATE_FAST changes the mesh grid layout such that the zero reference point is almost certainly not as close to a point on the sampled grid (although in this case, it's within the mesh). So, Klipper interpolates the Z offset of the zero reference point as it does with any other point not on the grid. So there's no difference in the accuracy of the meshes, but the farther an interpolated point is from a sampled point, the more it will amplify the effect of any sampling variance inherent in the physical system. That's just how a bed mesh works, and why increasing the sampling density increases the accuracy of the mesh.

That stated, it looks like you're seeing a variance of at most +/- 10 microns between runs. If that's the maximum variance across the full mesh, then it should be accurate enough for FDM/FFF printing. (If the variance is significantly worse, you may want to consider increasing your mesh density).

And independent of all of the above, I read up a bit more on z_tilt and quad_gantry_level and am now convinced that I have a bug I need to fix in _PRINT_START_PHASE_PROBING. It should explicitly do a full probe after either of those commands.

[jschuh]

Leaving a note here that I made the change to perform a full rehome after z-tilt or QGL in 14840a4.

[tastyratz]

I've been testing your new code. Unfortunately, it's breaking for klicky. I did confirm that it was in fact this change that did it by rolling forward and back. Right before the purge line I get Probe triggered prior to movement because it's completely skipping the dock routine and cancelling the print.

I'm not entirely sure why?

This is the relevent piece of my start code, FWIW

_PRINT_START_PHASE_PREHEAT
; Insert custom gcode here.
ATTACH_PROBE_LOCK

_PRINT_START_PHASE_PROBING
; Insert custom gcode here.
DOCK_PROBE_UNLOCK

_PRINT_START_PHASE_EXTRUDER