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

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

infiniteloop

@Thalios

I have a dumb question

Not so dumb at all…

Does the printer have to re-home?

That depends…

What kind of power failure do we expect? On a sharp power cut, the idea is that all movements stop immediately, then, with the remaining power in the capacitors (of PSU and Duet boards), the positions of all axes are written to the SD card. However, there are other types of power failures such as „brownouts“ or intermittent outages due to a lightning hitting the line - at least in theory, the mechanical position may then be out of sync with the latest stored coordinates. Luckily, we can ignore this case as we can’t do anything to prevent it.
Assuming a clear power cut: will the printer mechanics stop on the spot, or will inertia and/or gravity cause further movement of an axis? If, for instance, a heavy bed tends to give way down due to its own weight, the final Z-position differs from the Z coordinate stored in resurrect.g. Obviously, any axis which is suspected to not hold its exact position after a power loss will need to be re-homed.
Which precision per axis is required to continue a print? In the event of a power loss, stepper motors tend to skip microsteps, I.e. they like to snap into some full-step position. Same thing may happen when they are re-powered. In the worst case, these effects may add-up to a misalignment of two full steps - depending on your printer’s steps/mm, layer height and line thickness, this can be either tolerable or ruin your print. In case of the latter, the relevant axes have to be re-homed.

To conclude: In most cases, re-homing of X and Y is possible without interfering with a print on the bed, so simply do it.

how do you home Z when there's a partial print on the bed?

Good question. I can think of three different solutions:

Using a probe (such like a BLTouch), you can possibly probe your bed along one or more edges or in some corner - given that the printable area is smaller than the bed’s physical dimensions and the head or gantry are guarantied to not collide with the print object. However, if your printer has multiple Z drives (which is good for tramming or even bed levelling), probing just one corner can result in a bed not being well levelled.
Using (additional) high-end switches on all Z-drives, you can re-home Z with these. This may be a bit less precise than using a probe, but could be good enough to resume the current print job.
Trust in god and simply continue to print. Small inconsistencies can be corrected on the fly by adjusting the microsteps via DWC. If, however, your printer tends to not hold its Z-height when left without power, this method is unsafe.

To conclude: as a general solution, #2 is the way to go, but often, #3 does surprisingly well (depending on the mechanics of your printer).

Finally, you can prevent the thread of a power loss by providing some kind of UPS: admittedly, a full-fledged UPS powerful enough to keep a bed heater alive is costly, but in most real-world scenarios, a low-voltage (e.g. 24V) battery bank feeding just the steppers, nozzle heaters and controllers, will save your day. See @deckingman's post above, he has the expertise.

Thalios

@infiniteloop Thanks! That's the answer i was looking for!

I have tweaked my resurrect-prologue.g to home XY and hope that Z stays where it was. It is on a Railcore Core XY, so it's tricky to rehome Z.