The delta code calculates a "virtual tower" along the line of
movement. Rework the variable names and comments to make it clear
that this is occurring.
It is not necessary to pass the start_pos variable to the C code as it
is simple to update the start_pos at the start of each movement.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
It's not necessary to have separate C delta kinematic functions for
constant acceleration and constant velocity as constant velocity can
be obtained by using a constant acceleration of zero.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Update the C delta kinematic code to take velocity and acceleration
directly in step distances and clock ticks. This simplifies the
mcu.py python code as it only needs to do unit and axis conversion.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
It's not necessary to have separate C functions for constant
acceleration and constant velocity as constant velocity can be
obtained by using a constant acceleration of zero.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Update the C code to take velocity and acceleration directly in step
distances and clock ticks. This simplifies the mcu.py python code as
it only needs to do unit and axis conversion.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The normal system clock can have sudden jumps if the system clock is
changed. Use the system monotonic clock to avoid these sudden changes
in time.
It appears the Raspbian OS (which is used by OctoPi) is setup to
update the system clock upon network connectivity. This could cause
sudden system clock changes which could lead to Klippy processing
errors. Using the monotonic clock eliminates these issues.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The serialqueue_flush_ready() code was used to flush queue_step
commands during a homing operation. It's no longer necessary now that
moves during a homing operation use the normal message priority
system.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The endstop homing system requires all queue_step commands be in the
MCU's 'move queue' before endstop checking starts. Use the normal
message priority system to request that stepper queue_step commands
are received prior to the start of the end_stop_home command. This
simplifies the code and removes the need for special serial queue
flushing.
This also fixes a bug in homing operations that take longer than 2^31
clock ticks.
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>
Instead of writing error messages to stderr, route them into the
python code and use the standard python logging system.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Commits f0cefebf and 8f331f08 changed the way the code determined what
steps to take on fractional steps. Unfortunately, it was possible in
some situations for the C code to round differently from the python
code which could result in warnings and lost steps.
Change the code so that all fractional step handling is done in the C
code. Implementing the step rounding logic in one location avoids any
conflicts.
In order to efficiently handle the step rounding in the C code, the C
code has also been extended to directly send the "set_next_step_dir"
command.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Store the baud rate the MCU is configured for in the "identify" data
and use that rate when calculating the baudadjust parameter.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Kevin O'Connor