Hi There,
if i try to add my start/stop GCode from Cura to Octopi and delete the Start/Stop GCodes from Cura it doesn't use the Start GCode of octopi. Do i have to activate it somewhere or is it a bug?
What are you trying to accomplish? What makes you say "it" doesn't use the Start GCode of octopi? (btw: you mean OctoPrint)
If you do not have a start gcode in Cura, Cura will still add some gcode of its own to protect your printer from trying to extrude cold material (without preheating). If you want to prevent that from happening, you could add this stub gcode that fools Cura into thinking that you are at least preheating the printer:
; {material_print_temperature} {material_bed_temperature}
Use the snippet as is, with the ; and the {} brackets and this exact text. That will add a comment to your gcode which includes the extruder and bed temperatures in Cura and will prevent Cura from adding a preheating procedure to the gcode.
i use octopi with our ultimaker 2+ extended. with the following gcode in Cure it feels like the normal ultimaker start. If i delete the Start GCode in Cura and enter it in Octopi it doesn't pre print the material, didnt bring the heatbed to the extruder and just start printing from the homing position.
Why does the Start GCode works if i enter it in cura and doesn't work from octopi?
Btw. We have about 10 users, whitch use the ultimaker and it would be easyer to put the right start gcode in octopi than putting it in every ones cura.
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
G0 X20 Y20 F{travel_speed} ;bring extruder to the front
G1 Z25.0 F{travel_speed} ;move the platform down 25mm
G92 E0 ;zero the extruded length
G1 F200 E25 ;extrude 25mm of feed stock
G92 E0 ;zero the extruded length again
G1 F{travel_speed}
;Put printing message on LCD screen
M117 Printing...
This begs the question: what is wrong with the default start gcode in Cura?
I think the starting gcode snippet in OctoPrint is only used when you slice on the OctoPrint instance (ie: send the STL to OctoPrint instead of Gcode), but I am not sure of that.
nothing is wrong with the default but our users know how ultimaker starts by default and prefere this way
slicing with octopi doesn't work at the moment getting errors if i want to slice an stl via octopi
I think these are problems for next week 
I'd like the same startup gcode for bed leveling and warmup to be used for any slicer rather than having to maintain multiple printer profiles in each slicer. Other than bed and nozzle temps, my startup gcode is identical between all of my printer profiles across 4 slicers, and keeping them all in sync is annoying and error-prone.
Nope, it is executed before every print. However it cannot do replacements for stuff like {travel_speed} and that's probably going to be different for every slicing profile anyhow.
It is helpful for things like "move print head to some position first" or "print something to the LCD", but anything the influences print parameters really should stay in the slicer profile where it belongs.
First of all, as already said, OctoPrint, not OctoPi.
Secondly, it would help a lot if you shared some logs with us, first and foremost a serial.log from when you start such a print where it "doesn't work", and also make sure that you actually hit Save after modifying the GCODE scripts in OctoPrint. With the amount of information you've given so far it's almost impossible to say what is going on here. What I can tell you is that on my end GCODE scripts work just as they should.
2 Likes
I stand corrected...