manual/Tuning/Tool_changing

luca Massimiliano

Re: re-naming tool change macros
HI, READING the page https://docs.duet3d.com/en/User_manual/Tuning/Tool_changing#tool-change-macros, I would like some help, where the macros should be saved tfreeN.g tpreN.g tpostN.g AND ON G CODE OF THE SLICER DO I NEED TO INSERT ANY COMMANDS?. THANK YOU

droftarts

@luca-Massimiliano the tool change macros tfreeN.g tpreN.g and tpostN.g should be in the /sys folder. This information is missing on that page, I'll add it, thanks.

The slicer needs to send T commands to change tool, eg T0, T1, T2, then the tool change macros are run from the Duet.

Ian

stuartofmt

@droftarts @luca-Massimiliano

If you are using a common (i.e. same for each tool) BLTouch or similar: it might be worth checking to see if you also need to add deployprobeN.g and retractprobeN.g

I'm not entirely sure if its fixed / working as intended and may depend on the firmware version you are using.
I had to add them even though they only call deployprobe.g and retractprobe.g

droftarts

@stuartofmt from the 3.5 release notes https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x :

When RRF needs to deploy a Z probe, it first tries to run deployprobe#.g where # is the probe number. If that file is not found then it used to be the case the for probe only it tries to run deployprobe.g. Now, if deployprobe#.g is not found it tries to run deployprobe.g regardless of the probe number and it passes the probe number as the K parameter. This makes it possible to use a single deployprobe.g file to handle all probes. Similarly for retractprobe.g.

Ian

droftarts

@dc42 there is a typo in the above, should say
“ ..: it used to be the case the for probe 0 only it tries to run deployprobe.g.”

Ian

stuartofmt

@droftarts said in manual/Tuning/Tool_changing:

@stuartofmt from the 3.5 release notes https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x :

When RRF needs to deploy a Z probe ...

Ian

I'll take another look as soon as I get the chance. This was not the behavior in one of the 3.5 rc's - hence the workaround. I've not checked for a while - will report back as soon as I can.

luca Massimiliano

This post is deleted!