Firmware2/Marlin/src/gcode/motion
Scott Lahteine 3bba7d60f3 No retroactive changes with M851 Z
If using babystep to adjust the Z probe offset, the axis will move and the mesh will be updated at the same time, causing a doubling of the Z offset over the rest of the print.

To correct for this, the current Z position would need to be modified in the opposite direction, canceling out the additional Z offset added to the mesh. This would be confusing to users, and moreover it would not be accurate without also taking the current Z fade level and current Z height into account.

It might make sense to change the mesh in the case where no babystepping is taking place, but this could be considered an undesirable side-effect of changing the `zprobe_zoffset`.

One way to remedy this would be to return to storing the mesh with `zprobe_zoffset` included, then subtracting `zprobe_zoffset` from the returned Z value. Thus, a babystep moving the Z axis up 1mm would subtract 1 from `zprobe_zoffset` while adding 1 to all mesh Z values.

Without including the `zprobe_zoffset` in the `z_values` there is no safe way to alter the mesh in conjunction with babystepping, although it's fine without it.
2017-11-18 03:36:39 -06:00
..
G0_G1.cpp [2.0.x] Fix NO_MOTION_BEFORE_HOMING unwanted behaviour (#8176) 2017-10-30 22:50:22 -05:00
G2_G3.cpp Misc. fixes to compiler warnings, etc. 2017-11-06 22:57:05 -06:00
G4.cpp Move G4 to cpp 2017-09-21 16:26:49 -05:00
G5.cpp change to better (more clear) names (#8050) 2017-10-21 11:42:26 -05:00
M290.cpp No retroactive changes with M851 Z 2017-11-18 03:36:39 -06:00