Differences

This shows you the differences between two versions of the page.

--- why_does_the_z_offset_drift_or_vary [2026/06/15 20:55] – dshoop
+++ why_does_the_z_offset_drift_or_vary [2026/08/18 13:16] (current) – dshoop
@@ Line 13: / Line 13: @@
 - They have not [[tune_probe_configurations|configured the z probe tolerances]] and they are at the egregiously overly tolerant Klipper or Elegoo defaults.
+- A saved or reused bed mesh was loaded and used to print resulting in an invalid compensation matrix being applied as bed meshes are never similar between prints and immediately stale. They're invalid any time the plate is moved, the print removed or the plate touched, or if it's been heated and reheated. Owners should be using a bed mesh run at print time, preferably Orca's Direct Adaptive Bed Mesh Compensation.
 All of the above permit conditions inviting z probe height readings that vary between G28s and homing of the z axis virtual end stop.
@@ Line 33: / Line 35: @@
 The z probe calibration should only need to be performed again if the plate is changed, or the nozzle, hot end or tool head are changed.
+==== Maybe you like this answer better? ====
+It’s not a bug nor is it dropping the gcode z offset. It’s because unless you calibrate your z probe your offset will be negative because your overloading it with an error adjustment for the probe not being calibrated and that error adjustment will change when the probe’s not calibrated and the steppers not properly tuned. These are simple fixes that don’t require OpenNeptune. The gcode z offset has never been something Klipper has intended to be stored, it’s a filament calibration value nor a printer setup setting.
+The other issue is when using the silly side screen that’s not part of the printer it doesn’t send absolute z offset Klipper commands, if sends relative commands and as it’s not part of the printer has a very poor idea of what any current values actually are.
 ===== Older Answer:=====