My pre-print GCode is retracting instead of extruding before each print. I have Octoprint run a short homing script before Cura takes over, heating the hotend/bed and then purging the extruder. I'm not great with GCode (so I think I've just made a beginner's error), but I've tried reversing some of the extrusion values just as a test, but it doesn't seem to make a difference.
Octoprint pre-print script
M117 Homing axes
G28 ; Home x, y, and z
G0 X0.0 Y0.0 F10000 ; jack up the speed
G0 Z-0.17 F1000; Set Z offset
G92 Z0 ; Save Z offset
G0 Z2.0 F1000; Move up a bit
Cura pre-print script
; Ender 3 Custom Start G-code
M117 Heating
M140 S{material_bed_temperature_layer_0} ; start preheating the bed
M104 S{material_print_temperature_layer_0} T0 ; start preheating hotend
G0 X0.1 Y20 Z4.0 F5000.0; Move to start position
M190 S{material_bed_temperature_layer_0} ; heat to Cura Bed setting
M109 S{material_print_temperature_layer_0} T0 ; heat to Cura Hotend
M117 Purging extruder
G1 X0.1 Y200.0 Z0.3 F1500.0 E30 ; Draw the first line
G1 X0.4 Y200.0 Z0.3 F5000.0 ; Move to side a little
G1 X0.4 Y20 Z0.3 F1500.0 E30 ; Draw the second line
M117 Printing
What did you already try to solve it?
I've tried reversing the E values on the Cura purging script, but I think something is being wonky with how Cura is exporting (this might be a question for a different forum).
Complete Logs
This is the Octoprint terminal output for the section in question
I don't really understand the N9 M104 S{material_print_temperature_layer_0} ?T0100* line, but I assume Cura should have exported the raw value there, as I don't think OctoPi can interpret it?
Send: N7 M117 Heating*91
Recv: ok
Send: N8 M140 S{material_bed_temperature_layer_0}*12
Recv: ok
Send: N9 M104 S{material_print_temperature_layer_0} ?T0*100
Recv: ok
Send: N10 M190 S{material_bed_temperature_layer_0}*56
Recv: ok
Send: N11 M109 S{material_print_temperature_layer_0} ?T0*80
Recv: ok
Send: N12 M117 Preparing extruder*78
Recv: ok
Send: N13 G1 Z2.0 F3000*41
Recv: ok
Send: N14 G1 X0.1 Y20 Z0.3 F5000.0*27
Recv: ok
Send: N15 G1 X0.1 Y200.0 Z0.3 F1500.0 E30*83
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: ok
Send: N16 G1 X0.4 Y200.0 Z0.3 F5000.0*50
Recv: ok
Send: N17 G1 X0.4 Y20 Z0.3 F1500.0 E30*122
Recv: ok
Send: N18 M117 Printing*12
Additional information about your setup
Running Octoprint 1.4.0 on an Ender 3 Pro with a BLTouch and the latest firmware provided by Creality. I realize I should probably upgrade the firmware by myself, but until tonight it was working fine.
Actually Cura should fill in the placeholder ( material_bed_temperature_layer_0) with real values.
So is the Cura pre-print script in Cura or in OctoPrint?
Filament retracting when you think it should be extruding is a classic sign of a relative / absolute extruder setting (M83 / M82) mismatch.
Same thing can happen with absolute / relative (G90, G91) positioning.
When you write scripts, you need to know the absolute / relative state of both extrusion and position. Unfortunately, there's not a "save current state" command so you have to know how the slicer is configured.
Placeholders are a different issue and again, you have to know what your slicer supports and when scripts are interpreted, who is doing the interpreting (slicer or OctoPrint).
This looks to be my problem too. When I turn the printer on, the first print works fine but on subsequent prints the bed levelling runs, the head X/Y homes and then the extruder goes into reverse and all the filament gets pulled out.
The gcode that causes this is G1 Z2.0 F3000*46
How can I tell which mode the printer is in (absolute or relative) and what can I set to make sure it stays in the right mode?
I manually sent the commands from the gcode using the terminal send in OctoPrint and the same thing happened. First print using standard OctoPrint print function worked fine and the second print ran through the homing and ABL process, homed X and Y, got the head up to temperature and then retracted the filament.
I tried it from the SD card and got the same results, albeit with the Pi connected to the USB, but I am leaning towards Firmware or my gcode
G1 X0.1 Y200.0 Z0.3 F1500.0 E15 ; Draw the first line
The E15 on this line can be interpreted by the firmware in two ways. With M82 (E Absolute), it means move the filament to the position 15mm after the zero location. With M83 (E Relative), it means extract 15mm of filament over the distance traveled. This assumes, of course, that a G21 (millimeter units) has been issued. If a G20 (inch units) is in effect, change "mm" to "in".
Bottom line is that extracting one line out of a gcode file doesn't tell the whole story. We need to see the entire gcode file. The most important parts are the start gcode and the end gcode.
I'm going to guess that the end gcode in your slicer changes M82/M83 and the start gcode does not set M82/M83. This would explain the symptoms you are seeing. Different slicers have different defaults for (and an option to change) relative or absolute E. Very few slicers default to relative XYZ but will switch to relative when necessary.
The start gcode (after ; Ender 3 Custom Start G-code) assumes that E is zero. This may be true when you first turn the printer on, but at the end of this print, E is around 378. Sending this print again will probably cause a massive retraction of around 363mm.
I believe the "fix" is to move one of the G92 E0 commands before the ;Draw the first line command. I also believe there are a couple of redundant G92 E0 commands which could be removed.
Thanks, I had a hunch this might have been the case so I have just been testing this after I uploaded the gcode. It seems to fix the problem, third print running now and it has worked fine.
Thank you for this. I inserted G92 E0 after bed leveling and heat up and everything works as it should. The only solution I had before was to squeeze the lever to keep the filament in the hot end while this unnecessary retraction was happening
