Firmware retraction settings per tool

dc42

I had scheduled implementing per-tool firmware retraction settings for the 3.02 release, but now that I have a tool changer with both Bowden and direct tools, I've realised how useful it is. So I've brought this feature forward to release 3.01. Look out for RC4 in the near future.

deckingman

@dc42

David,

How difficult would it be to implement firmware retraction per drive as well as per tool? I'm thinking about my new mixing hot end. Similar to my existing Diamond hot end, the Bowden tube lengths are asymmetrical and there is no easy way that I can get around that due to packaging constraints associated with 6 extruders on a moving gantry. So my firmware retraction distance has to be a compromise - possibly a bit short for the longer Bowden tubes and a bit too much for the shorter ones. That "bit too much" probably didn't matter with the PTFE lined heat breaks that the Diamond uses, but the new hot end is all metal and the last thing I want to do is drag molten filament up inside one of the heat breaks. The new hot end has the additional feature that one of the filament inputs has a straight path to the nozzle, whilst the other 5 all go through a complex mixing chamber. Which is another reason why per drive retraction might be useful to have.

T3P3Tony

potentially have the tool retraction settings accept an array of settings that matches the drives assigned to that tool?

deckingman

@T3P3Tony That sounds like it would work for me. Ref the per tool retraction settings, could that not simply be accomplished by adding the desired M207 values to the tool change macros?

TC

@deckingman that is how I so it right now but I would love to have it really implemented

nraynaud

I put my software retraction parameter in my material file, was it wrong?

dc42

Here's a summary of the options:

Current system. One set of parameters for all extruders. For a mixing tool, G10 retracts all extruders by the same amount, at the same speed. Similarly for G11.
One set of parameters per tool. For a mixing tool, G10 retracts all extruders by the same amount, at the same speed.
Per-extruder retraction parameters instead of per-tool. For a mixing tool, G10 would retract all extruders by the configured amount for that extruder. But different extruders may specify different retraction speeds from each other. So the firmware would either have to execute it as an uncoordinated move (i.e. some extruders would finish retracting before others), or it would have to slow down some extruders so that all the retractions take the same time as the one that takes longest when it uses the specified parameters. Similarly, G11 would re-prime each extruder by its configured amount; but it would either have to execute them as uncoordinated moves, or slow down some extruders so that they all take the same amount of time. It doesn't make sense to configure Z hop per extruder, so a separate command would be need to configure Z hop per tool.
Per-extruder-per-tool retraction parameters. Individual retraction and reprime amounts would be specified per extruder, but only one speed, which could be treated as the speed that G10 uses for the extruder with the longest retraction distance. Similarly for reprime moves. One Z hop would be specified per tool.

From a firmware perspective, #2 makes a lot of sense because there are no conflicts over what the retraction speed or the reprime speed means (and I have already implemented it). #3 makes very little sense to me. #4 could be implemented later as an extension of #2.

Comments?

deckingman

@dc42 I'm probably the only person with a mixing hot end and asymmetric Bowden tube lengths which can't easily be made symmetrical. Given how busy you always are, it probably makes no sense to do anything complex or time consuming for a single user. My preference though would be #4. But in any case, let's wait and see what happens in real world testing. It may not be an issue.

dc42

@deckingman said in Firmware retraction settings per tool:

@dc42 I'm probably the only person with a mixing hot end and asymmetric Bowden tube lengths which can't easily be made symmetrical. Given how busy you always are, it probably makes no sense to do anything complex or time consuming for a single user. My preference though would be #4. But in any case, let's wait and see what happens in real world testing. It may not be an issue.

Ian, thanks for your feedback. I'll leave the implementation as #2 in RRF 3.01, but there is the option to change it to #4 in a future firmware version. Changing to #3 won't be an option.