How to completely disable resume info saving?
-
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
-
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.
-
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 -
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.
-
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.
-
@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?
-
@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.