Feature request: retraction concurrent with travel

[richfelker]

The idea is to utilize the negative pressure during retraction, in addition to the absence of the filament after retraction, to prevent stringing, thereby allowing faster printing and possibly also less stringing with materials prone to it.

I haven't performed any tests yet to confirm that this works as expected, but if there's potential interest in supporting such a feature, I can do some tests by hand on gcode to see if it looks promising.

[Ghostkeeper]

If you're running some tests, take extra care to test materials with long extrusions, such as TPU or Polypropylene. There is a danger that the travel move will become too slow then. Also take care to test with long travels because the retraction will become too slow then.

[richfelker]

Sorry I wasn't clear: I didn't have in mind slowing down either the retraction or the travel. Rather, the retraction would take place concurrently with whatever part of the travel it would happen during the time to retract at the defined retraction and travel speeds. If the travel finished before the retraction finished, the retraction amount would be less than the nominal configured amount, and the reversal of the retraction would likewise be less. This behavior is a big part of the point of the feature: making retractions for short travel jumps less costly in time by using the negative pressure in place of a full retraction.

[Ghostkeeper]

Ah, yeah I see.

It's going to be a bit more complex though. The printer is making a 4-dimensional move here with separate acceleration and jerk coefficients for each axis (except X/Y jerk). In the g-code it needs to say to what location the X, Y, Z and E coordinates need to move. G-code is unable to say "Move the extruder 8mm up, and in the meanwhile move to this X, Y and Z coordinate, interrupting the E move if you're done with the X, Y and Z move."

This 4D movement makes the computation very complex, because it depends on the speed gradient of the XYZ movements how much time you have to retract and thus to what 4D position it needs to move first. If your retraction travel move starts at a speed of 50mm/s then it can get further during the retraction than if it starts from a stand-still, because you still need to accelerate from the stand-still. Similarly, if you were extruding before the retraction then the E axis will need more time to accelerate to the other direction and so your travel move needs to go further.

Also, because the X/Y, Z and E can all three have different acceleration parameters in Marlin, two of them are going to be limited in their speed because of the acceleration limits of the third.

This is the reason why the current Z hop implementation does a vertical hop first, then X/Y movements, and then a hop down.

[richfelker]

I see. I wonder if just doing the retraction concurrent with z-hop - which should be easier since the initial z speed is known (0) and the distance is fixed - would be a worthwhile simplification of this proposal. It might help kill the stringing z-hop is infamous for.

[Ghostkeeper]

That does make things simpler. I wonder how it resolves the difference between the X/Y jerk and the Z jerk in this. At what speed will it go around the corner towards the Z hop? Is that the X/Y jerk or the Z jerk?

[richfelker]

I wonder if this functionality wouldn't make more sense in the printer firmware's planner, not just as "retraction concurrent with travel", but "full auto-retraction concurrent with travel". Marlin's Linear Advance functionality already essentially does this for its extruder adjustments, which are essentially retractions, that serve to relieve pressure at the nozzle during deceleration. It seems the same principle could be extended such that the slicer wouldn't have to perform retractions at all, with them instead happening automatically as part of travel.

As @Ghostkeeper noted above, the hard part of doing retraction concurrent with travel at the slicer level is having to predict how the firmware's planner will incorporate acceleration and jerk. But the interrupt handler doing the math for linear advance already has all that information and is already doing math that's largely equivalent.

[ivanwong1989]

I would love such feature as well. Retraction while moving would give some negative pressure in the nozzle to stop oozing.

[richfelker]

@ivanwong1989, I think it probably makes more sense to do this in firmware as part of linear advance, with automatic retraction that doesn't need any action by the slicer. Otherwise splitting the roles seems to get messy; I don't know if firmware is even prepared to handle negative extruder-axis motion concurrent with spatial motion, especially with linear advance.