Toolhead preheat prior to a tool change.

thomaspj

I was hoping for some sort of look ahead function during printing that will set the standby temperature to active on an inactive toolhead 'x' number of gcode lines ahead of the tool change 'T#' so as to cut down on print times waiting on the hotend to re heat during tool changes.

dc42

We plan to implement this on Duet 3, by having 2 readers reading the same GCode file. Reader #1 will do the printing, while reader #2 will run in simulation mode and stay ahead, so that it can tell #1 in advance that a tool heater should be switched to active temperature, or (for a mixing extruder) that the mix should be changed.

On Duet 2 there probably isn't enough RAM to do this easily, because of the additional DDAs needed to run a simulation in parallel with a real print.

Cura has a facility to advance tool heating and I believe some users have it working with Duets

fma

Why not just implement a pre-processor, more or less like the simulator, to add the heating G-Code lines? This is something one can do using a Python or Perl script, before sending the G-Code to the Duet, but it should not be difficult to implement it on the Duet itself, and should not need much RAM...

dc42

@fma said in Toolhead preheat prior to a tool change.:

Why not just implement a pre-processor, more or less like the simulator, to add the heating G-Code lines? This is something one can do using a Python or Perl script, before sending the G-Code to the Duet, but it should not be difficult to implement it on the Duet itself, and should not need much RAM...

To handle forseeable cases such as needing to advance tool heating by 20 seconds when drawing curved perimeters that take 0.1 seconds per segment of the curve, you would need to buffer up to about 200 moves. That would need too much RAM to do it on the Duet.

fma

Sorry, I was not clear: I was thinking the pre-processor to really pre-process the file, and add some lines to it (on the SD card) without printing. Then, just run the new file as usual...

dragonn

Maybe it would be possible to write a simulator for DuetWebControl so it runs in a browser. This way you could prepare the g-code at upload time by using the computer resources

deckingman

@fma said in Toolhead preheat prior to a tool change.:

Sorry, I was not clear: I was thinking the pre-processor to really pre-process the file, and add some lines to it (on the SD card) without printing. Then, just run the new file as usual...

That would do - I guess you are thinking of much the same way as I advance the tool change point in the gcode file for colour changes. As you say, a Python script or some such.

TechNi

@dc42 said in Toolhead preheat prior to a tool change.:

We plan to implement this on Duet 3, by having 2 readers reading the same GCode file. Reader #1 will do the printing, while reader #2 will run in simulation mode and stay ahead, so that it can tell #1 in advance that a tool heater should be switched to active temperature, or (for a mixing extruder) that the mix should be changed.
On Duet 2 there probably isn't enough RAM to do this easily, because of the additional DDAs needed to run a simulation in parallel with a real print.
Cura has a facility to advance tool heating and I believe some users have it working with Duets

@dc42 Sorry for necroing this thread but was this ever implemented? This would actually be useful since some slicers (like PrusaSlicer) don't pre-heat tools before a toolchange happens.

dc42

@techni it's still on the firmware wish list.

o_lampe

@dc42 I'm glad this old thread popped up. Now I know what you're planning with the multi gcode stream.
My hashPrinter will take a while before it could benefit from "printing with two heads" simultaneously.
But I'd like to know, if that's also possible then?

dc42

@o_lampe yes the intention is to allow printing multiple streams in parallel, with the GCode commands for both streams in the same file, more or less interleaved, and a facility to synchronise the two streams at various points in the file.

deckingman

@dc42 said in Toolhead preheat prior to a tool change.:

@o_lampe yes the intention is to allow printing multiple streams in parallel, with the GCode commands for both streams in the same file, more or less interleaved, and a facility to synchronise the two streams at various points in the file.

David,
Would this be a mechanism for advancing the tool change point within a file? I don't know if you recall but we've talked about this in the past. It's a useful way to reduce or even eliminate the need for purging when changing between colours with a mixing hot end. I currently use a post process python script to achieve this but that's a bit of a pain. The ability to "tune" the tool change positional offset "on the fly" would be awesome.

EDIT. The ability to have "Tn" acted on within a move would be even more awesome. Currently, my post processing scrip has to segment existing G1 moves in order to get the Tn where it needs to go.

o_lampe

@dc42 said in Toolhead preheat prior to a tool change.:

@o_lampe yes the intention is to allow printing multiple streams in parallel, with the GCode commands for both streams in the same file, more or less interleaved, and a facility to synchronise the two streams at various points in the file.

That's really great news and motivates me even more to get it finished.
Can I assume there is a solution for multiple (mini) Z-axis in the pipeline, too? Printing with mesh leveling and two or more tools involved wouldn't work convenient without it.

My proposal was to use mini Z-axis on each toolholder and apply mesh leveling and Z-hop to them when no Z-value is in the gcode line.
When there's a Z-value in the gcode, it's a layer change and will move the main Z-steppers.
My favourite mini z-axis would be a small geared DC motor with leadscrew and quadrature encoder, but I could live with a light stepper motor and excenter, too.
Maybe it needs a new toolboard, which can drive two motors? (direct drive extruder and mini-Z)