Add a mechanism for obtaining the print_time via a callback instead of
by flushing the look-ahead queue.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that the extruder lookahead method is no longer used it can be
removed from the toolhead and extruder classes.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add support for kinematic functions that calculate step times based on
a range of the motion queue. This requires adding additional pause
times when fully flushing the motion queue.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Update code that modifies the low-level kinematics handlers to first
call toolhead.flush_step_generation().
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Don't transition to the normal movement state if there aren't any
moves actually ready to be processed.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Directly disable all the stepper motors on a global motor_off() from
the StepperEnable() class in stepper_enable.py. This simplifies the
toolhead and kinematic classes.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
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>
Kevin O'Connor