IDEX tool pre heating like M104.1

brotherchris

Hey all,

M104.1 is used in Prusa slicer to get the next tool up to temp to be ready for the tool change. This greatly increases the speed on multi tool prints. I recently built an IDEX printer with DUET 2. Does anyone know of a method to do something like this in REPRAP?

Info on the extension:
M104.1 is a PrusaSlicer extension that aims to set the temperature for the next tool to be used, potentially reducing the time needed for the hotend to reach the correct temperature during a tool change.

Thanks all,
Chris

dc42

@brotherchris I've done a search and it doesn't appear that M104.1 is documented. We can't implement something that doesn't have a specification.

RRF lets you define a standby temperature for each heater of an inactive tool, using either G10 or M568. So it may be that you could use a post processing script to replace M104.1 commands by M568 commands to adjust the standby temperature, if you can work out how the M104.1 commands are supposed to behave and what the parameters mean.

brotherchris

@dc42 Thank you, there is some mystery there, Thinking about it, I think I can write a post processing script pretty easy to increase the standby temp based on the number of lines of gcode between tool changes. I will report back and share it when I am done.

dwuk3d

I'm presuming M104.1 is a bit like the G10 preheats you can get out of OrcaSlicer (and presumably Prusaslicer) when you specify RRF and supply a pre-heat time in the OOz prevention section on the Multi Material settings.

I have found them to work fairly well - though with two issues.

The G10's generated by Orca Slicer only supply a S parameter - which for inactive tools I don't think gets used - you need I think to provide an R parameter.
- I've worked around this by using a small post processor to convert the G10 to G10.1 - and then created a G10.1.g macro that takes in the G10 from Orca Slicer and corrects it. - See https://forum.duet3d.com/post/353868
The preHeat times are mostly accurate - but sometimes they are quite late - for example when I specify 20 seconds most are in the range 19-21 seconds before the tool change - but I a seeing a few as late as 9 seconds.

If you want to use M104.1 - which I presume gets generated when you use a Prusa XL, or something like Marlin firmware - then it should be fairly easy to process it and do whatever you like with it by creating a M104.1.g macro - and then either calling M104's or G10's to do the preheat.

Also worth noting that when to kick off the preheat also depends on how long the tool has been cooling and therefore what the start temperature - as for fast changes the temp may still be higher than the idle temperature.

If you do decide to write a post processor to send the pre-heat at the right time it can get quite complicated - as working out the time that each G0-G3 command for example takes to execute is quite tricky - as you have to take into account things like accelerations, feed rates, jerk and input shaping.

Prusaslicer/OrcaSlicer seems to internally keep a table of its predicted time for each move command, and then when a tool change is encountered it back traces through the table to work out where to insert the pre-heat command.

Personally I am planning on continuing to use G10's - but I am also planning for reprints to capture actual print times for each tool change when prints are done - and then use this information to make the preheat and in my case parallel priming times extremely accurate when the same print is repeated - so that I can tool swap times down as low as technically possible.

It might also be possible to somehow use Simulate to also get accurate predicted print times out of RRF .

crpalmer

@dc42 The P and Q parameters of M104.1 appear to be time deltas (in seconds?). I'm not sure exactly what they mean but it sounds pretty hard to have a post processing script handle this gcode command. My guess at interpreting the M104.1 command is to "heat tool T to temperature S in P seconds". The firmware needs to handle this because the firmware is the definitive source of the heating model for the hotend and the only place that could practically determine when and with what curve to heat the nozzle.

This sounds like a really cool feature to have for dual extruder printers and I would be interested in potentially using it in idex scenario if it was able to quite accurately hit the temperature. It would be nice as it could potentially consume less power and would be incredibly useful if I ever printed with filament I couldn't leave idle and at printing temperature for an extended period of time.

I understand that it would be foolish to implement undocumented gcode whose meaning could change at the whim of the PrusaSlicer developers. But, if they do ever document this gcode, I think it would be an interesting feature to offer.

dwuk3d

@crpalmer

Whilst I agree that preheat at a particular time would ideally be done by the firmware, Pending any potential changes It should be possible to write a M104.1.g macro - which collects the parameters, stores the required number of seconds plus the current state.upTime - then either using daemon.g or the 2nd motion system to asynchronously wait the right amount of time, minus enough time to kick off the preheat.

In my version of this I'm just doing a simple x degrees per second formula - but it probably wouldn't be that hard to build some sort of table of heat up times to derive the correct time to kick off the preheat.