Undo retraction in resurrect-prologue.g not possible in RRF 2.03

3hristian

Hi,

I am running RRF 2.03 on a Duet 2 Ethernet (v1.04). I have a self-built machine with 2 extruders and a problem when recovering from a controlled shutdown.

With the current firmware it seems not to be possible to undo a retraction that was made during shutdown with the "resurrect-prologue.g" makro, as mentioned in the wiki (https://duet3d.dozuki.com/Wiki/Setting_up_to_resume_a_print_after_a_power_failure) :
"If your power fail procedure in the M911 command retracts filament and your printer has a single nozzle, you may wish to undo the retraction."

In my case I want to undo the retraction from a controlled shutdown, so M911 was not called. But that should make no difference.

The reason I can't undo the retraction is, that I can't perform a retraction in resurrect-prologue.g when no tool is selected (or heated). Because in the current firmware the sequence of the commands in resurrect.g have changed. As mentioned in the changelog for RepRapFirmware 2.03 (released 13 Jun): https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md
The relevant bulletpoint is:

In resurrect.g, the current tool is now selected after running resurrect-prologue, and its tpre and tpost files are run (for tool changer)

Just for clarification. This is the resurrect.g file that is generated by my printer:

; File "0:/gcodes/interrupted_print.gcode" resume print after print paused at 2019-10-03 22:23
G21
M141 P0 S0.0
G29 S1
T-1 P0
G92 X76.986 Y100.320 Z3.100
G60 S1
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
G10 P1 S200 R0
G10 P0 S215 R215
T0 P6
M106 S0.00
M106 P2 S0.00
M106 P3 S0.00
M106 P4 S0.00
M106 P5 S0.00
M106 P6 S0.00
M106 P7 S0.00
M106 P8 S0.00
M116
G92 E0.00000
M83
M23 "0:/gcodes/interrupted_print.gcode"
M26 S2285966 P0.000
G0 F6000 Z5.100
G0 F6000 X76.986 Y100.320
G0 F6000 Z3.100
G1 F2133.3 P0
G21
M24

As you can see the used tool is selected and heated after resurrect-prologue.g was called.

Now my question / bug report / wish for the next release:
Is there a way to work around that issue? Is there a way to select the right tool (of the interrupted print), set the right temperatures (for the interrupted print) and undo the retraction before resuming the print?

Thanks a lot and best regards
Christian

dc42

Release 2.04RC3 which is in preparation selects the active tool before calling resurrect-prologue.g. This will allow extrusion in resurrect-prologue.g.

Workaround for RRF 2.03 and 2.04RC1 if you have only one tool, called T0: put T0 followed by M116 at the start of resurrect-prologue.g.

3hristian

Thanks for the response!
Hopefully also the temperatures for at least the active tool will be selected before resurrect-prologue.g is called?

If that is the case all I have to do is to wait for RRF 2.04 RC3 and thank you very much! If that is not the case I would wish for that or an option to access the last active temperature that was used for the active tool before the build job was interrupted.

Thanks a lot for the support and the great products you are developing together with the community.

Best regards
Christian

3hristian

Hi again,

I just updated to RRF 2.04 RC3 and tested the new behavior. Unfortunately it's still not possible to undo a retraction in a way you should do it. The problem is (as I guessed in my previous post), that the temperatures of the interrupted build job are not restored. So you can't handle the extruder in a proper way in the resurrect-prologue.g file because you don't know the correct temperatures. So the new behavior doesn't help e.g. if you have a machine that is capable of handling different materials.

Here is a code example of the resurrect.g file that is generated by my printer (with RRF 2.04 RC3):

; File "0:/gcodes/interruptRRF2.04RC3.gcode" resume print after print paused at 2019-10-09 16:27
G21
M141 P0 S0.0
G29 S1
T-1 P0
G92 X87.900 Y117.723 Z0.300
G60 S1
T0 P0
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
G10 P1 S200 R0
G10 P0 S220 R220
T0 P6
M106 S0.00
M106 P2 S0.00
M106 P3 S0.00
M106 P4 S0.00
M106 P5 S0.00
M106 P6 S0.00
M106 P7 S0.00
M106 P8 S0.00
M116
G92 E0.00000
M83
M23 "0:/gcodes/interruptRRF2.04RC3.gcode"
M26 S20136 P0.000
G0 F6000 Z2.300
G0 F6000 X87.900 Y117.723
G0 F6000 Z0.300
G1 F4800.0 P0
G21
M24

So why don't you restore the temperatures before resurrect-prologue.g is called?
Is there a way to get the temperatures of the interrupted build job to handle the extruder in resurrect-prologue.g?

Thanks again in advance!

dc42

Thanks for your clear description of the problem. I know it used to set the tool temperatures before it called resurrect-prologue.g. I'll need to look back at the github logs to see why that was changed. Probably something to do with tool changers. My guess is that it's because homing needs to be done before the T0 P6 command can be safely executed. I'll fix in in the next RC, which I will try to produce within a few days.

3hristian

Hi again,

I just tested the RRF 2.04 RC4 according to the problem I explained above. Unfortunately the new behaviour is still faulty: Now the temperatures are restored (as they should be) but the tool that was active at the print-interruption is not selected (as in RRF 2.03).

So this is the resurrect.g file that is generated by my printer (with RRF 2.04 RC4):

; File "0:/gcodes/interruptRRF2.04RC4.gcode" resume print after print paused at 2019-10-20 21:12
G21
M141 P0 S0.0
G29 S1
T-1 P0
G92 X183.690 Y105.250 Z6.300
G60 S1
G10 P1 S200 R0
G10 P0 S210 R220
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
T-1 P0
T0 P6
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
M106 S0.00
M106 P2 S0.00
M106 P3 S0.00
M106 P4 S0.00
M106 P5 S0.00
M106 P6 S0.00
M106 P7 S0.00
M106 P8 S0.00
M116
G92 E0.00000
M83
M23 "0:/gcodes/interruptRRF2.04RC4.gcode"
M26 S39166 P0.000
G0 F6000 Z8.300
G0 F6000 X183.690 Y105.250
G0 F6000 Z6.300
G1 F600.0 P0
G21
M24

As you can see there is no tool selected before calling resurrect-prologue.g.
The problem with this behaviour is that you have to guess which tool was active during the job interruption. In my example Tool 0 was active during the iterruption (you can see it at the temperatures):

G10 P1 S200 R0
G10 P0 S210 R220

So in my example the generated code of resurrect.g should look like this:

[...]
G10 P1 S200 R0
G10 P0 S210 R220

T0 P0

M98 P"resurrect-prologue.g"
M116
[...]

Of couse this is only a problem when your printer has multiple tools, but because that is one of the strengths of the Duet3d /RRF combination it would be great to solve this (minor) issue. Or is there something I am missing?

Best regards
Christian

dc42

@3hristian, I tested the behaviour twice by turning the printer off during a print, turning it on again, reviewing the resurrect.g file, and sending M918 to restart the print without changing the file. In both cases the tool was selected in resurrect.g. So I think that you may have produced that resurrect.g file by pausing or turning off the printer while no tool was selected.

3hristian

Hi dc42,

thanks for the response and the work you put in the conversation to the community and also this issue!

To make sure I have not messed up something during my test I tested the behavior again (also two times) and also checked that the tool (T0) was selected during some steps of the test. But the generated resurrect.g file stays the same and the tool selection in front of calling the resurrect-prologue.g is still missing.

But my test scenario was a little bit different to yours. That is the case because I personally want to use the resurrect function for controlled shutdowns so that I don't have to leave the printer unattended during printing (for safety reasons).

My test scenario was:

Starting a print
Wait for a few strand depositions
Pressing pause (on the paneldue) - (I checked: T0 is still selected as indicated on the paneldue and in DWC)

My pause.g file is the following (but should not matter because I don't deselect the tool):

G91         
M83           	 	
G1 Z3 E-5 F3000 	
G90            		
M98 Pmovetopurge.g
G91            		
G1 Z-3 F360     	
G90

My movetopurge.g file is the following (for the sake of completeness):

G1 X220 Y240 F15000
G1 X240 Y240 F15000	
G1 X240 Y260 F15000 
G1 X220 Y260 F15000

Pressing cancel (my cancel.g file is empty) - (I checked: T0 is still selected as indicated on the paneldue and in DWC)
Turn the printer off / pull the mains plug
Wait for about 10 seconds
Plug in the mains plug / turn the printer on
Open the resurrect.g file over Duet Web Control 2.0.2

So maybe the function / behaviour doesn't work for a controlled shutdown (at the moment)? Maybe you can test my procedure on your machine?

Best regards
Christian

dc42

@3hristian, you are quite right. Looks like i need to release 2.04RC5.

dc42

@3hristian , please try the 2.04RC4+1 build that I have put at https://www.dropbox.com/sh/mk3jlsoi6gyxd8q/AABbEvX2qb19McbRe6UvRmI9a?dl=0.

3hristian

Hi dc42,

I just tested the 2.04RC4+1 build from your dropbox. Now it seems to work as it should work. The same test procedure (of my previous post) now produces the following resurrect.g file:

; File "0:/gcodes/interruptRRF2.04RC4+1.gcode" resume print after print paused at 2019-10-21 21:05
G21
M141 P0 S0.0
G29 S1
T-1 P0
G92 X71.344 Y104.773 Z0.300
G60 S1
G10 P1 S200 R0
G10 P0 S225 R225
T0 P0
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
T-1 P0
T0 P6
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
M106 S0.00
M106 P2 S0.00
M106 P3 S0.00
M106 P4 S0.00
M106 P5 S0.00
M106 P6 S0.00
M106 P7 S0.00
M106 P8 S0.00
M116
G92 E0.00000
M83
M23 "0:/gcodes/interruptRRF2.04RC4+1.gcode"
M26 S11594 P0.000
G0 F6000 Z2.300
G0 F6000 X71.344 Y104.773
G0 F6000 Z0.300
G1 F3200.0 P0
G21
M24

During the next days/weeks I will test the behaviour in different situations (e. g. with T1 selected instead of T0 during pausing). I will inform you if I notice a strange behaviour.

Thanks a lot and have a nice evening!

dc42

Thanks, please keep me informed. If I don't get any other bug reports for 2.04RC4 then I'll turn that 2.04RC4+1 into 2.04 final release.

3hristian

I have tested the resurrect behaviour in different situations now (with different tools selected and with different temperatures): Everything works as expected now.

Best regards
Christian

dc42

@3hristian said in Undo retraction in resurrect-prologue.g not possible in RRF 2.03:

I have tested the resurrect behaviour in different situations now (with different tools selcted and with different temperatures): Everything works as expected now.

Best regards
Christian

Thanks!