Toolhead preheat prior to a tool change.

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

o_lampe

@jay_s_uk I guess these links won't work

jay_s_uk

@o_lampe works fine here (using googles copy link to highlight function)

o_lampe

@jay_s_uk You've posted one link, but it contains two http....addresses?

jay_s_uk

@o_lampe click it and see.....

o_lampe

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

there are now 2 gcode streams. however, how a user chooses which gcode stream is used I am unsure of

What I'm gathering from it is:

you slice two different parts (located at different places on the bed)
each part has it's own gcode file
In their start code you specify the tool number with M596 (both files will have X,Y and E components, but we don't need postprocessing to rename XY axes)

What I don't get is, how it will handle layer changes
And it doesn't preheat a tool, since both tools are working

hestiahuang

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

@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

Great to hear that, even it is for Duet3 6HC. Thanks a lot!

hestiahuang

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

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

Any link about your tahead.g? Oh... I think I can check your post history and locate it. Thanks!

dwuk3d

Just came across this old thread, and some of the thoughts in it are relevant to some work I am currently doing.

A few years ago when I was using a Marlin based IDEX machine with a fairly slow heating element I did write a gcode post processor that parsed the gcode and inserted pre-heat commands into the gcode stream approximately the right number of instructions ahead to take into account the likely execution time of the individual gcode instructions, plus the amount of heating time required based on approximate heat up rate, plus previous cool down rate.

I don't think the multiple motion systems enhancements really help with this so I am embarking on looking at preheating again based on a multiple motion systems/multiple idex/tool changer system I am working on:

Things that need to be considered are:

The faster heat up times of more modern extruders meaning timings need to be fairly accurate - or maybe they are fast enough to largely negate the benefits of preheating.
Gcode queuing/multiple queues means that working out where in the gcode stream to place the preheat instructions is fairly complicated.
Working out how long each move/extrude is actually going to take it quite tricky too given acceleration/slow downs both prior and after each instruction.

I guess ideally the slicer and firmware would handle this, but in the meantime
I'm thinking maybe some global variables indicating future preheat timings, and use of daemon.g might end up being part of the solution.