Calculate the ratio of axis distance to total move distance (axis_d /
move_d) and store in a new member variable axes_r. This avoids
needing to recalculate the value in other code.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Only track a single acceleration movement in a 'struct move' instance.
Break the classic trapezoid movement (accel, cruise, decel) into three
separate movements. This simplifies the calculation logic.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Load all items from the look-ahead queue into the trapezoid velocity
queue, and then flush that queue by time. This prevents the host cpu
from being starved on very long moves (which may require a large
number of steps to be generated). It also improves the overall
performance.
With the batch flushing logic in place, it is no longer necessary to
split homing moves up.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that all callers use the trapq system to queue moves, it is no
longer necessary to individually allocate and fill a 'struct move'.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that all kinematics use the trapq system, there is no need to call
into the kinematics on each g-code move.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add support for building a list of moves in the trapq.c code. Update
the toolhead code so that moves generated from the look-ahead code are
added to that list.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
When reducing the maximum speed due to the max_accel_to_decel setting,
move velocity limits must still be propagated. Otherwise, the
trapezoid move planner may produce moves with velocity jumps.
Signed-off-by: Dmitry Butyugin <dmbutyugin@google.com>
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
During a "drip feed" move, both the move's maximum speed and maximum
acceleration may be limited by the kinematics.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
It's not necessary to fully build up the look-ahead queue prior to
starting a "drip move" homing operation. Instead, allow the
look-ahead queue to flush normally.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
If the homing move is exceptionally long, it could take a long time
for the host to process the look-ahead queue. Delay the print_time
calculation until moves are ready to be sent.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that homing is implemented via "drip moves", it is no longer
necessary to move the print_time backwards.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Rework the low-level implementation of homing movement. The existing
mechanism buffers all homing movement into the micro-controller prior
to starting the home. Replace with a system that buffers all movement
into the host look-ahead buffer and then "drip feed" those moves to
the micro-controllers. Then clear the host look-ahead buffer when all
endstops trigger.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
If commands are slowly fed to the printer it could cause the number of
queued commands to grow without bound. Be sure to pause the incoming
command stream even if the lookahead queue is empty.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add "gcode_position" named tuple to gcode.get_status(). Add a
"position" named tuple to toolhead.get_status().
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Instead of directly turning off motors, heaters, and fans from
gcode.py, raise a new event and allow the heater, fan, and toolhead to
handle the event as needed.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Convert all users of the printer_state("shutdown") handler to register
a "klippy:shutdown" event handler instead.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Limit speed and acceleration of extrude only moves to just the
max_extrude_only_velocity and max_extrude_only_accel config settings.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
If a requested value is higher than the configured maximum, then just
limit the value to the configured maximum instead of raising an error.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Only clear the internal sync_print_time flag if the code performs a
regular "lazy" flush of the look-ahead queue. This helps build the
look-ahead queue even when running internal scripts.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The max_accel_to_decel variable must not be greater than the max_accel
variable. Make sure to check this when M204 changes max_accel.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Commit 4573932f allowed move.end_pos to differ from the requested end
position - the toolhead class should use the updated position when
storing its commanded position.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
It's possible that a g-code transform class may make an extrude only
move appear as a kinematic move due to limitations of double precision
math. Handle this by checking for an inconsequential move distance
instead of checking for a move distance of exactly zero.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Move the "motor_off_timeout" tracking to a new module in the extras/
directory. This makes it easier to customize the idle timeout
behavior.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The junction_deviation configuration parameter has a number of quirks
that make it difficult to configure. Replace it with a
"square_corner_velocity" configuration parameter.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Move extruder.py, cartesian.py, corexy.py, and delta.py to a new
kinematics/ sub-directory. This is intended to make adding new
kinematics a little easier.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Use the new gcode.register_mux_command() so that SET_PRESSURE_ADVANCE
works correctly with multiple extruders.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
If max_accel_to_decel is greater than max_accel in the config, then
just internally limit max_accel_to_decel to max_accel. This makes it
easier to completely disable the max_accel_to_decel feature (as it can
just be set to a high value in the config).
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The existing junction algorithm limits the speed between two moves by
determining the maximum speed an arc between those two moves would
have if the cetripetal acceleration of that arc did not exceed the
printer's maximum acceleration.
However, should the slicer send an actual arc to the printer, then the
existing junction algorithm would not impose any significant limit on
the travel speed of that arc. This would permit the head to travel in
a circle at high velocity and with a greater centripetal acceleration
than the printer's maximum acceleration. To avoid this, impose a
limit on the junction velocity of short moves so that an approximate
centripetal acceleration of that move does not exceed the move's
acceleration limit.
Suggested by Michael Barbour.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Kevin O'Connor