Pause and resurrect do not play nice with each other

gnydick

When the print is paused, the nozzle moves 5mm away from the print in order to not sit there and melt the print. The resurrect.g only stores instructions assuming the power failed, so it uses G92 to tell the machine where it is, THEN the pause adds the 5mm. This is the wrong scenario for a paused print. Here's an example of why...

I had a print going that I wanted to change the temperatures on without starting over, so I didn't want to re-slice it in case the offset in the newly sliced file was different, so I paused and cancelled the print, downloaded the gcode file from the printer, did a search and replace on the temps and re-uploaded it. I then resurrected the print. That immediately started printing in thin air because the pause added 5mm.

Now, I can't put that in resurrect-prologue.g because if there is a power outage, then I'll crash into the print by resurrecting.

dc42

Which firmware version are you using?

Please post your pause.g and config.g files.

gnydick

@dc42 sorry, I was wrong. I paused that print twice. It is the G92 that is wrong, I will completely repost later today with the corrected problem.

gnydick

@dc42 OK, I updated the OP here.

dc42

I don't understand how 5mm got added. The scenario that resurrect.g after pausing the print is intended to address is that you want to power the printer down because it will be unattended. So you pause the print, then turn the printer off. Later you turn it on and send M918 to resurrect the print. Therefore, the G92 commands written to resurrect.g need to set the position at which the print was paused, before the pause.g file moved the head up 5mm. This is what the code does, and it was working last time I tested it.

gnydick

@dc42 the 5mm didn't get added to the G92. I stated it incorrectly before. The problem is the pause physically moves the head 5mm away, but the G92 DOESN'T take that into account. So...

time	step	Z pos	resurrect contents
T=0	print	1.4
T=1	Pause	6.4	G92 Z1.4

From there, it doesn't work, there is nothing that moves the head 5mm back down.

dc42

OK, I see the problem. The resurrect.g file is written before pause.g is executed. When I was doing this, I was homing Z in resurrect-prologue.g, so the G92 value wasn't being used.

There isn't an easy fix for this, so I won't be able to include a fix in the 2.03 release.

gnydick

@dc42 I think there is. There can be some new features.

A flag called "destructive homing" that means that unless the user has verified that it's safe to home, don't do so. For example, if I lose power and want to resurrect, I personally can't include homing because it would crash into the print. Not only that, I'd have to manually deploy my probe.
A new g-code prefix C for config ENUMs.
A config ENUM C101: "pause Z movement." This is the distance to move when doing a pause.
The ability to reference config values in g-code. Let's say the "pausez" is C101, the center X position is C102 and the center Y position is C103. It'd be awesome to be able to have something like G1 XC102 YC103 ZC101 or G1 XCcenterX YCcenterY ZCpauseZ

With these features, you can make any number of assumptions about how to deal with things.

For example, (expanding on the idea I just proposed) there are so many macros to operate the machine and they all have hardcoded values. If all of those values, where possible, were actually config ENUMs, the machine could behave much, much more consistently and robustly. Nearly every time you've ever had to answer someone with "well, you'd have to edit it here, here, and here..." would go away.

Macros would be much easier to maintain over time. I have tons of them: diagnostics for motion smoothness, skipped steps, unjamming the extruder, moving to the center. Not to mention homeZ.g which moves to the center before probing Z. The ability to reuse that position would be so handy.

I understand for a stable, not changing machine, these features might not be all that useful, but the duet is so popular and used in so many in-development projects, that I believe this kind of functionality would to over extremely favorably with the community and make duets even more the go-to platform it already is.

My gut instinct tells me this will solve many other issues as well.

Thoughts?

dc42

Most of what you describe is encompassed by the conditional GCode syntax and associated variables that will soon be implemented in RRF 3.

gnydick

@dc42 aren't I clever