How to correctly setup power failure detection/resurrection in 1.20?
-
Hi David,
Thanks for the reply.
Ok, I will replace the script-call with direct commands.
I am curious. If all axis coordinates are known and stored in resurrect.g, why I must home the printer after power is back?
This is a major drawback because as I mentioned before, it is not possible to rehome Z-axis, unless the print model is smaller than the gantry height.
So basically, the solution is to install Z-max endstop (Ok, It's not that big deal). -
The reason for re-homing is that when you power a printer down and up again, the stepper motors move to a close multiple of 4 full steps. So the axis positions change by up to 2 full steps or perhaps a little more.
Depending on the size of your print, you might be able to move the head to one corner of the print area and do Z homing there.
If you have a high Z steps/mm then I guess you might be able to ignore the Z motor movement because it will be small. But currently there is no way of doing that automatically. I guess it would be possible to have the firmware put a G92 Z command in the resurrect.g file to tell it what the Z coordinate was when the print stopped.
-
Thanks for the explanation.
Now its make sense to me that homing the axis in "resurrect-prologue.g" is a must.
As I mention, homing Z-axis to max is a possible solution, maybe even without installing max endstop, because I can try to home Z axis using motor stall detection (Haven't tried that feature yet). -
The reason for re-homing is that when you power a printer down and up again, the stepper motors move to a close multiple of 4 full steps. So the axis positions change by up to 2 full steps or perhaps a little more.
Depending on the size of your print, you might be able to move the head to one corner of the print area and do Z homing there.
If you have a high Z steps/mm then I guess you might be able to ignore the Z motor movement because it will be small. But currently there is no way of doing that automatically. I guess it would be possible to have the firmware put a G92 Z command in the resurrect.g file to tell it what the Z coordinate was when the print stopped.
Actually, not homing Z would work for me although I appreciate that not everyone is in the same situation. With 1mm lead screws and 1.8 degree motors, one full step is 0.005mm so 2 steps would only be an error of 0.01 mm. Even with 4mm lead screws, the error would be 0.04mm which with a 0.3mm layer height wouldn't be desperately bad. I'm guessing that Deltas use a much lower Z steps per mm but then don't they home at Z max in any case?
I might be worth having the option to have G92 Z in the resurrect.g file for lead screw driven Z axes?
-
In the meanwhile, I wrote "homeZMaxUsingStallDetection.g" script. and it's working good.
[c]
M915 Z S10 F0; Configure motor stall detection, Z motor, set stall detection threshold, set stall detection filter disabled
M574 Z2 S3; Set Z-axis home to Max endstop, Set endstop type to Motor stall detection
M913 Z85; Reduce current of Z motor to 85%
G91; Switch to relative positioning
G1 Z300 F1200 S1; Lower bed all the way down, until motor stalls
M400; Wait for move to finish
M913 Z100; Reset motor currents back to normal 100%
G1 Z-5; Raise bed by 5[mm]
G92 Z165; Set Z position
M574 Z0 S2; Set Z-axis home to Minimum endstop, set endstop type to Z-Probe (Reset to normal working mode)
[/c]so I guess I am ready to try the resurrect routine.
-
Had my first power failure during a big print early this morning, would like to resurrect.
Additional questions:
1. Why is the file in resurrect.g is called "Presurrect-prologue.g" instead of "resurrect-prologue.g" as the wiki says?
2. I never configured auto-pause with M911, yet a seemingly good resurrect.g file has been created for the print. Is there a default auto-pause in place?
3. My machine homed itself at the time of the power failure. I'm at a loss to explain how this could have happened.
The contents of resurrect.g right now:
[[language]] ; File "ExhaustPanel-P.gcode" resume print after print paused at 2018-01-13 05:07 M140 P3 S70.0 G10 P1 S0:0:0:0 R0:0:0:0 G10 P0 S215 R215 T0 P0 M98 Presurrect-prologue.g M106 P0 S1.00 M106 P2 S0.00 M106 P3 S0.00 M106 P5 S0.00 M106 P7 S0.00 M106 S255.00 M116 M290 S0.000 G92 E10.69300 M82 M23 ExhaustPanel-P.gcode M26 S4316562 P0.000 G0 F6000 Z6.560 G0 F6000 X383.10 Y181.68 G0 F6000 Z4.560 G1 F14000.0 P0 M24 -
The "P" is the parameter letter, it is not part of the filename.
In firmware 1.20 a resurrect.g file is created whenever you pause a print, so the one you have will be from when you last paused it, not from the time of the power failure unless the print was already paused when the power failed.
-
Oh, darn. Okay, thanks David.
-
…
Actually, not homing Z would work for me although I appreciate that not everyone is in the same situation. With 1mm lead screws and 1.8 degree motors, one full step is 0.005mm so 2 steps would only be an error of 0.01 mm. Even with 4mm lead screws, the error would be 0.04mm which with a 0.3mm layer height wouldn't be desperately bad. I'm guessing that Deltas use a much lower Z steps per mm but then don't they home at Z max in any case?I might be worth having the option to have G92 Z in the resurrect.g file for lead screw driven Z axes?
I can see a potential problem with that. You will probably have a command to lift Z in the power fail script, otherwise the nozzle will be stuck to the print. But if you don't have enough power reserve, that G1 Z command may not be executed accurately or in full. So you would still be uncertain of where Z should be.
A better solution might be:
- Implement a GCode to set the coordinates of the pause restore point, and generate this in resurrect.g to set it to the position when the power fail occurred
- When restarting the print, after homing X and Y and heating the nozzle, jog the head down to the correct height manually
- Implement a R1 option on the G92 command, then you cold use G92 R1 Z0 to tell the firmware it was at the Z height that is set in the psue restore point
-
But hey, that resurrect.g IS for today's date. Strange.
-
UNEXPECTED BEHAVIOR CONFIRMATION
I just successfully resurrected this print despite not having M911 defined in config.g
-
It must have automatically commanded the pause script, because it parked itself. I speculation that there was a short brownout this morning to account for it having enough power to park itself. I know you're saying that's not possible, but it did… I was sleeping when the print stopped itself, and on resurrect it picked right up where it left off.
-
Lucky you!
-
Yeah but, it seems like it issued the pause script on its own somehow. The gantry was parked, mid print. Any idea why it would do that?
-
Did I forget to mention the new firmware precognition feature?
An alert from a filament monitor will also cause a pause.
