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)

[hestiahuang]

@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

Any good news about this feature? 4 years passed, it should be big improvement for the multiple tools change.

[jay_s_uk]

@hestiahuang it's part of the 3.5b1 release a few weeks back

[hestiahuang]

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

@hestiahuang it's part of the 3.5b1 release a few weeks back

Really? I may miss the milestone. Thank you so much!

[hestiahuang]

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

@hestiahuang it's part of the 3.5b1 release a few weeks back

Sorry, need to distube you again. I read the change log carefully, however I can't see any description about this part. Any idea about the details of this change?

https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta2-in-preparation
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta1

[Rushmere3D]

There is a 3rd party PrusaSlicer post processor for this if your interested?

[o_lampe]

@hestiahuang I proposed to establish a tahead.g macro which runs, as soon as the look ahead planner finds a toolchange.
This could probably be too late, depending on the length of look ahead.
Finding the best solution is way harder, since each line of code can take longer or shorter.
My dual extruders always run at full temperature. Even when a tool is parked. I park the nozzle over a piece of nylon to prevent oozing and purge the tool, when it's reactivated.

[jay_s_uk]

@hestiahuang its part of the multiple motion support. https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta1:~:text=[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] Multiple motion systems are supported. See https%3A//docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems. Caution%3A this feature is experimental and may not be fully working in this release.
there are now 2 gcode streams. however, how a user chooses which gcode stream is used I am unsure of