Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    How to correctly setup power failure detection/resurrection in 1.20?

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    6
    25
    3.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • botundefined
      bot
      last edited by

      Is the resurrect.g being created by copying the entire remainder of the contents of the printing gcode file to the new file?

      *not actually a robot

      1 Reply Last reply Reply Quote 0
      • Ak Ericundefined
        Ak Eric
        last edited by

        @dc42: Thanks!

        @bot:
        It does not: By looking at one that my bot made, it's reloads the original gcode with an M23, the sets the current gcode position via a M26, sets the xyz location of the hotend, then restarts the print with a M24.

        1 Reply Last reply Reply Quote 0
        • botundefined
          bot
          last edited by

          Thanks!

          *not actually a robot

          1 Reply Last reply Reply Quote 0
          • Guyarosundefined
            Guyaros
            last edited by

            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 Reply Last reply Reply Quote 0
            • dc42undefined
              dc42 administrators
              last edited by

              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.

              Duet WiFi hardware designer and firmware engineer
              Please do not ask me for Duet support via PM or email, use the forum
              http://www.escher3d.com, https://miscsolutions.wordpress.com

              1 Reply Last reply Reply Quote 0
              • Guyarosundefined
                Guyaros
                last edited by

                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).

                1 Reply Last reply Reply Quote 0
                • dc42undefined
                  dc42 administrators
                  last edited by

                  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.

                  Duet WiFi hardware designer and firmware engineer
                  Please do not ask me for Duet support via PM or email, use the forum
                  http://www.escher3d.com, https://miscsolutions.wordpress.com

                  1 Reply Last reply Reply Quote 0
                  • Guyarosundefined
                    Guyaros
                    last edited by

                    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).

                    1 Reply Last reply Reply Quote 0
                    • deckingmanundefined
                      deckingman
                      last edited by

                      @dc42:

                      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?

                      Ian
                      https://somei3deas.wordpress.com/
                      https://www.youtube.com/@deckingman

                      1 Reply Last reply Reply Quote 0
                      • Guyarosundefined
                        Guyaros
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • justine.hauptundefined
                          justine.haupt
                          last edited by

                          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
                          
                          
                          1 Reply Last reply Reply Quote 0
                          • dc42undefined
                            dc42 administrators
                            last edited by

                            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.

                            Duet WiFi hardware designer and firmware engineer
                            Please do not ask me for Duet support via PM or email, use the forum
                            http://www.escher3d.com, https://miscsolutions.wordpress.com

                            1 Reply Last reply Reply Quote 0
                            • justine.hauptundefined
                              justine.haupt
                              last edited by

                              Oh, darn. Okay, thanks David.

                              1 Reply Last reply Reply Quote 0
                              • dc42undefined
                                dc42 administrators
                                last edited by

                                @deckingman:

                                …
                                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

                                Duet WiFi hardware designer and firmware engineer
                                Please do not ask me for Duet support via PM or email, use the forum
                                http://www.escher3d.com, https://miscsolutions.wordpress.com

                                1 Reply Last reply Reply Quote 0
                                • justine.hauptundefined
                                  justine.haupt
                                  last edited by

                                  But hey, that resurrect.g IS for today's date. Strange.

                                  1 Reply Last reply Reply Quote 0
                                  • justine.hauptundefined
                                    justine.haupt
                                    last edited by

                                    UNEXPECTED BEHAVIOR CONFIRMATION

                                    I just successfully resurrected this print despite not having M911 defined in config.g

                                    1 Reply Last reply Reply Quote 0
                                    • justine.hauptundefined
                                      justine.haupt
                                      last edited by

                                      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.

                                      1 Reply Last reply Reply Quote 0
                                      • dc42undefined
                                        dc42 administrators
                                        last edited by

                                        Lucky you!

                                        Duet WiFi hardware designer and firmware engineer
                                        Please do not ask me for Duet support via PM or email, use the forum
                                        http://www.escher3d.com, https://miscsolutions.wordpress.com

                                        1 Reply Last reply Reply Quote 0
                                        • justine.hauptundefined
                                          justine.haupt
                                          last edited by

                                          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?

                                          1 Reply Last reply Reply Quote 0
                                          • dc42undefined
                                            dc42 administrators
                                            last edited by

                                            Did I forget to mention the new firmware precognition feature? 😉

                                            An alert from a filament monitor will also cause a pause.

                                            Duet WiFi hardware designer and firmware engineer
                                            Please do not ask me for Duet support via PM or email, use the forum
                                            http://www.escher3d.com, https://miscsolutions.wordpress.com

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA