Undo retraction in resurrect-prologue.g not possible in RRF 2.03
-
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.
-
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 -
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!
-
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.
-
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 -
@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.
-
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 -
@3hristian, you are quite right. Looks like i need to release 2.04RC5.
-
@3hristian , please try the 2.04RC4+1 build that I have put at https://www.dropbox.com/sh/mk3jlsoi6gyxd8q/AABbEvX2qb19McbRe6UvRmI9a?dl=0.
-
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!
-
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.
-
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 -
@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
ChristianThanks!