There is a chance that current_block can be NULL despite
the queue being non-empty. This can happen early after a block has been
queued, but before the isr has picked it up for processing, and/or when
the current block is at the last step and is being discarded.
Check for current_block directly to avoid this race.
Both during early init and in uvlo_tiny, display "POWER PANIC DETECTED"
if enough charge is left.
This is not worth doing in regular uvlo_, as we want to give full
priority to the X motor
If power has been lost during startup already a falling edge would be
skipped, causing the print to continue and lose its state without
being able to save again.
Check for a low line after arming the interrupt and simply wait
for reset.
Do not allow uvlo_tiny() to trigger before the previous print has
already been recovered.
A quick repeated power failure could cause uvlo_tiny to overwrite
the Z position before it has been correctly recovered.
enable/disable_z behave differently when PSU_Delta is defined.
During powerpanic and kill however we do *really* need to save energy
and poweroff the motors.
Rename enable/disable_z as poweron/poweroff_z and define some aliases so
that we can use the low-level function where needed.
Use 2 bytes to store extruder temperature during UVLO.
Re-use the storage of EEPROM_UVLO_TINY_Z_MICROSTEPS which has been freed
by previous changes.
Fixes#2303
- In both uvlo_ and uvlo_tiny, calculate Z usteps properly and adjust
the Z position to a true fullstep before disabling the motor. This
avoids shifs during recovery.
- In uvlo_tiny, instead of moving up indefinitely, adjust Z just
once using the smallest move possible (new def UVLO_TINY_Z_AXIS_SHIFT)
- Perform all the uvlo/recovery processing in physical coordinates
and MBL off: there should be no automatic Z movement!
- Disable heaters in both handlers to conserve more power.
- Add timing information to uvlo_tiny too.
- During recovery, to switch between physical and logical positioning
introduce a new "PRUSA MBL" gcode as most of the procedure is
enqueued, and no existing gcode was available.
There is frequently plenty of power left during a PP. Take advantage of
it by moving the extruder to either side of the axis to detach
completely the nozzle from the print.
Re-enable Z during this move to avoid losing the current step.
When the printer is connected to a USB host during a PP (and the host
does not lose power), the rambo can linger for longer, sometimes for
long enough to recover the print state. Drain some more power.
If the motors are off-phase, this is more likely to "bump" them to an
incorrect/reverse full-step, doing worse.
We need to ensure the motors are already positioned on a fullstep
during power panic instead.
Remove the PSU_DELTA exception: Z _always_ needs to be powered here.
Also clear the UVLO flag when using lcd_print_stop. This prevents an
aborted print which has been cancelled while unparking (just prior to
recover) to come back again at the next startup.
- Initially restore the last E position from the eeprom in any case, not
just when using absolute mode (although unnecessary: since it will be
reset later), fixing a possible unitialized position and crash during
recovery (thanks to @leptun)
- Remove useless extra calls to put the extruder in relative mode:
the extruder already starts in relative mode and is later switched to
absolute.
- Replace incorrect calls to STRINGIFY with sprintf_P
- Retract after pressure has been restored in uvlo_tiny, to be
consistent with a regular uvlo (remove the bogus double unretract
as a result).
- Set the real E position prior to the panic *after* the retraction,
using the now-fixed G92.
Do not process serial commands when re-enabling the global isr.
While printing via USB and a power panic is triggered, *any* extra
command should be ignored.
Abuse the "saved_printing" variable to inhibit serial processing.
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.
Matthias Urlichs
DRracer
Yuri D'Elia
Alex Voinea
3d-gussner