Support retrying Z_TILT_ADJUST a configurable number of times
to a configurable tolerance both in the config or as parameters.
- By default keeps original behavior of no retries.
- Adds parameters RETRIES and RETRY_TOLERANCE to QUAD_GANTRY_LEVEL gcode.
- adds config options retries and retry_tolerance to uad_gantry_level]
- issues an error if we are getting worse intead of approaching tolerance
- issues an error if retries were requested but we did not reach the tolerance
in the specified number of retries
the minimum change should be a single z step for those
probing 2 points for 2 stepper motors and 3 for 3 stepper motors.
at one point it was suggested to use the amount of z adjustment instead of the
range of the probed points as a trigger for retry. I've chosen not to do this.
using z adustment in these cases means the minimum unit of change is related to
the angle created by the probed points and the distance to stepper motor and
can be more than a couple steps which is rather unintuitive.
for the case when someone is using more probed points than z steppers the
probed points range will have some fixed minimum value that can't be reduced
which is also unintuitive but that case should idealy be the rarer case, and
the user can learn to set a higher tolerance that matches their probing setup.
Signed-off-by: John "Fess" Fessenden <fess@fess.org>
"The z_tilt_adjust was coded to require 3 points because the original
intent was for railcore-xl and voron. Since then, a number of users
have started using z_tilt_adjust for prusa i3 style printers with dual z
steppers. That's fine, but we just haven't gotten around to removing
the superfluous check in the code." -- Kevin O'Connor
remove that check.
Signed-off-by: John "Fess" Fessenden <fess@fess.org>
Factor out minimum required points check for ProbePointsHelper
in prep for setting different values for quad_gantry_level
and z_tilt_adjust
Signed-off-by: John "Fess" Fessenden <fess@fess.org>
The z_adjust offset provided to adjust_steppers is calculated given the
steppers adjust exactly according to the given x_adjust/y_adjust. As the
algorithm eliminates an offset that is common to all steppers, this offset
must be taken into account in the final correction.
Signed-off-by: Arne Jansen <arne@die-jansens.de>
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Convert all users of the printer_state("connect") handler to register
a "klippy:connect" event handler instead.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Don't require the config file to specify manual probing. Instead,
allow the user to select manual probing on each ProbePointsHelper
invocation.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that all users of ProbePointsHelper use the same
get_probed_position() code, it is possible to implement that locally
within the ProbePointsHelper class.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
It's rare to have all the Z stepper locations directly under the
printable surface, so using z_positions for points is not a good
default.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The different uses of get_position() can be confusing, so choose a
different name for the ProbePointsHelper callback.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Calculating the cartesian position from the stepper positions can be
complex and cpu intensive, so rename it to calc_position() to be more
descriptive.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Update the code to use the term "rail" when dealing with a motor
controlled "axis". A rail has a series of steppers and endstops that
control that motor controlled "axis".
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add additional wrapper functions so that no outside callers need to
peak into the member variables of PrinterStepper.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Petri Honkala