It's possible for a printer with very fine resolution to require a
large number of steps for a homing operation. Instead of storing all
of those steps in memory, periodically flush the queue should more
than 64K steps be present. This keeps a reasonable limit on the
amount of ram needed to store steps.
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>
Revert 4a16053c and avoid integer overflows in the addfactor
calculation by exiting the loop early if count > 0x200. This provides
stronger protection against overflows.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Commit a217c0f3 changed the way the "addfactor" was calculated.
Unfortunately, it was possible for the updated method to cause an
integer overflow and have a negative addfactor. Fix this by
explicitly casting the addfactor calculation to uint32_t.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Some motors have very small step distances and they can generate over
a million steps during a homing operation. Increase the maximum count
to ten million to avoid triggering the internal sanity check.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Instead of splitting the available "add range" in half, try for add
values closer to the higher end of the range. This heuristic seems to
result in better choices.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Change the min/maxadd variables to use an inclusive range instead of
exclusive. This better matches min/maxinterval.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Make it clear which variables refer to the best verified point found
so far, and which variables deal with the next (not yet verified)
point.
Also, remove checked_count as bestcount serves the same purpose.
Also, allow minmax_point to be inlined.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Most moves are on the XY plane - avoid a few multiplications in the
inner loop in this case. When there is a Z move, it is almost always
entirely a Z move - avoid the sqrt() call in the inner loop in this
case.
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>
Move flush() and check_expand() code to a new location so that the
stepcompress_push_X() functions can flush.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Update the stepcompress C code to check for integer overflow so that
the python code does not need to. The new checks also handle the
possibility of a single move lasting long enough to cause an overflow.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Use a non-zero qm->min_clock value to indicate that the command uses
the move queue and to also store the clock of when that move queue
item will be released.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
It's theoretically possible for floating point truncation to cause a
math formula to return a small negative number instead of 0. If
sqrt() is called on this small negative number it could cause a
crash. Check for this case and return 0.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Commit 47f30331 converted compress_bisect_add() to use "best reach"
instead of "best add". However, that change caused
compress_bisect_add() to behave poorly when passed in invalid data
(negative times). Change the code to better handle invalid data.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Search for the maximum reachable value instead of the maximum "add".
The maximum reachable value encompasses both the maximum count and a
closest step time to the last requested step time. This allows for
more "add=0" sequences to be generated which the mcu can optimize for.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The test to check if the queue only needed to be moved was not correct
and it could lead to a segfault if clean_queue() was called instead of
actually increasing the queue size.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Check for an invalid count and report an error if found. This
prevents some segfaults when count goes negative.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
At high step speeds, it is possible to exit the inner scan due to
integer truncation. Always update minadd or maxadd so that the outer
loop always terminates.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Kevin O'Connor