How to correctly setup power failure detection/resurrection in 1.20?
-
Hi,
I have several questions in regards to the power failure routine.
I wrote in the config the command:
[c]M911 S23.0 R25.0 P"M98 PpowerFailure.g";[/c]powerFailure.g contains the following commands:
[c]
; This script runs automatically if a power failure has occurred during printing
M913 X0 Y0; Set X and Y motors to zero current (M913 X0 Y0). This is to make the power last longer
G91; Set relative positioning
M83; Set relative extruder positioning
G1 Z3 E-5 F1000; Simultaneously lower bed by 3[mm] and retract filament
[/c]So now, after a power failure had happened, if voltage is below 23[v], all the print paraments should be saved in the file "resurrect.g"
Assuming that the head and bed did not move while the printer was off, why would I need to home axis again while resume printing?
I would expect that M916 command, will automatically set axis location (G92) based on the saved paraments that stored in resurrect.g
Actually, I cannot home Z-axis, because that would cause the printed part to crash into the printer gantry.Let's say I want to pause the print and shut down the printer, but I wish to be able to go back printing from the same position in the next day.
Assuming the printer axis did not move while the printer was off.
Should I just pause the print, shut down the printer and let the power failure routine to do its job, or there is another more elegant way perform a safe shut down, with the option to resume to the same spot?Should I need to manually create the file "resurrect-prologue.g" ?
which contains the following commands:
[c]
M116 ; Wait for temperatures
M83 ; Set relative extrusion
G1 E5 F300 ; Undo the retraction that was done in the M911 power fail script
[/c]Thanks,
-
1. Don't call macros in your power fail script, it slows down the response, making it more likely that you will run out of power before it is completed. Put the commands directly in the script instead.
2. Firmware 1.20 saves the resume info any time you command a pause. So just pause the print and then turn the printer off. The power fail script will not be run because the printer is already paused.
3. As described in the wiki, you need to home the printer too in your resurrect-prologue.g file, without the head colliding with the print.
-
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.
