Nozzle heater behaviour in multi tool printers
-
In a multi-tool print and with my current configuration, the first tool active and standby temperature is set, the tool heats up and once at operating temperature, it begins to print. The second tool that is used gets it's active temperature set but standby temperature is set to 0. I can, in the custom g-code section tool change code, set the temperature of active and standby temperatures but the tool does not start to heat up (from ambient) until the tool change happens.
Is there any way of bringing all tools to be used in a given print job to their standby temperatures at the beginning of the print so that the wait time for tool heat-up is reduced? If the first tool is going to be printing for an hour before the tool change happens, is there a way of only starting the heat up cycle a few minutes before the tool is used? The idea being that warm up time is reduced but the tool doesn't sit at standby temperature for a long time.
Using PrusaSlicer 2.6, is the normal way to set up standby temperature by setting the temperature delta in the ooze prevention section or is there an alternate method? -
@jens55 At first glance, my thoughts would be to simply set the standby temperature to around 140 Deg C or somewhere around the glass transition temperature for your filament(s). Do that for all tools at the start of a print. The time it takes to get to the active temperature will be much reduced than from a standby temperature of ambient and holding unused tools at around the gt temperature won't cause any oozing issues.
-
@deckingman, so are you saying that short of some fancy macro programming, there is no way to start to heat up hot ends closer to when they will be used? How do you determine which hot ends will be used in a print? Different filaments have different temperature ranges - how do you set temperatures that are appropriate short of manually doing whatever for every print?
-
@jens55 Pretty much the only way of starting heating some time prior to a tool being selected is to insert the heating command into the gcode file and pretty much the only way to do that is to post process the sliced gcode. There is no way that the firmware could predict when the next tool might be used, because that will be different for every gcode file.
As for your other questions, well you are going to have to decide which filaments you are going to use when you slice the object. The slicer will then put the appropriate Tn commands in the gcode file. The tool change macros will then take care of changing from active to standby temperatures. You'll have to decide what active and standby temperatures to use for each filament and set them for each tool in the slicer start code. If you always use the same filaments for each tool, then you could wrap the active and standby temperature commands in a macro.
-
@deckingman, thanks for your input. I had hoped there would be a way but I guess we are not there yet. A slicer should easily be able to say that at such and such a layer to go ahead and start warming up the next tool. Ideally the slicer would also know how long down the line the current tool will be re-used and if it is more than say 5 minutes it should be smart enough to turn the heater off or go to an even lower temperature setting. I guess we will have to wait until this sort of look-ahead feature makes it into the slicers.
-
@jens55 Yes, I think it needs to be done in the slicer somehow, or a post process script.
With mixing hot ends, one can use the new filament to purge out the old. So when changing from one colour to another, I used to advance the tool change command within the gcode file so it actually changed tools "n" mm of filament before it would otherwise do. This meant that I could actually print multi-colour objects without using any sort of purge tower. To accomplish that, I had to write a little python script which would read through the gcode file, find the tool change commands, go back through the file and calculate the new position by summing the "E" values backwards from the original tool change point, then delete the tool change commands and re-insert them at the new points. But it gets complicated because the new change point might be inside a long XY move so I also has to segment such moves into two parts.
One would need to do something similar in order to pre-heat a tool by changing it's standby temperature at some point in time before it becomes active. That point in time might well be part way through a long G1 move so it would have to be segmented in order to insert the new standby temperature command.
There was some talk at one point about the firmware being able to run two or more parallel gcode streams but I don't know what the status of that is. That would be handy for such situations. One stream could contain just the G1 moves, the other could contain the tool heating/change commands.
