How to completely disable resume info saving?



  • If I happen to cancel a print from web interface, the next print is always ruined. Whatever I do, the firmware wants to perform parts of the previous job first, stupidly even with cold hotend if the printer had been off for a while. It then works for a while and only after that does the normal homing and starts to heat hotend and bed.

    I don't want this forced resume attempt, I want the situation after a print job cancellation be clear withouth any remains of the previous job, but how?

    Software versions: combined firmaware 2.0 and server & webcontrol both 1.21.


  • administrators

    Are you printing from SD card, or over USB, Telnet or some other way?



  • From SD, the behaviour is the same whether I use the "upload and print" or from gcode files menu in the web interface. IIRC if I upload a completely different file it it does not do the ghost movements. The worst is that during these ghost movements machine limits are not respected, and the carriage can crash into x- or y-max.



  • One more thing, while doing these ghost movements, the gcode console displays a bucketful of "Error: Attempting to extrude with no tool selected." The Gcode file itself is generated by S3D 4.0.0, and works on other printers.


  • administrators

    How are you cancelling the print: by pressing Pause then Cancel, or some other way?

    Do you have a cancel.g file, and if so, what is in it?

    I am not aware of any other reports of similar behaviour.



  • By pressing Pause, then Cancel. Cancel.g is essentially empty, it contains just stop.g, which is however commented out (all done by the configurator). I try to uncomment it and report back after having tried it. Looks very possible that the commented out call to stop.g might be the culprit. But I now have a 12 hour print running, so it will be awhile before any answers 🙂



  • Well, it was not the cancel.g (had to cut the print, there were other goofs in it so could experiment). Problem seems to be the resurrect.g that is always called in beginning of print, whatever I really want to do. Resurrect.g seems to call resurrect-prologue.g that I dont seem to even have...

    I tested ending the print with a gcode command M0, and that does not clear the ghost print happening


  • administrators

    The resurrect.g file is only called if you execute M916, or M98 Presurrect.g. You should not be doing that in your slicer start Gcode, or anywhere else except when you want to resume an interrupted print.



  • Well, nothing I do calls M916, and neither do I knowingly use M98 Presurrect.g. Neither of them are standard Gcode, so no slicer should call them anyway? There is no Presurrect.g on the SD-card.


  • administrators

    Perhaps you should post the first 100 lines or so of a GCode file that exhibits the problem.



  • Here's the start of one. Notice that the ghost printing happens with every gcode file, be it generated by S3D or Cura 3.4 if I have cancelled the previous print job.

    G90
    M82
    M106 S255
    G4 P500
    M106 S0
    M140 S60
    M190 S60
    M104 S215 T0
    M109 S215 T0
    G28 ; home all axesl
    G92 E0
    G1 Z0.1 F1000
    G1 X8.0 F2000
    G1 Y60.0 E4.0 F1000.0 ; prime
    G1 Y100.0 E8.5 F1000.0 ; prime
    G92 E0
    G92 E0
    G1 E-0.5000 F4800
    G1 Z0.100 F1002
    ; process Process1
    ; layer 1, Z = 0.100
    T0
    ; tool H0.100 W0.400
    ; skirt
    G1 X129.772 Y116.108 F7200
    G1 E0.0000 F1440
    G92 E0
    G1 X130.592 Y115.288 E0.0183 F2100
    G1 X199.408 Y115.288 E1.1055
    G1 X200.228 Y116.108 E1.1238
    G1 X200.228 Y186.734 E2.2396
    G1 X199.408 Y187.554 E2.2579
    G1 X130.592 Y187.554 E3.3451
    G1 X129.772 Y186.734 E3.3635
    G1 X129.772 Y116.308 E4.4761
    G1 X129.772 Y116.108 F2100
    G1 X130.172 Y116.274 F7200
    G92 E0
    G1 X130.758 Y115.688 E0.0131 F2100
    G1 X199.242 Y115.688 E1.0950
    G1 X199.828 Y116.274 E1.1081
    G1 X199.828 Y186.568 E2.2187
    G1 X199.242 Y187.154 E2.2318
    G1 X130.758 Y187.154 E3.3137
    G1 X130.172 Y186.568 E3.3268
    G1 X130.172 Y116.474 E4.4342
    G1 X130.172 Y116.274 F2100
    G1 X130.572 Y116.439 F7200
    G92 E0
    G1 X130.923 Y116.088 E0.0079 F2100
    G1 X199.077 Y116.088 E1.0846
    G1 X199.428 Y116.439 E1.0924
    G1 X199.428 Y186.403 E2.1977
    G1 X199.077 Y186.754 E2.2056
    G1 X130.923 Y186.754 E3.2823
    G1 X130.572 Y186.403 E3.2902
    G1 X130.572 Y116.639 E4.3923
    G1 X130.572 Y116.439 F2100
    G1 X130.972 Y116.605 F7200
    G92 E0
    G1 X131.089 Y116.488 E0.0026 F2100
    G1 X198.911 Y116.488 E1.0741
    G1 X199.028 Y116.605 E1.0767
    G1 X199.028 Y186.237 E2.1768
    G1 X198.911 Y186.354 E2.1794
    G1 X131.089 Y186.354 E3.2509
    G1 X130.972 Y186.237 E3.2535
    G1 X130.972 Y116.805 E4.3504
    G1 X130.972 Y116.605 F2100
    G92 E0
    G1 E-0.5000 F4800
    ; outer perimeter
    G1 X131.372 Y116.888 F7200
    G1 E0.0000 F4800
    G92 E0
    G1 X198.628 Y116.888 E1.0625 F1050
    G1 X198.628 Y185.954 E2.1537
    G1 X131.372 Y185.954 E3.2162
    G1 X131.372 Y117.088 E4.3042
    G1 X131.372 Y116.888 F1050
    ; inner perimeter
    G1 X131.772 Y117.288 F7200
    G92 E0
    G1 X198.228 Y117.288 E1.0499 F1575
    G1 X198.228 Y185.554 E2.1284
    G1 X131.772 Y185.554 E3.1783
    G1 X131.772 Y117.488 E4.2537
    G1 X131.772 Y117.288 F1575
    G1 X132.172 Y117.688 F7200
    G92 E0
    G1 X197.828 Y117.688 E1.0373 F1575
    G1 X197.828 Y185.154 E2.1031
    G1 X132.172 Y185.154 E3.1404
    G1 X132.172 Y117.888 E4.2031
    G1 X132.172 Y117.688 F1575
    ; solid layer
    G1 X196.950 Y118.028 F7200
    G92 E0
    G1 X197.488 Y118.566 E0.0120 F1680
    G1 X197.488 Y119.131 E0.0209
    G1 X196.385 Y118.028 E0.0456


  • administrators

    I think you may be confusing the extruder priming moves on your start Gcode with moves from the previous print. You have several heater commands and G1 E moves in your start Gcode before you select a tool with the T0 command. So the behaviour will depend on whether or not a tool is selected before you start the print. That in turn may depend on whether the previous print finished or was cancelled.



  • Nope, I know exactly how the extruder priming moves look, the ghost print is nothing to do with it. If I wait long enough the ghost moves stop, they last approximately one layer, then the head moves to around x0 - y150 and sits there for a while, then the printjob commences as it should, the printer heats up the bed and hotend, homes and starts to print, doing first the priming/nozzle wiping move along X8 first to y60 then with really fast extrusion to y100, which wipes the nozzle, after that the print moves start.


  • administrators

    Can you post a video showing this behaviour?



  • I got some light on the situation. When I cancel a printjob (with the web interface), the Gcode monitor shows "Error: Push() stack overflow! and resurrect.g remains on the SD-card's sys-folder. I can now clear the situation by just deleting this resurrect.g so whatever causes this in not a significant issue anymore

    What made the situation hard to diagnose was that other troubles were masking what really was happening, I noticed that sometimes when I transfer a gcode from PC to Duet, the beginning of the file can go missing and the gcode starts from some random place and gives an error due to incomplete command. I was puzzled by these seemingly random gcode errors, because I checked the original file on PC, not the one on printer, not suspecting a transfer error. The wifi signal is marginal at where the printer is, maybe I have to consider the Ethernet version because the whole house is cabled with Cat5e.


  • administrators

    @sikasid said in How to completely disable resume info saving?:

    What made the situation hard to diagnose was that other troubles were masking what really was happening, I noticed that sometimes when I transfer a gcode from PC to Duet, the beginning of the file can go missing and the gcode starts from some random place and gives an error due to incomplete command. I was puzzled by these seemingly random gcode errors, because I checked the original file on PC, not the one on printer, not suspecting a transfer error.

    Are you sure? The firmware verifies that the file size written matches the size of the original file, so this should be impossible.



  • I am quite sure, and it is not a single occurrence.

    Where does the firmware gets the file length? From the web interface? That might be the source of the error?


  • administrators

    @sikasid said in How to completely disable resume info saving?:

    I am quite sure, and it is not a single occurrence.

    Where does the firmware gets the file length? From the web interface? That might be the source of the error?

    Yes, the web interface sends the file length, and the firmware checks that it has written exactly that amount of data.

    Please note, with some slicers it is possible to have DWC upload the file before the slicer has finished writing it, because the slicer doesn't open the file in exclusive mode while writing it. This used to be the case with slic3r - I don't know whether it still is.


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.