Add Drive/Extruder Parameter to M207

BMMal

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.

dc42

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.

BMMal

@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.

BMMal

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.

dc42

It sounds like per-tool is the way to go, but this feature still needs to be specified. Assuming that I add an additional parameter to specify the tool number:

Should a M207 command that doesn't specify a tool number affect only the current tool? Or all tools? Or something else?
When a new tool is created, what M207 parameters (if any) should it inherit?

wilriker

@dc42 said in Add Drive/Extruder Parameter to M207:

Should a M207 command that doesn't specify a tool number affect only the current tool? Or all tools? Or something else?

I would say if no tool is given it is taken as the global default for all tools.
Though this opens the question if it should override a more specific value if this was given prior, i.e. if for tool n aM207 Pn [...] has been issued before would a global M207 override it or not?

EDIT: This question could be solved by adding an override parameter, e.g. Onnn. If it is omitted or O0 is given it will only set the value for tools that have no specific value. O1 will override the value for all tools.

When a new tool is created, what M207 parameters (if any) should it inherit?

The global default (if any).

BMMal

@dc42 said in Add Drive/Extruder Parameter to M207:

It sounds like per-tool is the way to go, but this feature still needs to be specified. Assuming that I add an additional parameter to specify the tool number:

Should a M207 command that doesn't specify a tool number affect only the current tool? Or all tools? Or something else?

If no parameter is given it should be the global default but not overwrite any tools that were explicitly configured. This way M207 can be in config.g without a tool parameter to give a good starting point for all tools or just to set them for single extrusion setups or users who do not have independent settings for materials. Then, the beginning of a gcode file would include the more specific configuration depending on what is set in the slicer custom gcode. This would also allow for the current behavior to be mimicked if no tool numbers are ever specified.

If a second print is run without resetting the firmware, then the second file would contain the specific M207 tool configs for that print and update them as needed.

When a new tool is created, what M207 parameters (if any) should it inherit?

I think it should inherit the global default since this is how the current implementation would behave.

I don't want to break the current behavior as it is working well for me now and I know for other people. I just want to add the possibility of having it be configured per tool to allow me to expand into other slicers while still reducing the amount of manual configuration I have to do for each print/material.