Limit extruder feedrate for printing and retraction

[MarkMan0]

Application Version 3.6.0

Platform Windows 10

Printer With Marlin firmware

So I'd like to have a feature to limit the maximum speed of the extruder, while printing. I've tried doing this by chaging the limits in firmware, but it made retraction slow too, obviously.

So what I imagine is a new setting in the speed tab, like retraction speed Extruder max. speed [mm/s] - lets say 3mm/s. Thats 180 mm/min

And then in the gcode it would be like: ..... M203 E180 ; set extruder speed for printing ; printing now G1 G1 G1 ... ;Now retract, reset feedrate M203 E... G1 ;retract G0 ;travel G0 G1 ; un-retract M203 E180 ; reset feedrate

Why I think this is good? We can easily measure the max. feedrate our printer can handle with certain filaments. For me it's 200mm/min. This value doesn't change for different layer heights, so no need to play with temperature/speed settings when increasing layer height.

The max print speed would be limited in firmware.

Edit: I'm a hobby programmer. The way I would go implementing this, is: stick an M203 at the beginning

before every retraction set M203 after every retraction, set M203

[psiberfunk]

Another pile on user here. Having built my own printers at this point and used Klipper and Marlin and Cura and PrusaSlicer and SuperSlicer (SuSi), I can definitely say I generally prefer Cura's way of doing things, but SuSi/PR's way of doing volumetric-constrained speed throttling is absolutely a godsend to setting speeds.

In my case, my CoreXY printer is great at handling high speed moves and i'm often more constrained by the filament properties and the extruder's ability to press things through the hotend (Dragon Highflow) than I am by speed limitations per se. Setting speed limits within the context of a volumetric flow is so much more intuitive when used in combination with speed limits ... here's how I think about it:

Volumetric flow is like my home internet pipe, throttling the total bandwidth to my devices in my house. You can't exceed it's compacity without upgrading. Everything must bow to the ISP link speed. Each of the other speed limits I may set in my router quality-of-service settings are subservient to the master bandwidth limit. Figuring out what is limiting during the print could easily be messaged to the user with a popup tip on slicing.. or better.. when viewing the speeds/flow views of the slicer preview, where it would be most appropriate.

I would expect to get a little helpful notice that says "Note: your speeds have been capped by your maximum flow rate setting (XX mm^3/s) in this print. Learn more (insert link to page explaining basic concepts)"

[khani3s]

So basically it's just an UI problem? Let's just add an option under experimental for now. If someone enables it just paint all overridden speeds on orange and set a popup message like others suggested. If someone turned on advanced mode I believe he is already able to get around in the settings.

[VoronManiac]

I have found that some materials like TPU are volume flow limited. I was getting Extruder jams on my Voron using SuSi because I was allowing line width to vary for interior fills at "low" print speeds. There were a few fat lines where the volume spiked resulting in a jam. Setting the max flow rate worked like a charm. So far, I am reliably able to run TPU at volume flow rates of 6mm^3/sec (runtime confirmed on the mainsail display) which if you do the math for 0.4 wide line and 0.2 layer height yields print speeds of 75mm/sec. Print speeds are vastly increased. Reading this thread, it is not clear what requests are opened, closed and linked. I was having some other issues with SuSi and was looking at Cura, but not having volumetric flow is a non-started for TPU.

[Pennerbert]

+1 Any news out there?

[Arsoth]

Easy to do so I have added a Max Filament Flow Rate setting to my Cura variant and it will be available in the next release (4.20.9) (see https://github.com/smartavionics/Cura/releases).

Any chance you could put a PR in for that... or is it wildly incompatible with Arachne (I'm sure I misspelled that) engine?

[psiberfunk]

Any chance you could put a PR in for that... or is it wildly incompatible with Arachne (I'm sure I misspelled that) engine?

Sorry, I no longer submit PR's for anything other than fixes for my own bugs. The good news is that the required changes are trivial so anyone who can build Cura 5 from source could submit an equivalent PR with little effort.

I’m not sure why you would comment on this thread if you’re to dangle a fix, plug your own fork , but not going to submit a “trivial” PR upstream. That’s a little rude IMO. Such behavior is only normal when the upstream project is abandoned or not accepting PRs.

[tastyratz]

I mean, I get that you have your own fork which gives you a lot more freedom and I suspect there could be politics being in the big sandbox with everyone else, but, I really hope you reconsider this position. Having your own fork is great when you want to take things a new direction and have a different vision. Having your own fork is simpler. It's also great to put your changes in there if they are denied by the main branch because of fundamental differences on the end result.

If you won't even submit a PR to begin with though, Those things don't really apply.

I'm glad you made the change and that you feel it's rather trivial to implement Please consider helping everyone at large who isn't using a spinoff.

[psiberfunk]

I'm glad you made the change and that you feel it's rather trivial to implement Please consider helping everyone at large who isn't using a spinoff.

Or that doesn't have the deep familiarity with Cura or the build system...

[Arsoth]

Oh well, he deleted his comments. Guess he took his toys and went home, but at least now we know it's possible and "trivial"; hopefully someone from the Cura team or who has a good understanding of the code can implement that so the rest of us can use this feature!

[psiberfunk]

So, I was just browsing his relevant changes, which I found buried in his branch here (he did not link to them easily for some reason): https://github.com/smartavionics/Cura/commit/81a6fddfd1d886fe7d69d5ff2d53b787946cbf89?diff=unified

While I don't understand the Cura codebase at all.. it seems like based on the changes this is a slicer front-end setting in config files to somehow trigger the use of a CuraEngine feature that's buried... but I can't find any reference to it in the mainline CuraEngine code.. so i'm going to go hunting in his CuraEngine Fork for them..

[psiberfunk]

If someone wanted to pull this in, it would seem you'd need to pull in his additions to the CuraEngine project as well, which I located here:
https://github.com/smartavionics/CuraEngine/commits/mb-testing

[olmedocr]

@psiberfunk are those two changes (engine + cura) the only ones needed? Why don't you try and submit the PR?

[maruhe]

I use adaptive layer high and on 0,3mm layer and 120mm/s I'm at the end of my revo so to print support and infill a little slower for this layers would help and limiting extruder feedrate / volumetric flow would solve this :-) as I already see the flow in cura preview i hope there well be a way

[mjc-506]

Submitted a couple of PRs for this (one for Cura https://github.com/Ultimaker/Cura/pull/14452 , one for CuraEngine https://github.com/Ultimaker/CuraEngine/pull/1814 ) that implement this, copying the code used for 4.20 above https://github.com/smartavionics/Cura/commit/81a6fddfd1d886fe7d69d5ff2d53b787946cbf89?diff=unified

This works-on-my-machine(tm) (ie, keeps flow rate at or below the limit set) but it does seem simple enough so can't foresee any problems...

[ghost]

@mjc-506 It did not compile with freshly fetched repositories. There might have been some changes in CuraEngine since you've last updated your fork.

Anyways, I've created a PR on your repo with all necessary changes that made compilation possible on-my-machine⟨™⟩.

[matthewj301]

Thanks @mjc-506 and @mashuptwice for your work on this! I feel like this is one of the main features missing compared.to PS and SS (besides common-sense filament management 😛)

[tastyratz]

Did you want to linkback your pull here so we could follow the progress on this one? It might make it easier to keep track of. I just checked back in on the thread and thought it could be helpful.

[tastyratz]

This one sat for awhile and I just noticed that https://github.com/Ultimaker/CuraEngine/pull/1828 pull request was closed. It looks like Mashuptwice deleted their github account and the pull died with it.

Does that mean we're back to square one on this very important request?

[mjc-506]

Whhaaaaat?! :( [s]#1814[/s] should be good to go I think, but has a conflict that needs someone to resolve. (line 2057 removing?) https://github.com/Ultimaker/Cura/pull/14452 (for Cura) looks ok too?

[Arsoth]

(1814 meaning this PR for those confused: https://github.com/Ultimaker/CuraEngine/pull/1814 )

[mjc-506]

D'oh, sorry, getting confused where I am... :-)

[cubitik]

+1, Cura getting boring.

[ArnoldDeRuiter]

Would also like to be able to set flow rate in Cura. Great improvements have been made already! This one is noticeably missing still however.

[konddda]

+1. I can't beliele, there is no max volumetric flow rate

[olszewski]

Please for the love of everything good add this to the slicer. It would be an immensely powerful feature that with a current model I am looking at would be able to cut my print time down to 1/3 if I was able to maximize the flow rate across it.

The printer speed or flow rate isn't the limiting factor at all right, it's just the lack of this feature in the slicer to automate things.

I appreciate your work guys!

[tastyratz]

I cannot believe that Cura is STILL the only slicer left that does not have this very basic setting like all modern slicers. The fact that I'm still getting notifications from this post this many years later is WILD.

This is a 5 year old req! And it's a bare minimum requirement necessary on any modern high-speed printer since that timeframe. I'm glad I didn't wait around for it. If Ultimaker wants to retain any userbase that has mixed mode environments with any coreXY printers in house, this is a showstopper.