Fix some Power Loss Recovery behaviors

[sjasonsmith]

Description

Retracts were never performed on power-loss, even though Configuration_adv.h has this to say:

    //#define POWER_LOSS_RETRACT_LEN 10 // (mm) Length of filament to retract on fail. Requires backup power.

This change performs the retract immediately prior to the Z Raise.
I performed slight cleanup in the recovery code, but did not need to change it at all for Retract/Purge to function.

Note: There are probably still more retract/purge issues related to multi-tool configurations. I don't have the hardware to debug this, so did not attempt to address it.

Benefits

Performs retract on power-loss, in accordance with the header claims.

Related Issues

#18192 (Only solves one part of this issue)

[sjasonsmith]

I'm hoping someone will notice this and try it out. This should solve one of the problems @DrumClock mentioned in #18192. I don't know whether it fixes enough for them to test with on their machine.

[DrumClock]

@sjasonsmith failed compilation

Details…

Configuration_adv:

 #define POWER_LOSS_RECOVERY
  #if ENABLED(POWER_LOSS_RECOVERY)
    #define PLR_ENABLED_DEFAULT   false // Power Loss Recovery enabled by default. (Set with 'M413 Sn' & M500)
    #define BACKUP_POWER_SUPPLY       // Backup power / UPS to move the steppers on power loss
    #define POWER_LOSS_ZRAISE       20 // (mm) Z axis raise on resume (on power loss with UPS)
    #define POWER_LOSS_PIN         64 // Pin to detect power loss. Set to -1 to disable default pin on boards without module.
    #define POWER_LOSS_STATE     HIGH // State of pin indicating power loss
    #define POWER_LOSS_PULL      pulldown     // Set pullup / pulldown as appropriate
    #define POWER_LOSS_PURGE_LEN   20 // (mm) Length of filament to purge on resume
    #define POWER_LOSS_RETRACT_LEN 10 // (mm) Length of filament to retract on fail. Requires backup power.

    // Without a POWER_LOSS_PIN the following option helps reduce wear on the SD card,
    // especially with "vase mode" printing. Set too high and vases cannot be continued.
    #define POWER_LOSS_MIN_Z_CHANGE 0.05 // (mm) Minimum Z change before saving power-loss data
  #endif

[sjasonsmith]

@DrumClock I don’t think that failure is from my change. Maybe you accidentally deleted an #endif from your configuration file?

[ellensp]

@DrumClock my guess is you didn't copy the last line of the file powerloss.cpp
ie "#endif // POWER_LOSS_RECOVERY"

[sjasonsmith]

I'm copying some comments from @DrumClock along with my replies over from the open issue. That way @thinkyhead can see it all in one place.

does not turn off Part-Cooling Fan

Turning off fans might contribute to heat creep and clogs, if the wrong fans are disabled. I don't think it is always save to assume that all the numbered fans controlled by M106/M107 are only part-cooling fans. There may be other fans that need to run as long as power remains. Something can surely be done here, but the correct fix is less obvious than the missed retract on power-loss.

retraction 10 mm filament
move axis X,Y to last print position
lift Z to last prtint position
extrude 10 mm filament

After purging POWER_LOSS_PURGE_LEN this then retracts by POWER_LOSS_RETRACT_LEN prior to moving to the print.
In your case this excessive, but another variable would have to be added to make it something shorter.

Does the long retract cause problems for you, or is it something you can live with? Since I do not actually use this feature, I would rather leave adding new features to somebody who does.

[sjasonsmith]

Regarding the retract after purge, it might be pretty useless anyway. Maybe it can just be removed. That behavior was already there, but the configuration file comments certainly do not indicate that POWER_LOSS_RETRACT_LEN will be used during recovery, only on power loss.

At least on my printer, the retract does nothing to remove the purged filament from the nozzle. The entire purge travels to the print anyway. Whether it oozes a little more while traveling would make no difference.

That retract might be more valuable if you have a brush set up so that the nozzle has to travel over it while leaving the home position. Longer-term it seems like maybe the user should just provide a sequence of G-Code to execute on recovery, then they can do anything they want.

[DrumClock]

@sjasonsmith
Turning off the Part-Cooling fan (or all) could save some power from the UPS. Priority for filament retraction and Z raise, etc. Anyway, after consuming power from the UPS, all fans will turn off :) I would still try it on my V-extruder, where it is not possible with the current program.

Here it would have to be like this:

1. printing in progress e.g. nozzle 1
2. blackout (power OFF)
3. HotBed heating off
4. HotEnd 1 and 2 heating off
5. ( turn off Part-Cooling Fan or all) ??
6. nozzle 1 retraction 10 mm filament
7. Z lift on 20 mm
8. switching nozzle (servo 0)
9. nozzle 2 retraction 10 mm filament

steps 8 and 9 will not take place now

Yes, the 10 mm retraction in the event of a power failure is great.
I just think it might not be the same when resuming printing.
But you can live with it :)

[sjasonsmith]

@DrumClock I'm going to wait to hear some more input. I feel confident fixing obviously broken things. When it starts to redefine or add to the feature I think more input is desired. Even if I did more work on that retract, it would probably not help at all with your switching nozzle. I am personally not interested in doing all the work to expand these capabilities 😊

Thank you for being so helpful with your feedback. I think we will end up fixing some things now, then maybe create one or two feature requests for future improvements. For now we wait until this is looked at by other people.

[DrumClock]

@sjasonsmith
Yes, I know that the V-extruder probably doesn't have many people :)
I will be happy to help with testing, I still have one printer for this purpose and I am constantly rebuilding it ....

[DrumClock]

Hello @thinkyhead , is it possible to download the last modified powerloss.cpp
file so I can try it? I'm afraid abch didn't make a mistake while rewriting.
Thanks.

[sjasonsmith]

is it possible to download the last modified powerloss.cpp
file so I can try it? I'm afraid abch didn't make a mistake while rewriting.
Thanks.

@DrumClock, this link will take you to the full file from this PR branch. It will update as changes are pushed to this pull request:
(use the "raw" button to get to the file you can save)
https://github.com/sjasonsmith/Marlin/blob/PR/powerloss_retract_purge/Marlin/src/feature/powerloss.cpp

[DrumClock]

thank you @sjasonsmith
I upload to the printer, test and send the results.

[DrumClock]

Actual behavior single extruder test :

1. printing in progress
2. blackout (power OFF)
3. HotBed heating off
4. HotEnd heating off
5. fast retraction filament 10 mm
6. Z lift on 20 mm

RESTART PRINTER (power ON)

1. resume printing from the LCD
2. axis X,Y moving to 0 position
3. waiting for HotBed heating
4. waiting for HotEnd heating
5. turns on Part-Cooling Fan
6. fast extrude 10 mm filament
7. slow extrude 20 mm filament
8. move axis X,Y to last print position
9. lift Z to last prtint position
10. printing continues correctly

[DrumClock]

I tested the dual extruder.
Unfortunately, the POWER_LOSS_RECOVERY function is not usable here.
When T0 prints and an outage occurs.
Printing then continues with T1 into the material for T0.

[thinkyhead]

I have moved the Tool-Change after the loop which calls T<hotend> and M109 to heat up the previous hotends. This loop could leave the last-heated-up tool selected instead of the last-active tool.

[DrumClock]

Hi, @thinkyhead now resumes printing with the correct T0 or T1 tool after recovery.
Errors remain:
In the event of a failure and recovery, retraction and extrusion are not performed on the tool that did not print.

[DrumClock]

@thinkyhead is it a serious problem?

[DrumClock]

@thinkyhead
If the printer does not print and the power is turned off, POWER_LOSS_ZRAISE is activated at that time, but the Z-MAX endstop is not respected, and it is a problem when the Hotbed is in the maximum position.

I found out only after connecting the Makerbase MKS UPS 24v module that came today.
Previously, I simulated a blackout with a switch on pin 64, which was in the state "LOW" = power OK when turning off the printer.

[DrumClock]

I use pronterface. Can I create a log in it and how can I please?

[thinkyhead]

A "log" is just the text output that appears in the console. You select the text and use the "Copy" command in the "Edit" menu to put it in the clipboard. Then you can use the "Paste" command to put it someplace else. Pronterface might allow you to save the console output into a text file with the "Save" command.

[DrumClock]

@thinkyhead

* Marlin-bugfix-2.0.x 
* Downloaded:	13.7.2020
*
* Tested: Fix some Power Loss Recovery behaviors #18558
* https://github.com/MarlinFirmware/Marlin/pull/18558/files
*
* Replaced files:
* Marlin/src/lcd/language/language_en.h
* Marlin/src/MarlinCore.cpp
* Marlin/src/feature/powerloss.cpp 
* Marlin/src/feature/powerloss.h
* Marlin/src/gcode/feature/powerloss/M413.cpp 
*

HotBed and HotEnds do not heat up after recovery.
The T0 nozzle is retracted and printing continues.

As seen in the video above.

Here is an extract from Pornterface: pronterface.zip

The time shift of +7 hours between Austin and Pilsen is unfavorable for testing changes.
Can't we find common time if we can test? E.g. Austin 3-5 pm and Pilsen 10-12 pm?

[thinkyhead]

Thanks, @DrumClock. We're not going to get any more useful information this way. You can move on to other things and we'll attend to this issue directly.

[DrumClock]

Thanks, @DrumClock. We're not going to get any more useful information this way. You can move on to other things and we'll attend to this issue directly.

OK, @DrumClock. It was just a suggestion.
Did the statement from Pronterface help?
If you need something else, please follow the steps on how to create it.

The last functional file powerloss.cpp was from commit 9503011

Thank you.

[sjasonsmith]

HotBed and HotEnds do not heat up after recovery.

I just saw the same behavior when resuming. Just lots of cold extrusion messages with no attempt to enable the heaters.

[sjasonsmith]

Heaters were not coming back because they were disabled in the thermal manager prior to saving the machine state. I reordered these to leave heaters enabled until after the save(), so that the thermal manager will still have the needed values present.

If there is concern that there won't be time to save to SD due to the heaters, then a little more rearranging will be needed, such as splitting save() into separate prepare() and write() calls, with heaters disabled between them.

[thinkyhead]

Ah, of course! I disabled the heaters to save energy. I still want to disable heaters to save energy for the save to SD, but I'll copy the temperatures to an array or to the save buffer first.

[DrumClock]

The POWER_LOSS_RETRACT_LEN and POWER_LOSS_PURGE_LEN steps are performed
only for the EXTRUDER that was printing at the time of the outage recovery.

It is possible to perform these steps with all active EXTRUDERS ?

[thinkyhead]

Anything is possible. It's just a matter of someone having the time and the inclination to implement it. Consider the power-loss recovery feature to be an open-ended starting-point for more ambitious developers.

[DrumClock]

So should I enter a new "Bug report" or "Feature request"?

I don't understand, FW Marlin is able to control 8 EXTRUDERS though
the POWER LOSS RECOVERY function only works for one.

It's ..... like having five seats in a car but only four seat belts ....

I'm willing to test this feature on a printer with two EXTRUDERS.
After all, today there are a lot of users who have two nozzles on either one carriage or IDEX.

[thinkyhead]

It's ..... like having five seats in a car but only four seat belts ....

It was contributed by Creality3D, made for very basic machines, and as with all other features, it is a perpetual beta.

Please use Discord if you want to have discussions and talk philosophy: https://discord.gg/n5NJ59y