SunRed/Marlin-Artillery-M600
Archived
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
This repository has been archived on 2022-01-28. You can view files and clone it, but cannot push or open issues or pull requests.
Marlin-Artillery-M600/Marlin/src/gcode/motion/M290.cpp

57 lines
1.8 KiB
C++
Raw Normal View History

Add M290 Babystepping
2017-10-25 22:49:34 +02:00
/**
* Marlin 3D Printer Firmware
* Copyright (C) 2016 MarlinFirmware [https://github.com/MarlinFirmware/Marlin]
*
* Based on Sprinter and grbl.
* Copyright (C) 2011 Camiel Gubbels / Erik van der Zalm
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*
*/
#include "../../inc/MarlinConfig.h"
#if ENABLED(BABYSTEPPING)
#include "../gcode.h"
#include "../../module/probe.h"
#include "../../module/temperature.h"
#include "../../module/planner.h"
/**
* M290: Babystepping
*/
void GcodeSuite::M290() {
#if ENABLED(BABYSTEP_XY)
for (uint8_t a = X_AXIS; a <= Z_AXIS; a++)
if (parser.seenval(axis_codes[a]) || (a == Z_AXIS && parser.seenval('S'))) {
Miscellaneous cleanup
2017-11-16 07:27:24 +01:00
const float offs = constrain(parser.value_axis_units((AxisEnum)a), -2, 2);
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-16 23:53:55 +01:00
thermalManager.babystep_axis((AxisEnum)a, offs * planner.axis_steps_per_mm[a]);
Add M290 Babystepping
2017-10-25 22:49:34 +02:00
#if ENABLED(BABYSTEP_ZPROBE_OFFSET)
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-16 23:53:55 +01:00
zprobe_zoffset += offs;
Add M290 Babystepping
2017-10-25 22:49:34 +02:00
#endif
}
#else
if (parser.seenval('Z') || parser.seenval('S')) {
Coding standard patch of M290
2017-11-12 05:14:21 +01:00
const float offs = constrain(parser.value_axis_units(Z_AXIS), -2, 2);
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-16 23:53:55 +01:00
thermalManager.babystep_axis(Z_AXIS, offs * planner.axis_steps_per_mm[Z_AXIS]);
Add M290 Babystepping
2017-10-25 22:49:34 +02:00
#if ENABLED(BABYSTEP_ZPROBE_OFFSET)
zprobe_zoffset += offs;
#endif
}
#endif
}
#endif // BABYSTEPPING
Reference in a new issue Copy permalink