One-press resume printing after power failure

[resam]

I think the actual Z position is not written to the resurrect.g file, is it?
On a printer with z-min homing like a regular cartesian or CoreXY this is basically useless...?

I understand the problems and everything - but maybe at least write the last Z position into the file (as a comment) so the user can manually use G92 Z.

[dc42]

@resam said in One-press resume printing after power failure:

I think the actual Z position is not written to the resurrect.g file, is it?
On a printer with z-min homing like a regular cartesian or CoreXY this is basically useless...?

I understand the problems and everything - but maybe at least write the last Z position into the file (as a comment) so the user can manually use G92 Z.

Of course there is a command to move the head to the correct Z position to resume the print, without it the print couldn't be resumed. You will find it in the resurrect.g file.

[resam]

Yes - the movement command is there - but at this point I might not have my Z homed yet (or used G92 for that matter). If I want to resume, I first need to look into the resurrect.g file, search for the first G0/1 command with a Z component, and then use G92 with that Z value to "home" my Z. Only then can I use the resurrect to resume my print.

Not very intuitive or easy to use.
I would propose to at least add a comment at the top of the file:

; Z height before power was lost: 12.5mm
; Z height after running the "auto save on loss of power" g-codes: 15.5mm

Ideally M911 would be aware of my Z-homing disability and simply show me a M291 error message so I am reminded to use G92 first.

[Phaedrux]

@resam you are in control of the resurrect prologue macro. You can define however you want to home the z there.

I agree it would be beneficial to call out the saved z height in a more accessible place though.

I added an optical endstop for zmax on my corexy and made a zmax homing macro for this purpose. Can't you do the same?

[resam]

@Phaedrux well, ideally I don't want to move my leadscrew-driven bed at all!

They are self-locking, so in the case of a power outage they will not move.

They might shift due to microstepping switching into the next position, but I think I can live with that on a TR8x2 and 0.9° steppers ; with 3200 steps/mm.

[Phaedrux]

@resam agreed. I'm on triple tr8*1 belted to a single 0.9 motor. 6400 steps. With the power off I can't even push the bed down.

But as I said, you can script out the resume-prologue to set z however you like. For instance this should get you what you want if you have your z axis max travel measured accurately. Just replace G92 Z300 with whatever your zmax is.

; resurrect-prologue.g
;
; Called by resurrect.g after a resume from powerloss.
; 

G28 XY			; Home X and Y
M291 S3 Z1 R"Set Z Position to Z Max"
G92 Z300
M116			; Wait for temps
M83			; Relative Extrusion
G1 E2 F1000		; Undo retraction and prime nozzle

; Returns to resurrect.g to resume print

[resam]

Thanks @Phaedrux - this looks interesting!
Right now I have no idea what my Zmax actually is - I've never traveled there...
Guess I should setup an accurate endstop or indicator...

Still, I would prefer if I don't have to move my bed at all, if possible.

Too bad g-code has no variables or placeholders. I think this would have been a good use case (at least in my narrow-minded workflow )

[Phaedrux]

@resam well you don't have to move the bed at all really. If it hasn't dropped at all you can simply modify that macro before you print the resurrect file and change the G92 Z value to be the final z height from the time of power loss. You'd still have to dig it out yourself though.

[resam]

Yes - thats what I'm complaining about
I don't want to go digging around to find the Z value.

It would be nice to at least put it at the top of the file in a nice comment.

Even better would be some sort of integration / M291 magic - but this might be highly specific to each printer type, so I'm not putting my hopes up.

[wilriker]

@resam said in One-press resume printing after power failure:

I would propose to at least add a comment at the top of the file:

; Z height before power was lost: 12.5mm
; Z height after running the "auto save on loss of power" g-codes: 15.5mm

From what I can see in the source code at least the first line should be fairly easy to add.
I would be a little bit concerned with the second one as this is the height of Z if and only if there was enough power left to move Z - and this could even be only a partial movement.

Here we come to a point of uncertainty on my side as the code here is rather complex: AFAICT the file is written before running the M911 P part so at this time it is unknown whether this will succeed or not - and at the time it is known the file is closed and probably not enough power left to append this info either.
This might be confirmed by @dc42.

[resam]

Yes there is uncertainty - thats why I think adding both values would be good.
The user should check & verify the current Z height against these two values before proceeding.
I guess I could deduct the second value myself by looking at my M911 command list... but this would be yet another file to check...

[wilriker]

@resam said in One-press resume printing after power failure:

The user should check & verify the current Z height against these two values before proceeding.

But how do you reliably check whether Z has moved 2mm away or only 1.92mm - or any value in between. The nozzle of my printer is surrounded by stuff, so I would have no chance to get anything between the nozzle and the print to accurately measure this distance. Of course ball-park-numbers of full mm should be doable but finer then this... I don't see a chance.

What could be done with the first value (but that would still be extra manual work) would be to move the nozzle back manually onto the print (at best before heating up to not damage the print) and then set Z height based on what's in the comment. But at least the comment would help in that case.

---

I just had another look at the source code. The Z height is already in the file. It should be the third to last command

G0 F6000 Znnn <---
G1 Fnnn
M24

where nnn denotes the Z height at pausing.

[dc42]

I think the long-term solution will come when we support variables and parameters in GCode commands. Then we will be able to pass the Z height at which the print stopped to resurrect-prologue.g, and it can be used in a G92 command in that file.

[dc42]

Firmware 2.01 beta 2 puts a G92 command in resurrect.g, just before it calls resurrect-prologue.g.

[resam]

This is a step in the right direction!

As you clearly stated, this does not account for any Z movement in the command string when the print is stopped with M911.

Thinking about it some more, this means that people who can't home Z with a print on the bed should NOT perform any Z movement in the command string when the print is stopped with M911, because the G92 will not account for it, and you will end up 3mm too low (inside you print).

Since this would leave a hot hotend directly over your print, causing it to warp/melt, adding a Z-hop would still be beneficial.

@dc42 how about adding a new parameter to M911 that controls when and which G92 commands to insert. Something like:
M911 S19.8 R22.0 T0:0:2 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000"

With Tx:y:z being a single digit for each axis:

• 0: do not use G92 for this axis (there must be a G28 in resurrect-prologue.g for this axis!)
• 1: run G92for this axis with the last saved position before calling resurrect-prologue.g
• 2: run G92for this axis with the last saved position after calling resurrect-prologue.g

For my CoreXY machine, I would use T0:0:2, because I can home X and Y in the resurrect-prologue.g, but afterwards, I want to use G92 to set my Z height.
This allows people to not home at all, as well as doing a "partial" home for some axis.
Maybe this also helps people with absolute extruder coordinates, I'm not sure how this is currently handled?

Does this make sense, or am I missing anything?

[wilriker]

@resam I think you have a small mistake in your description of what "2" means because it is identical to what "1" means. I guess that 2 would mean setting G92 after resurrect-prologue.g, wouldn't it?

[resam]

@wilriker thanks - copy-paste error

[dc42]

@resam said in One-press resume printing after power failure:

This is a step in the right direction!

As you clearly stated, this does not account for any Z movement in the command string when the print is stopped with M911.

Thinking about it some more, this means that people who can't home Z with a print on the bed should NOT perform any Z movement in the command string when the print is stopped with M911, because the G92 will not account for it, and you will end up 3mm too low (inside you print).

Since this would leave a hot hotend directly over your print, causing it to warp/melt, adding a Z-hop would still be beneficial.

@dc42 how about adding a new parameter to M911 that controls when and which G92 commands to insert. Something like:
M911 S19.8 R22.0 T0:0:2 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000"

With Tx:y:z being a single digit for each axis:

• 0: do not use G92 for this axis (there must be a G28 in resurrect-prologue.g for this axis!)
• 1: run G92for this axis with the last saved position before calling resurrect-prologue.g
• 2: run G92for this axis with the last saved position after calling resurrect-prologue.g

For my CoreXY machine, I would use T0:0:2, because I can home X and Y in the resurrect-prologue.g, but afterwards, I want to use G92 to set my Z height.
This allows people to not home at all, as well as doing a "partial" home for some axis.
Maybe this also helps people with absolute extruder coordinates, I'm not sure how this is currently handled?

Does this make sense, or am I missing anything?

There is no guarantee that the Z hop in your power fail script will be completed, because the power reserve might run out first.

[resam]

@dc42 said in One-press resume printing after power failure:

There is no guarantee that the Z hop in your power fail script will be completed, because the power reserve might run out first.

Yes - I'm fully aware of that. But I feel like taking a risk today