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



  • 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


  • administrators

    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!


  • administrators

    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


  • administrators

    @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:

    1. Starting a print
    2. Wait for a few strand depositions
    3. 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 
    
    1. Pressing cancel (my cancel.g file is empty) - (I checked: T0 is still selected as indicated on the paneldue and in DWC)
    2. Turn the printer off / pull the mains plug
    3. Wait for about 10 seconds
    4. Plug in the mains plug / turn the printer on
    5. 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


  • administrators

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


  • administrators

    @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!


  • administrators

    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


  • administrators

    @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!


Log in to reply