Leave [first_layer_temperature_1] at 0 for single-extruder prints #1899

whosawhatsis opened this Issue Apr 2, 2014 · 9 comments


None yet

3 participants


I'm trying to set up a start.gcode using the temperatures placeholders instead of letting Slic3r decide where to put the heatup commands. The problem is that I can't see any way (short of using separate printer configs for single/dual extrusion, or using a dummy filament profile with temperatures of zero) to leave the second extruder cold when doing a single-extruder print on a dual-extruder machine. Is there a trick I'm missing? If not, the behavior should be changed to just leave the temperatures for all unused extruders at 0.


Same here, but as I am priming both extruders at the beginning of the print via start.gcode, leaving one extruder temperature at 0 would lead to cold extrusion for me with single extruder prints..

Didn't find a better solution yet than just always priming both extruders. I'm priming the second extruder first and turn it off after that, priming the first extruder then and leave it hot for printing. But the ability to just skip part of the start.gcode in case one extruder won't be used during a whole print would be much more appreciated.

There could be some custom gcode for every configured extruder, maybe. Call it an individual "extruder initialising gcode" for every extruder. Just a quick idea, didn't think much about how complicated that would be in combination with start.gcode. These initialising gcode blocks could be executed right after the usual start.gcode - but only for those extruders that will we used during a print.

Would make things complicated if one intends to usually do more general custom movements after extruder priming/initialising independent of how many and which extruders are used... Maybe split the current start.gcode in two parts like "start-1.gcode" and "start-2.gcode" (or "pre-extruder-init-start-gcode" and "post-extruder-init-start-gcode"...) and execute the custom extruder gcode blocks of those extruders used during print in between?

We could then do all the general initialising at the very beginning with start-1.gocde, having the necessary extruders individually primed and pre-heated next, doing further movements/settings with start-2.gcode and start the print after that.

alexrj commented Apr 3, 2014

Hi @whosawhatsis, are you using 1.1.0 (master) or 1.0.0 (stable)? Master should actually just skip any temperature command for unused extruders...


I'm using 1.1.0.

alexrj commented Apr 6, 2014

@whosawhatsis, I pushed some fixes about that. If you run from sources, can you confirm it works as expected now?

@alexrj alexrj added this to the 1.1.1 milestone Apr 6, 2014

@alexrj I haven't had much luck getting the source to compile in the past, but maybe I can try again tomorrow. Is there any trick to producing an OS X application package for Slic3r?


Works fine with 1.1.1-dev, unused extruders are set to 0 instead of my specified temperature during my priming sequence. Looks like our printers don't mind about the forced "cold extrusion" during priming. Eventually performed extrusion moves get caught by the firmware's "prevent cold extrusion" feature without effect on the following print, so I think this solution works fine for me!

@alexrj alexrj modified the milestone: 1.1.2, 1.1.1 Apr 22, 2014
alexrj commented Apr 22, 2014

@whosawhatsis, I just released 1.1.1, can you check with that one? Thank you :)


My first attempt, it seemed to be using a default start code instead of my custom one. Switched profiles around and now it's catching the custom code, but it's not replacing [first_layer_temperature_1], so I get this on both single- and dual-extruder prints:

M104 S[first_layer_temperature_1]

@alexrj alexrj added a commit that referenced this issue Apr 29, 2014
@alexrj Fixed regression and ambiguity about multiple-value placeholders like…
… [first_layer_temperature_1]. Includes several unit tests covering regression. #1899
alexrj commented Apr 29, 2014

Fixed with regression test.

@alexrj alexrj closed this Apr 29, 2014
@alexrj alexrj added the Fixed label Apr 29, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment