If the endstops kick in, then st_get_position_mm shows the actual travel distance. current_position[Z-AXIS] does not get updated correctly thus we cannot use it when unhomed.
current_position[Z-AXIS] is later set to Z_MAX_POS,
we cannot use that either to calculate the travel distance
Removed the "plan" parameter.
We were incorrectly returning from the function if the printer was homed,
but plan = false. This would leave current_position with an incorrect value
If the printer is homed => finish the move and return the travel distance
If the printer is not homed => rely on end stop to prevent damage,
return travel distance even if the endstop stopped the move.
* Created a new function raise_z() which will move the Z axis by some
X millimeters. If plan = false, the function will return the
actual travel distance since the move is blocking.
* raise_z_above() is refactored to call raise_z()
Now the M701 and M702 will move the Z-axis relatively, and also
when done, revert the Z axis position when done.
This is a similar behavior as in Marlin 2.
It is only used when the MMU is disabled. With the MMU we use a defined ramming sequence.
When the MMU is disabled I borrowed the usages from Marlin 2.
The L parameter only defines the length for the "fast" load length.
Default value is 70mm, same as M600
Fix the unload procedure when the user has paused a print
then stopped the print after the temperature has reached below 175°C
Now the E-motor will move as expected
The following situation is now fixed, steps:
1. Load filament through LCD
2. Load to nozzle through LCD
3. Before filament reaches Fsensor => turn off the printer
4. Wait a few seconds and then turn the printer on again
5. Start a print through the SD card
6. Printer will unload and then re-load the filament
Previously in step 6, the printer would start a print without any
filament loaded.
- Dependent on current MMU error being processed
- Includes rename of LEFT_BUTTON_CHOICE -> LCD_LEFT_BUTTON_CHOICE (and right, middle as well) to avoid confusion with MMU buttons' ordering
Having the original PRINTER_ACTIVE macro copied at multiple spots doesn't make sense.
Refactoring it into a non-inline function saved ~400 bytes of code.
It should be safe in terms of performance, all occurrences are at non-time critical spots.
Call this variable menu_block_mask instead. We don't need to know the
exact reason of why we're locking the menu.
We will be able to reuse this to prevent menu entry during more
activities in a cleaner way than testing for each condition as it's
currently done for both menu entry and longpress.
If the user accepted to resume, do not wait for bed temperature when
recovering. This only adds a pointless delay when recovering a short
pause and doesn't really improve the recovery quality after a long
pause.
Do not allow resuming until all thermal and fan errors are clear.
Call the appropriate resume function when resuming a printing depending
on the saved_print state (is saved_print is available, then we always
need to resume from the saved state even when printing via usb).
Clear the Stopped state when resuming, so that commands can be accepted
again.
Force processing of the pause and stop "parking" commands _after_ the
main loop completes.
This was/is currently done in lcd_commands, which is a poor place to
continue processing, since it can be called already within an aborted
command. This requires checking for planner_aborted before any action
can be performed.
After calling planner_abort_hard() no motion command can be
scheduled until we return to the main loop since the call can
potentially be scheduled inside a nested process_command call.
Despite previous fixes, bugs keep creeping in due to nested calls not
being obvious to detect at all.
Stop allowing motion _completely_ for the entire processing loop by
default. That is, instead of aborting the current plan_buffer_line call,
abort the entire command until we can actually schedule motion safely
again.
This benefits handling of pretty much all g/m-codes, since this flag
(now "planner_aborted" for clarity) becomes a general "command aborted"
call.
This also now ensures that the flag prevents _any_ new block (including
blocks partially planned while servicing an interrupt) are scheduled
after planner_abort_hard is called.
There are only two exceptions where it's safe to resume in this context:
- Within uvlo_, where we never return to the main processing loop
- When we're intentionally scheduling a new process_command loop for a
MK3 filament recheck (which is *bad*)
Handle those two cases as exceptions.
D.R.racer
Guðni Már Gilbert
Alex Voinea
VintagePC
3d-gussner
Yuri D'Elia
DRracer