To maintain an accurate step count (which is required for correct
position recovery), any call to plan_set_position&co needs to be done
synchronously and from a halted state.
However, G92 E* is currently special-cased to skip the sync (likely to
avoid the associated performance cost), causing an incorrect E step
count and position to be set. This breaks absolute position recovery,
miscalculation of the LA factor and possibly other weird issues.
We rewrite the handling of G92 to always sync but still special-case the
frequent "G92 E0" for performance by using a free bit in the block flags.
To avoid a sync, we relay the request for reset first to the planner
which clears its internal state and then relays the request to the final
stepper isr.
Since the global feedrate can be similarly modified for moves ahead of
time, save the original feedrate in the planner as we do for
gcode_target.
This avoids having to undo feedmultiply (and machine limits!) from
"nominal_speed" as previously done.
Thanks @leptun
When starting to replay existing USB/SD commands from a recovery state,
an immediate relative move needs to compensate for a previously
interrupted move. This is almost the norm for the E axis.
Instead of saving the relative status of the move (which needs to
account for the world2machine conversion and is not always available on
a chunked move split by MBL) save directly the calculated target
position for the move in the original plan, which is easy to replay.
While handling moves in a recursive plan, such a filament check,
ensure restore_print_from_ram_and_continue unwinds the stack by
aborting early from any call that waits on the planner.
This currently only handles G1 moves, but hard-coded behavior that can
trigger recursive behavior (such as filament change) will probably have
to be checked too.
Do not store the block e_D ratio, store directly the computed
compression factor so that we can recompute the advance steps
quickly and update them in sync with the acceleration rates.
access to the low / high words of the 32bit values.
This is a prerequisity for an optimized 16bit only DDA
in case the number of step is lower than 32767.
Improved accuracy of diagonal moves by oversampling the path discretization.
Accelerated the planner by rewriting time critical routines from floating
point to fixed point arithmetics.