Flow Rate Based Retraction Distance

[CCS86]

This is similar to my recent request for a flow rate based coasting volume, since both deal with pressure based phenomenon.

On my bowden printer (UMO), retraction requirements are drastically different when at say 0.15mm layers, and 30 mm/s, than they are at 0.2mm layers @ 60mm/s. It can be the difference between 2mm retraction needed vs 6mm

If the slicer could keep track of the volumetric flow rate of the last print move before retraction, and perform a simple linear calculation on distance, I think the results would be great.

Just for fun I plotted the two conditions I mentioned above to see how close they would be to linearly pointing at [0mm retraction @ 0mm^3/s], and it is super close:

This would mean that you could calibrate by doing a rectraction test at your max printing flow rate to determine a good retraction distance. Just plug the flow rate and retraction distance in and Cura could just use that slope.

[Ghostkeeper]

We've discussed this with the Cura team. We'd like to run this idea by Ultimaker's material & processing engineers. We think the idea has merit but they have more expertise than us programmers on this regard.

To summarise the problem: You observe that the ideal retraction distance depends linearly on the flow rate. You configure the retraction distance to the median flow rate of the print, but there are still variances in the flow rate within the print (different speeds, infill layer thickness, etc). But you'd like to have the retraction distance depend on the flow rate.

We'd have to test two things in particular:

• You can't reduce the retraction distance for high flow because that would increase stringing.
• You can't increase the retraction distance for low flow because that would increase printing time and wear on filament too much.

Essentially, we'd have to test if the difference between the optimal retraction distance is great enough that it makes a tangible difference in the print quality or productivity to implement this.

[CCS86]

I'm glad to hear the idea has a little traction.

I think you summed it up well. If any development does eventually move forward, it would be a good idea to keep in mind that coasting volume would benefit greatly from this approach as well.

I think a test could be written relatively easy using a python script to generate gcode that makes two simple shapes (square or round towers), at fixed distances from one another; repeated N number of times.

You would define S_0, the printing speed of the first tower set; and S_f, the printing speed of the final set; incrementing speed between tower sets,

You would also choose a starting and ending retract distance (Rd_0, Rd_f), and derive a retraction distance increment from these values and N.

This would let you perform the test a few ways:

1. You could choose S_0 and S_f to be the same low print speed, but with a range of retraction distances. This would let you find the minimum effective retraction distance for the low print speed.

2. You could now fix retraction distance at this value, and let print speed increment up. This would help demonstrate that the short retraction distance works well at lower flow rates, but breaks down as nozzle pressure increases.

3. You could perform test enable/disable slice in background #1 again, but at your maximum printing speed, to find the optimum retraction distance at this pressure.

4. You set up the test to range from your low print speed to maximum, and your retraction distance from the low optimum, to the max optimum. This would prove the concept out fully if each tower printed well with the linear, flow-rate based retraction distance in place and calibrated.

[Ghostkeeper]

Ultimaker's material & process engineers say that they have found no significant dependencies between flow rate and the optimal retraction distance. As a result, in Ultimaker's profiles there is no difference between the retraction distance of the high-quality 0.06mm profile and the fast 0.2mm profile, as can be seen. Stronger factors for the retraction distance are the width of the melting gradient and the viscosity of the material (which depends on temperature). They also mention that the retraction is a tiny fraction of the printing time, so they don't think that reducing the retraction distance makes a lot of difference for productivity.

This seems to contradict your tests though.

[ClockeNessMnstr]

if you enable flow rate compensation you get flow rate based retraction. I ran into an issue with this however as the retraction priming seems broken with flow rate compensation. The flow rate compensation is retracted after a move, however it is not re-primed which is an issue for the next move.

I will be writing this as a new issue unless I find another issue that specifically pointed this out.

[CCS86]

Interesting thought. I hadn't tried that feature.

After enabling "flow rate compensation" I saw no change in extruder behavior. It was set to 100% and 4mm max correction.

Is that feature functional?

[ClockeNessMnstr]

It's not working correctly but it was giving me increased extruder position.
you can check the gcode pretty easily. there are comments with "FLOW RATE COMPENSATION ="

however it is not using negative values or coming back to 0 when stopping before a retraction so the retraction occurs with the entire compensation value + retraction distance. since it doesn't reduce the compensation at the end of a move or before a turn it just extrudes more before the retraction. Then priming doesn't work because it does not restore the compensated position.

The description sounds like it should be breaking each move into 3 parts and adjusting the E values but I only see it adding some E at the first move after a feedrate change. It should reduce the compensation to 0 before the stop + retraction resulting in reducing the pressure to a consistant state before each retraction.

I'm going to break out a post processing script and see if I can replicate + improve on the changes it makes as I'm lacking Linear Advance on my Ender 3 V2 due to the integrated 2208 driver on my extruder.

What I think is going on:
Black: current behavior of Flow rate compensation / extrusion path of a line
Blue; target behavior
Red: normal behavior
Green: retraction

EDIT: E does not also represent pressure. maybe integral of pressure would look the same as E position.

[ClockeNessMnstr]

I wrote an issue on the extra retraction I drew in black #8202
I'm thinking the title is wrong as it seems the Flow Rate Compensation itself is broken/incomplete

[CCS86]

Not sure what my issue was last night, but Flow Rate Compensation is "functioning" now.

I really hope some development work can be applied to this feature, as I think it has sooo much potential. I really believe that it belongs in the slicer, not in the firmware (as pressure advance).

[ClockeNessMnstr]

Seems like it could be done best in the firmware, sounds like a headache in the gcode. I'm not sure why firmware works with some stepper drivers and not the 2208's so I'd say it definitely should be an option in the slicer.

[Ghostkeeper]

Here is my write-up of what the expected behaviour is of the setting: https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/experimental/flow_rate_extrusion_offset_factor.md
Or at least, what I thought it was doing last year, when that article was written.

This was an experiment that was found to be very ineffective with a Bowden tube indirect-drive printer like the ones Ultimaker manufactures. So it probably won't get much attention from us soon.

[ClockeNessMnstr]

Thanks! that makes sense as to what is happening then. Seems it would some new development to be effective similar to LA. I'm glad I wasn't crazy thinking this was supposed to be a sort of LA compensation.

[ClockeNessMnstr]

I wrote a post processing script to do some LA

Top: Slow, Middle: Fast, Bottom: Fast + SWLA

Might not be perfect or efficient yet but it works really well since I'm stuck with TMC2208's on the Ender3 v2

Edit,
Found some bugs with the junction/lookahead functions. hosting the script/test as a WIP on Thingiverse until I work it out.
https://www.thingiverse.com/thing:4578664

[CCS86]

I wrote a post processing script to do some LA

Might not be perfect or efficient yet but it works really well since I'm stuck with TMC2208's on the Ender3 v2

Edit,
Found some bugs with the junction/lookahead functions. hosting the script/test as a WIP on Thingiverse until I work it out.
https://www.thingiverse.com/thing:4578664

Well that is exciting! The results look very promising. I can try to do some testing on it, when you think you have ironed out the identified bugs.

[CCS86]

@ClockeNessMnstr

I was going to test your script and had a question. Are all these fields labeled correctly? Some of the default values didn't make sense, like Y and X velocity limits being at 1000 mm/s

I filled in with my actual values and tested on a live print, and even with K set as low as 0.2, I got a lot of print head and extruder stutter during circular motion, especially in the skirt:

[ClockeNessMnstr]

I think it's still producing three lines for every one original line of g-code (even k=0). It should be "cruising" instead of accelerating every time. The last changes I was making should have improved or fixed that but then it started hanging on me.

I'll get it working with my last changes and update the files.

[ClockeNessMnstr]

fixed it hanging (still takes a while to run). I need to figure out an issue on my printer config or cura settings. I'm actually getting stuttering / bulges on my benchy hull without any post-processing. I need to fix that before I can keep testing.

EDIT: the default maximums are high. I just have them set high on my printer right now so I put the defaults in that way. the script reads the actual print jerk and acceleration values from the gcode if you enable acceleration control and jerk control so the maximums sholudn't really matter.

[CCS86]

You might check out this issue I posted. 4.7.0 seems to be introducing discontinuities in perimeters that cause slowdowns:

#8321

[ClockeNessMnstr]

You might check out this issue I posted. 4.7.0 seems to be introducing discontinuities in perimeters that cause slowdowns:

#8321

oh dear,
That looks like it's it. This is a picture of it slowed down to 30mm/s which helped the look but it is still super unusable.