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.
