Orca Slicer Multiple Toolhead Preheat G10 S parameter - ER

dwuk3d

I recently discovered that Orca Slicer can send G10's a specified number of seconds prior to each colour change to tell the idle nozzle to kick off pre-heating.

The slight issue is that the G10's specify the preheat on the S parameter not the R parameter - which as far as I can tell doesn't get used by tools in 'standby'

I have worked around this in two ways.

For single threaded prints I have written a small gcode post processor that translates the G10's into G10.1 - so that I can then create a G10.1.g macro to take G10.1 P1 S220 for example and convert it into G10 P1 R220.
For Multiple Motion System parallel prints this is less of an issue - because both tools are active - but I have still overridden G10's to alter the S value to a lower amount, - so that I can use this to detect when preheat is triggered and use this to time when to kick off the preheat more precisely and also use it for tool changing and priming/wiping in parallel (see my SV08 upgrade thread for demo).

Ideally it would be nice if all GCODE commands could be overridden like I think they can be in Klipper - with the ability for the original command to be called somehow within the overriden version.

Failing that - for scenario 1. above it would be good if there was a way for G10 Px Sx's to somehow kick off the preheat of tools in 'standby'.

Also it would be ideal if the full text of the overridden GCODE command were made available to the override macro - , including any comments - as sometimes there is useful info in the comments - like the fact that the G10's are preheats - rather than normal heat ups.

dc42

@dwuk3d said in Orca Slicer Multiple Toolhead Preheat G10 S parameter - ER:

Ideally it would be nice if all GCODE commands could be overridden like I think they can be in Klipper - with the ability for the original command to be called somehow within the overriden version.

That could become an option in the future. It would take too long to search the SD card for a possible macro file on each command, so RRF would need to maintain a bitmap to record which commands has corresponding macro files. Due to the amount of RAM occupied by the bitmap, we wouldn't implement this on Duet 2.

Feel free to create a feature request at https://github.com/Duet3D/RepRapFirmware/issues.

dwuk3d

@dc42 Sounds great thanks.

I don't think the number of overridden GCODEs is likely ever to be a very long list - so maybe a lookup list could work too - perhaps with some sort of extra M command in the config.g or start gcode in the slicer to register the overrides.

In the meantime I think I will alter my post processor to be more generic and do more or less the same thing.
i.e. Look for some sort of override registration M command (M802 for example) in the gcode stream, and then use that info to then override any relevant G/M/T commands later in the stream into .x equivalents.