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>
Now that the only caller to set_commanded_position() is
set_position(), remove the set_commanded_position() method and pass
the set_position() call directly to the itersolve.c code.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that the homing code does not call set_commanded_position(), it is
no longer necessary to save/restore the position in the bltouch code.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that the homing code does not use get_commanded_position(), it is
no longer necessary to alter the low-level commanded position after a
homing move.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Rename calc_position() to calc_tag_position() and have it calculate
the value of the position from the last stepper set_tag_position()
call. This enables the calc_tag_position() code to be more flexible
as it can be run with arbitrary positions.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that the tmc drivers perform automatic soft stepper enabling,
there is no need to be able to list multiple pins in the enable_pin
config setting.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Automatically detect if the stepper has a dedicated enable line. If
it does not, then automatically enable virtual enable support.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that the PrinterStepper and MCU_stepper classes have been merged,
there is no need for the add_to_endstop() method.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Move the enable line tracking out of the main stepper.py code. This
simplifies the main kinematic code.
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>
Minor rework of the loop to reduce the chance that numerical stability
could cause an infinite loop.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Update BLTouch.md, FAQ.md, and sample-probe-as-z-endstop.cfg to
recommend using a safe_z_home config section over a homing_override
config section.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
No longer allow the primary extruder to be named "extruder0". This
avoids internal and external confusion between the printer objects and
config section names.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Do not apply max_extrude_cross_section check, and do apply
extrude_only_xxx checks to Z only moves that also extrude. Some
printer start scripts will prime the extruder while moving the Z.
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>
Eliminate the old gen_steps() call now that all callers have been
converted to the newer trapq based generate_steps().
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>
Kevin O'Connor