What is the problem?
I can't locate where in the start gcode the printer is being instructed to heat up. I would like to try heating up the print bed, preforming the auto-level with my BL Touch, then moving the extruder to the home position 10mm above the build plate, priming the extruder, then start printing. Currently it heats up the extruder and build plate, which causes a little oozing, that small amount of ooze balls up under the extruder, which it will then smash to the nozzle as it auto-levels the bed. Then it will go and prime the extruder, which will all then stick to the nozzle along with the rest of the initial ball of plastic. There has to be a better way to do this.
What did you already try to solve it?
Tried to modify the gcode but can't find the commands telling the printer to heat up.
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
Latest update of OctoPi.
Starting GCode:
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z20.0 F{travel_speed};move the platform down 15mm
G29
G1 X0 Y0 F3000 ; Go to home (without homing: it would disable compensation)
G92 E0 ;zero the extruded length
G1 F140 E30 ;extrude 3mm of feed stock
G1 X20 Y0 F140 E30
G92 E0 ;zero the extruded length again
G1 F{travel_speed}
;Put printing message on LCD screen
M117 Printing...
If you don't manually add a heatup command into the start GCODE configured in Cura, last I checked it will detect this and insert that stuff on its own at the beginning.
Your GCODE there contains neither of M104, M109, M140 or M190, so that's probably what's happening here. Try adding your heatup to where you want it in the start GCODE and then your slicer won't have to guess where it makes sense anymore.
Minor correction: Cura doesn't actually check for the M104 , M109 , M140 or M190, but for the strings {material_bed_temperature} and {material_print_temperature} (like that, with curly brackets and that actual text, not the numbers). So, like you put {travel_speed} there, only that should be {speed_travel}.
So, something like this should work (again, the text between the curly brackets is meant to be taken literally, Cura will do the replacement for you when writing the gcode):
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z20.0 F{speed_travel};move the platform down 15mm
G29
M190 S{material_bed_temperature}
M109 S{material_print_temperature}
G1 X0 Y0 F3000 ; Go to home (without homing: it would disable compensation)
G92 E0 ;zero the extruded length
G1 F140 E30 ;extrude 3mm of feed stock
G1 X20 Y0 F140 E30
G92 E0 ;zero the extruded length again
G1 F{speed_travel}
;Put printing message on LCD screen
M117 Printing...
(or, technically, since the infamous Cura 15.06 which we all rather forget existed)
I wish I could forget that. The frustration that release caused thanks to trying to shoot a moving target for close to a year and then finally just having to give up is something I wish I didn't have to experience
I adjusted your recommendation slightly. Here is what I am using and the first layer looks awesome.
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z20.0 F{travel_speed};move the platform down 15mm
M190 S{print_bed_temperature} ;Uncomment to add your own bed temperature line
G29 ;Preform auto-bed-level routine
M109 S{print_temperature} ;Uncomment to add your own temperature line
G1 X0 Y0 F3000 ; Go to home (without homing: it would disable compensation)
G92 E0 ;zero the extruded length
G1 F140 E30 ;extrude 3mm of feed stock
G1 X20 Y0 F140 E30
G92 E0 ;zero the extruded length again
G1 F{travel_speed}
;Put printing message on LCD screen
M117 Printing...
You are welcome, but F{travel_speed} still does not work; it gets sent to the printer as is, and your printer won't understand it. Change it to F{speed_travel}.
@fieldOfView while I have you attention, I see this mistake a lot and it's causing a ton of issues in the field - historical reasons? Prominent documentation error? Any chance to mitigate in the replacement engine?
The variable name was changed from travel_speed to speed_travel in that 15.06 rewrite (get the boxing ball ready) in an effort - I guess - to standardize on names that start with the category the setting is in. It was before my time
I'll see if a PR to accept either lands well with the UM devs, but it won't be until Cura 4.1.
