Owners that believe their gcode z offset is “lost”, drifts or varies from what it “should be” often find the following also true:
- Their z probe is not calibrated. A telltale sign of an uncalibrated z probe is a gcode z offset setting that's a negative number as those are non-sensical when the probe is calibrated properly. See probe_calibration.
- They have z stepper interpolation enabled on their z stepper motors, and should also examine their stealthchop vs spreadcycle configurations. Read the Klipper docs regarding proper tuning of this as well as improving microsteps.
- They have not 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.
Checking POSITION will reveal the actual stepper position, as well as its perceived positions.
Older Marlin firmware style workflows, including Elegoo's QuickStart and the separate and ancillary side Screen, often rely on a method for compensating for errors in the printer's self-perceived z axis height by adjusting the gcode z offset value, a parameter that is designed to provide very fine adjustment of the toolhead position above the plate to accommodate the proper filament squish, a whole distinct topic and purpose. In these workflows the gcode z offset value is overload to accommodate two purposes, its intended purpose and to compensate for error between where the z height endstop triggers and when the nozzle is actually touching the plate then Z=0.00mm.
This is not an appropriate way to operate in a Klipper based environment. Instead we should be calibrating the Z probe so that it properly report its end stop position such that the nozzle is 0.00mm above the plate when it triggers. This is done by calibrating the z probe.
The gcode z offset then has the intended Klipper purpose of fine adjusting the squish on the filament so that the extrusions aren't just tangentially binding to the layer/plate beneath and adjacent permitters and infill. It's nominally zero, or maybe within 80 or so microns, often is inconsequential. When adjusted from zero it's to adjust for variations of material and for the specific filament we're using, so it being saved isn't any more rational than saving filament extruder temperature or max volumetric flow rate.
Unfortunately Elegoo, in its software updates, has purposefully and intentionally broken the Klipper automated z probe_calibration] method, requiring a manual editing step of the final value to printer, cfg.
When the probe is calibrated and the gcode z offset set by observation for the correct filament squish, and when the z steppers are configured to be accurate, and when the probe tolerances have been made more accurate its very rare to see the z end stop drift much, which is the effective complaint owners have when they say the z offset seems to change.
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.
The value for the gcode z offset that fine adjusts layer height to properly shape the filament cross section is not saved in printer.cfg. The Elegoo ancillary screen has workflows that attempt to save it to a file yet this is not a standard Klipper practice and results in indeterministic results.
Well, it doesn't, yet things that it's based off of do.
The default probe tolerance for its readings using either the klipper or elegoo defaults allows for inaccuracies of 100 microns, which while often a variation of 30 microns is enough to throw off the filament squish. tuning_the_z_probe_configuration and improve this issue and is a best practice.
The z steppers using Elegoo's defaults allow for interpolation and introduce inaccuracies in the movement of the Z axis causing drift. This can be remedied by tuning_the_z_steppers.