Some XY moves at the extreme end of the build envelope could cause
excessive axis stepper movement. Check for any moves that could
possibly result in a stepper movement of more than 3 times the XY
movement and cap the move's acceleration and speed.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Calculate and store the maximum xy2 value for the given z level each
time the head moves to a new z level. This simplifies the boundary
check for common XY moves.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Instead of requiring the user enter velocity and accel parameters for
extrude only moves, calculate sane defaults from the printer's maximum
velocity and accel.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add a is_kinematic_move flag to the Move class and clear it on extrude
only moves. Don't call the kinematic check_move() or move() methods
for extrude only moves.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Taking the inverse of the XY move distance can lead to extremely large
values when the XY distance is very small. This can lead to
saturation of the double precision variables and incorrect results.
Rework the delta kinematic math to avoid using this inverse. Pass the
closestxy_d value directly to the C functions so that the C code can
calculate its intermediate constants.
After this change the move_z special case is no longer necessary as
the regular delta functions now work with movexy_r=0 and movez_r=1.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The head may be far away from an axis at the start of a home, and that
axis must then traverse more than just the distance from zero height
to the endstop position. Add in additional distance to account for
this.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
On a delta printer, z moves require the mcu to support the greatest
number of steps per second. However, z moves are rare, so it makes
sense to limit the velocity of z moves separately from the velocity of
normal xy moves.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Change the config file so the maximum accel and velocity are specified
in the "printer" section instead of the individual "stepper" sections.
The underlying code limits the velocity and accel of the toolhead
relative to the print object, so it makes sense to configure the
system that was as well.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Commit 1e1364c3 moved the storage of the stepper position to the
mcu_stepper class. The initializing of that position needs to be
pushed back until after the mcu_stepper class is instantiated.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Instead of checking the endstop trigger directly after a retract move,
verify some distance is traveled during the following homing
operation. This reduces the amount of synchronization between mcu and
host during homing.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Move the storage of the stepper location from the kinematic classes to
the low-level mcu_stepper class.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Allow an EndstopError to be raised without a destination position.
Introduce EndstopMoveError wrapper so that current callers can
continue to pass in a move destination.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Change the scheduling of the final homed position (which takes into
account the stepper phases) so that it is scheduled from the kinematic
classes instead of from the toolhead class.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Create the Homing class in the gcode handler instead of in the
kinematic classes. This will make it easier to pass error messages
back to the user.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Create the QueryEndstops in the gcode handler instead of in the
kinematic classes. This simplifies the gcode handler as it can
directly register its response callback.
Also, store the stepper name in the stepper class. Also, propagate
the print_time of the query request to the mcu_endstop class.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Kevin O'Connor