Auto-resume after power failure - any con's or comments?

[NeoDue]

I successfully managed to get the power-loss feature running, but I wonder a little why you need to manually send M916 to restart printing.

While it should be rather easily possible to do that with conditional gcode from config.g, I guess there are reasons for this - but which? I am grateful for any thoughts on the topic.

For now, I only can see the obvious "pro" advantage that the printer will resume on its own when power comes back...

[dc42]

@NeoDue said in Auto-resume after power failure - any con's or comments?:

For now, I only can see the obvious "pro" advantage that the printer will resume on its own when power comes back...

IMO it's unsafe to have a printer spontaneously start heating and/or moving when it is powered up, except perhaps if it is enclosed and has a door-open switch to allow movement only when the door is closed.

[NeoDue]

@dc42 thanks a lot! A valid point indeed - I did not think about open printers or large-format robot arm printers where this would be indeed a no-go.

Apart from the door sensors (which are according to my experience usually the first things to be circumvented at any professional machine btw), my printer does fulfil that requirement however, so I would try that, combined with a suitable warning sound, "Warning - Auto-resumes due in x seconds - press abort..." message on the PanelDue and wait time created by resurrect-prologue.g.

Unless I overlooked something in the Object model documentation there is no flag or such that indicates that the last power-down was caused by a power failure in RRF, correct?
That would mean I have to create a file with a persistent global variable for that purpose within M911 then which is read by config.g and gets reset when resurrect-prologue.g is executed since I cannot add code to be executed right after resurrect.g was executed. (Another option might be to append the reset code of the variable to resurrect.g from within resurrect-prologue.g).

[dc42]

@NeoDue at machine start there should be a resurrect.g file in the system folder only if either there was a power failure during printing, or the machine was paused and then power was removed. You can use the fileexists function to test of there s a resurrect.g file. Typically , if it does exist then you would use M291 to ask the user whether to resurrect the print.

[NeoDue]

@dc42 if I am not mistaken, resurrect.g stays where it is if M916 is not called after the reboot... but you are right, that should not matter in most cases, or I could let the macro delete the file if auto-restart is aborted.

Thanks for the hint!

[moth4017]

if you get a lot of power cuts buy a ups and run the printer on that

[NeoDue]

@moth4017 said in Auto-resume after power failure - any con's or comments?:

if you get a lot of power cuts buy a ups and run the printer on that

No, not at all! We had power outages of maybe 20 minutes - in total, summed up over the last eight years since we live here.

This is more of a "...because I can!" thing. The Duet offers these nifty functions, so why not use them?

[NeoDue]

Just a quick update, in case someone needs it: since Duet messages do not allow any other time-based action than "cancel" I went back to a simple script that is called at the end of config.g...

; add this to the end of config.g
if fileexists("/sys/resurrect.g")
    M98 P"resurrect-request.g"          ; ask if print should be resumed after power-loss

and checks for the existence of resurrect.g on startup - and if there is one, it displays a message and lets the user choose whether or not to resume printing.

In case the user chooses not to resume, he may choose to delete resurrect.g, otherwise the message will reoccur at the next boot:

; resume-request.g, called by config.g if resurrect.g exists

G4 S4                               ; wait for config.g messages on PanelDue to finish
M291 S4 K{"Resume","Abort"} P"There was a power loss during the last print.. The printing position was saved. Resume or abort print?" R"Power loss"
if input = 0
    M916                            ; resume
    M291 S1 T4 P"Resuming print..." R"Power loss"
if input = 1
    M291 S4 K{"later","delete"} P"Do you want to resume the print later or do you want to delete the saved data?" R"Power loss"
   if input = 1            
        M30 "/sys/resurrect.g"      ; delete resurrect.g
        M291 S1 T4 P"Saved printing position was deleted." R"Power loss"
    if input = 0                    ; do nothing for now  - the printer will ask again to resume after next boot
        M291 S1 T4 P"Printing position was kept. To resume the print, enter M916 or reboot the printer." R"Power loss"

[gtrider]

@NeoDue It shortens the life of the SD card is why I do not use it. Maybe only a bit but I do know they are only good for a certain number of writes.

[NeoDue]

@gtrider Okay, I never had issues with that. I have been using the same (good quality, however) SD card for over seven years in my old printer - Duet standalone by the way, no SBC or such. The small handful of additional writes (which only happen if there is a power fail - i.e. one power fail = one additional write) are nothing I care about.

[gtrider]

@NeoDue True but if power is off more than however long it takes my heated bed to cool resurrecting would be a moot point . Was just reminded of that by the pops from the recent completed print. It sticks perfectly while hot and releases when cool.

[NeoDue]

@gtrider yes, that makes sense. My bed holds the parts rather long, but it would indeed make sense to preheat it to maybe 45...50 degrees if it was heated up and if there is a power failure (blackouts are usually short here, if they occur - but it might take a while until I notice what happened). Let me see if I can add that in a safe way...

[Phaedrux]

@gtrider said in Auto-resume after power failure - any con's or comments?:

@NeoDue It shortens the life of the SD card is why I do not use it. Maybe only a bit but I do know they are only good for a certain number of writes.

This isn't true of the Duet power loss recovery. It's not continuously writing anything to the SD card. It only writes when the power loss is detected with the remaining power left in capacitors it executes your final moves and saves position data.

[NeoDue]

@Phaedrux exactly, that is what I meant with my post above "...which only happen if there is a power fail - i.e. one power fail = one additional write"

Just for sake of completeness: if I am not mistaken, the Duet barely ever writes to the SD card unless the user explicitly tells the board to do so, e.g. by uploading print files, defining "write to SD card" commandos in his macros or when updating firmware.

But to my judgement any Raspi has a hugely higher amount of SD card file writes than a Duet.

[gtrider]

@Phaedrux Ahh so it is not as bad as Marlin version. That one tended to shorten the life of the SD card with the constant writes. I have a large UPS for each of my printers so the only way I would need to worry is if the power was off more than 15 minutes. That long and I'm probably going to be in the dark awhile.

Maybe it is different now but years ago when I tried it on an 8 bit card it also left artifacts on the prints..

[NeoDue]

@gtrider on the Duet, the auto save on power fail function does exactly nothing - unless the Duet detects that input voltage falls below the value you have specified as lower limit in M911. In case that happens, it executes the short script you define in the same command and saves one file to the SD card. That is why you may need to add a large enough capacitor to the input of the Duet to provide enough time to do that.

That's it, and therefore I assume there is no influence on print quality at all (I also do not observe any).

The little script above then only somewhat eases restarting the print when power comes back.

As far as I understand your experience from what you wrote, you know some auto save feature that constantly saves data on the SD card in order to be able to resume in case of a power loss. That one would kill the SD card indeed sooner or later.

[gtrider]

@NeoDue Interesting, I just did a quick search and apparently Marlin still writes where it is in the print to the SD card. So there will be some wear. With a more modern control board not the prehistoric 8 bit one I tried it with there should not be blobs all over the print. That was ugly.

And something Duet can brag about, that option for Klipper is apparently not mainstream. It's tinkerers doing it. And the one I found seemed to be a variation of Marlins so it writes constantly to the SD card.

A big UPS is probably the best method. I hear the ones in the house and the one out in the shop occasionally chirp. Checking it is a usually a power dip, maybe a tree branch or suicide squirrel as the cause. Mine are good for at least 15 minutes but since most power blips when they do occur are less than a few seconds one large enough to handle the load of the bed heating up is all you should need.

[deckingman]

@gtrider said in Auto-resume after power failure - any con's or comments?

.........A big UPS is probably the best method.............

There is an alternative worth considering if you have a decently thick bed with a mains powered heater. That is to use a DC UPS. On my printer, if power should fail, the UPS cuts in and a couple of 9Ah batteries wired in series will keep the 24V supply and hence the machine running for many hours (about 4 hrs to reach 50% discharge) Naturally the bed will gradually cool and after a couple of hours or so, the part will likely fall off (because the bed heater is mains powered). But invariably any power outages I've seen have been much less than an hour so I've never (yet) lost a print.

[Thalios]

I have a dumb question regarding resume after power failure..

Does the printer have to re-home? If so, how do you home Z when there's a partial print on the bed?

[NeoDue]

@Thalios On my printer, the z homing sensor is at maximum z., therefore I do not have any issues with homing with a print.

But the Duet saves the z position at shutdown. Therefore, if you have the usual lead screw for z which stays where it is, it should suffice to just reload the z value with a G92 command as suggested here: https://docs.duet3d.com/en/User_manual/Tuning/Resume