why_does_the_z_offset_drift_or_vary
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| why_does_the_z_offset_drift_or_vary [2026/08/16 20:18] – dshoop | why_does_the_z_offset_drift_or_vary [2026/08/18 13:16] (current) – dshoop | ||
|---|---|---|---|
| Line 37: | Line 37: | ||
| ==== Maybe you like this answer better? ==== | ==== Maybe you like this answer better? ==== | ||
| - | It’s not a bug nor is it dropping the “z leveling”, | + | 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. | 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. | ||
/app/data/pages/why_does_the_z_offset_drift_or_vary.txt · Last modified: by dshoop
