New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
whosawhatsis opened this Issue Apr 2, 2014 · 9 comments

Comments

Projects
None yet
3 participants
@whosawhatsis

whosawhatsis commented Apr 2, 2014

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.

@jonaskuehling

This comment has been minimized.

Show comment
Hide comment
@jonaskuehling

jonaskuehling Apr 3, 2014

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.

jonaskuehling commented Apr 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Apr 3, 2014

Member

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...

Member

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...

@whosawhatsis

This comment has been minimized.

Show comment
Hide comment
@whosawhatsis

whosawhatsis Apr 4, 2014

I'm using 1.1.0.

whosawhatsis commented Apr 4, 2014

I'm using 1.1.0.

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Apr 6, 2014

Member

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

Member

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?

@whosawhatsis

This comment has been minimized.

Show comment
Hide comment
@whosawhatsis

whosawhatsis Apr 7, 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?

whosawhatsis commented Apr 7, 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?

@jonaskuehling

This comment has been minimized.

Show comment
Hide comment
@jonaskuehling

jonaskuehling Apr 7, 2014

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!

jonaskuehling commented Apr 7, 2014

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 milestones: 1.1.2, 1.1.1 Apr 22, 2014

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Apr 22, 2014

Member

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

Member

alexrj commented Apr 22, 2014

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

@whosawhatsis

This comment has been minimized.

Show comment
Hide comment
@whosawhatsis

whosawhatsis Apr 22, 2014

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]

whosawhatsis commented Apr 22, 2014

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 added a commit that referenced this issue Apr 29, 2014

Fixed regression and ambiguity about multiple-value placeholders like…
… [first_layer_temperature_1]. Includes several unit tests covering regression. #1899
@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Apr 29, 2014

Member

Fixed with regression test.

Member

alexrj commented Apr 29, 2014

Fixed with regression test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment