Similarly to resume_print_from_ram_and_continue, abort any
planning in mesh_plan_buffer_line already in stop_and_save_print_to_ram
in case it is called for pausing only.
Remove the conflicting and mostly useless card.paused flag (the printing
is either paused, or not) and switch to isPrintPaused only which
accounts for both cases (SD/USB) correctly.
Fix M27/getStatus to show the current real status of the SD print.
Synchronize the queue on M601, as required to precisely pause the print
at the correct instruction.
Alias M25 to M601, which when combined with PR #1899 fixes issue #1614.
Guard against incorrect usage in M601, M602 and M603.
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
Remove incorrect usage of stop_and_save_print combined with the
fsensor_recovert internal instruction which would result in a
broken sequence of events and/or broken stack.
Re-use the now safe stop/recover functions in the same spot
(fsensor_checkpoint_stream) to effectively cut a hole in the current
gcode stream to insert an M600 instruction, which removes all
recursive behavior without the need of extra state variables.
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.
Ensure card.printingHasFinished sees all the planned moves before
clearing sdprinting. To do that, we need to ensure all SD commands
exited the command queue.
