Tool change documentation error or bug?

deckingman

Either there is an error in the documentation or something is amiss with the firmware (RRF3.3 in my case).

The documentation indicates that none of the tool change macros will run if the axes have not been homed https://duet3d.dozuki.com/Wiki/Gcode#Section_T_Select_Tool.

However, I had "T0" (without a P0) in my config.g. My tpost files have commands to move the print head and then purge the nozzle. On booting the printer, it did not attempt to move the print head which is all fine and dandy. However, it did attempt to do the purge (which didn't go well because the hot end was cold). So tpost0.g did run albeit with the caveat that the move axes commands were suppressed. If the documentation is correct, this should not have happened because the printer had not been homed. Of course, adding "P0" to the "T0" command in config.g suppressed the running of the tool change macros, but according to the documentation, this should not have been necessary because the printer wasn't homed.

rsobik

I had the same experience a couple of weeks ago with RRF3.3. Tool changing macros were run even though the printer was not homed.

droftarts

@deckingman I think the note from point 1 also applies to point 3 and point 5, ie anywhere it checks if axes have been homed. I'll check with @dc42; the note does say "tool change files", not just "file" or "tpre#.g".

If another tool is already selected and all axes have been homed, run macro tfree#.g where # is the number of that tool. As of release 3.3, the tool change files will be actioned even if not homed, so that you can use conditional GCode to choose which commands to run.

If another tool is already selected, deselect it and set its heaters to their standby temperatures (as defined by the R parameter in the most recent G10/M568 command for that tool)

If all axes have been homed, run macro tpre#.g where # is the number of the new tool

Set the new tool to its operating temperatures specified by the S parameter in the most recent G10/M568 command for that tool

If all axes have been homed, run macro tpost#.g where # is the number of the new tool. Typically this file would contain at least a M116 command to wait for its temperatures to stabilise.

Apply any X, Y, Z offset for the new tool specified by G10/M568

Use the new tool.

ie it runs through this list, but as no tool is selected, it doesn't do point 1 or point 2. At point 3, the comment on point 1 applies, and at point 5; "As of release 3.3, the tool change files will be actioned even if not homed, so that you can use conditional GCode to choose which commands to run." So tpre0.g and tpost0.g are run. Because axes aren't homed, any axis movement is ignored (maybe with an error?) but extrusion does happen. Is cold extrusion allowed? Would it help to put 'wait for temperature' (set by point 4) in tpost0.g?

As you note, T0 P0 suppresses running of the macros completely.

Ian

PS @chrishamm confirms it's the same for all points, re 3.3 release notes:

When changing tool, tool change files are now run regardless of whether axes have been homed or not. You can use conditional GCode to choose which commands are only executed if axes have been homed.

I'll update the documentation so it is clearer.

dc42

To clarify:

Prior to release 3.3, when changing tools the tool change macro files were not run unless all axes has been homed.
From 3.3 onwards they are run even if axes have not been homed. This change was made because some users want to do homing within the tool change files under some conditions, e.g. on a machine that can't be fully homed until a tool is loaded, it may not be possible to home Z because the Z probe is attached to the tool.
You can use conditional GCode within the tool change files to skip parts of the file if axes have not been homed
The rules for extrusion in tool change files are the same as anywhere else, i.e. extrusion and retraction are allowed if a tool is selected (so not in the tpre files) and either the tool it hot enough or cold extrusion has been allowed
The other files affected by this change are pause.g and resume.g. However, these files are only run when a print is paused and resumed, so the printer would normally have been homed anyway.

deckingman

@dc42 Thanks. @droftarts Maybe a comment at the start of the notes to say that these apply to firmware prior to 3.3., and that post RRF 3.3, the macros will run even if axes have not been homed (I'm using 3.3 so that explains the behaviour I observed).