Add Drive/Extruder Parameter to M207

  • With multiple extruders and materials, it would be nice to be able to associate M207 with a specific extruder/drive since some materials require more or less retraction and differing drive and hot end hardware within a machine may require differing retraction. The parameter could be optional so that if it is included in a command, it is only for a specific drive but if not included it is applied to all drives like it currently is.

    In my case, this would allow material specific custom Gcodes (I include M207 and M572 to be inserted only at the beginning of a file. (Currently I have to run the Kisslicer Matl gcodes every tool change in order to have the proper retraction for each material. In turn this would open up more compatibility with other slicers as Kisslicer is the only one that inserts the material specific Gcodes whenever the token is called (in this case I insert it into the custom tool change gcode). I know other slicers have scripting that could post-process the code and add this but this would be a cleaner solution.

  • administrators

    Should it be per-drive or per-tool? This matters because tools that represent mixing nozzles have multiple extruder drives. If it's per drive, how should the firmware behave if two M207 commands for different extruders call for different amounts of Z hop? Again, making it per-tool would avoid this issue. But might there be applications in which a tool with multiple extruder drives might need different amounts of retraction on them?

    You can of course include M207 commands in the tool change files if it helps.

  • @dc42 For what I am trying to achieve (having the slicer insert custom parameters for each tool at the beginning of the print and only once), per-tool would be just fine. If it were per-drive, I should be able to make it work too.

    If two drives have differing z-hop, I would think using the greater of the two would be safest.

    I think for mixing hardware, people are probably using setups in which the drive hardware is all similar enough to do per-tool. I do not know of anyone blending different base materials so I would think that using the same retraction for all drives, in this case, would be okay.

    In my experience, retraction settings are much more closely related to the material properties than hardware, assuming all drive hardware is similar. Therefore, I have my toolchain set up to include the custom firmware retraction settings for each material automatically in a section of the slicers custom G-codes. In Kisslicer I put this in the Material tab and then call that material Gcode at each tool change before the Duet runs its tool change scripts. This gets tricky though with anything other than Kisslicer.

    Putting M207 in the tool change files would mean I would have to remember to change the retraction for each material manually.

    Ultimately, I would like if slicers provided an easy way to tell the firmware what material is being used and where so that the firmware would contain a configuration file for each material and the firmware gets auto-configured for that material, or maybe even replaces certain Gcode parameters with the variables stored in that file. My thoughts are that temperatures, M572, M207, and similar parameters could be stored in this file. Along with this, I would also like if the slicers and firmware could automatically enable and disable the filament monitoring for a drive that is being used or not being used appropriately.

  • For the filament switches/monitoring maybe only allowing faults/pauses to be flagged when the associated drive is in use would work. That way all monitoring could be turned on/configured at all times but should only ever cause a pause to occur if the firmware tried to use a drive that didn't have filament. This way filament does not have to be present in monitors which are not being used for a print or monitors do not have to be turned on/off for each print.


Looks like your connection to Duet3D was lost, please wait while we try to reconnect.