Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow limiting maximum volumetric flow of material for the print #12743

Closed
akshimassar opened this issue Jul 11, 2022 · 2 comments
Closed

Allow limiting maximum volumetric flow of material for the print #12743

akshimassar opened this issue Jul 11, 2022 · 2 comments
Labels
Status: Duplicate Duplicate of another issue. Type: New Feature Adding some entirely new functionality.

Comments

@akshimassar
Copy link

Is your feature request related to a problem?

Maximum volumetric flow (in mm^3/s) is a characteristic of a printer for a certain material. For instance, my machine is able to print certain TPU at the rate of 7 mm^3/s. If exceeded, TPU bends and leaves normal path leading to jam. It's a hard limit, meaning exceeding is equal to ruining the print.

At the same time, printing speed is also important for various materials. Some of them require not exceeding certain speed to get proper adhesion (or to properly melt with neighbor lines).

With introduction of variable line width it becomes harder to control these parameters. Yes, flow equalization ratio is here, but It's not super flexible.

Describe the solution you'd like

Please allow to limit flow and possibly extrusion speed as well.

Allowing limiting the flow to certain number will not only ensure that variable width will not lead to exceeding it but might be also beneficial for common prints. For instance, I would set flow limit to 20 mm^3/s and would not have to touch printing speeds anymore, expecting slicer to slow down the printer when necessary. In contrast, now I have to adjust my printing speed to not exceed flow when I increase line width and / or height. Even worse when line width is different for different purposes as well as printing speed.

Limiting speed is might also be a good idea as some material require slower speed for adhesion. But for what I see cura 5.1.0-beta is actually exceeding print speed by default using probably travel speed as limiting factor. Actually, I would rather have speed I configured for printing to be the top speed for printing since usually lowering speed is more forgiving than increasing it. I probably could set flow equalization factor to zero, so I would get my speed as desired. But then slicing results in flow exceeding my desired one (line width * line height * speed) by 40% ! So we are back to limiting flow question...

Describe alternatives you've considered

Alternatives are described above, manual checking and re-configuring speeds.

Or possibly you could use configured printing speed / flow as upper bound. That what is usually ment.

Affected users and/or printers

In first place, I think, those who print fast and pushing the limits will benefit from that change.

Additional information & file uploads

No response

@akshimassar akshimassar added the Type: New Feature Adding some entirely new functionality. label Jul 11, 2022
@GregValiant GregValiant added the Status: Duplicate Duplicate of another issue. label Jul 13, 2022
@GregValiant
Copy link
Collaborator

This comes up every once in a while as in #11901 , #5248 , #6982 , #7865, #9410 #10320 , #10894, #11667 , and on the backlog as "Devs see CURA-8282" .
5248 in particular has some good discussion regarding volumetric control of the speed.
Maybe @Ghostkeeper can address where the Cura Team is with this and in regards to the implementation of the "flow equalization ratio" currently used in the 5.x versions of Cura.

@Ghostkeeper
Copy link
Collaborator

Flow Equalization Ratio only applies to the variable line width created for walls in thin parts. I don't think it's a solution for this issue, not even a halfway solution. It's a way to keep the flow equal within a certain type of structure. There will still be flow changes when switching to e.g. infill.

We have the issue in our backlog. We didn't work on it yet and the UX isn't entirely clear either. It's about halfway along our backlog, which basically means that it's unlikely to get cut but it's also not likely to be implemented in the next few releases.

I will close this as a duplicate of #5248. Please continue the discussion there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Duplicate Duplicate of another issue. Type: New Feature Adding some entirely new functionality.
Projects
None yet
Development

No branches or pull requests

3 participants