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

Auto-speed is broken again 2.3.57.1 #1629

Open
NameOfTheDragon opened this issue Oct 10, 2021 · 9 comments
Open

Auto-speed is broken again 2.3.57.1 #1629

NameOfTheDragon opened this issue Oct 10, 2021 · 9 comments
Labels
working as intended unless you prove me wrong.

Comments

@NameOfTheDragon
Copy link

Version

2.3.57.1

Operating system type + version

Windows 10 Pro

Behavior

Slice an object using a profile with auto-speed enabled.
image

Also note filament overrides:
image

Switch to GCODE view, and examine the print speeds.
image

The generated gcode has the entire model printing at 0.7 mm/s (which is way below the configured printer minimum print speed of 15 mm/s) - it should several orders of magnitude faster, especially the infill.
image

Project File (.3MF) where problem occurs

Use Calibration -> Calibration Cube -> Standard Cube, and set speeds as in the screen shots above.

@neophyl
Copy link

neophyl commented Oct 10, 2021

The reason a project file is requested is that there are potentially other areas that can effect things. For example filament settings can over ride other speed settings. That’s why ALL the profile settings are needed.

@supermerill
Copy link
Owner

You set 0 to gap_fill speed, bad idea as there are many very small extrusion (see tooltip).

@supermerill supermerill added the working as intended unless you prove me wrong. label Oct 11, 2021
@NameOfTheDragon
Copy link
Author

NameOfTheDragon commented Oct 22, 2021

You set 0 to gap_fill speed, bad idea as there are many very small extrusion (see tooltip).

Working as intended? Really?

On further investigation, there are two speed settings that seem to trigger this behaviour in non-obvious ways.

  • Setting Thin walls to zero triggers the entire model to be printed at ridiculously slow speeds approaching zero.
  • Setting Gap fill to zero causes the entire model to print slower than expected (a few tens of mm/s instead of hundreds) but in a non-obvious way. Why should setting Gap Fill to Auto (0) slow down infill and perimeters?

The way these settings currently defeat auto-speed calculations is extremely opaque, it goes against the "principle of least astonishment".

Perhaps one way to resolve this would be to prevent setting these settings to zero. But then what to use as the minimum value? One suggestion would be to use the Minimum feed rate when extruding setting from Machine Limits. In my case I have minimum speed set to 15 mm/s and if I set both Gap fill and Thin walls to that, then I get what looks like correct auto-speed calculations for the rest of the model (up to 240 mm/s).

So for me personally I have a workaround and improved understanding and I am happy with that, but I really feel like there needs to be some robustness around this especially when the help balloon for Gap fill says:
image

@supermerill
Copy link
Owner

Working as intended? Really?

That doesn't mean it's ideal. It just means that it's not a bug.

The thing is, gap fill can have very thin extrusion (thin walls also but it's less extreme). As he auto-speed wants to keep the same volumetric flow for everything, the thinnest extrusion is printed with the max speed and everything else have to be printed slower to keep that volumetric speed. But it's so thin that everything else is printed very slowly.

If you have a good idea...

@NameOfTheDragon
Copy link
Author

If you have a good idea...

I guess I just don't understand the auto-speed logic, it seems all backwards. I suppose this is a Prusa Slicer thing? My assumption is that if one uses auto-speed, then printing will go as fast as possible without exceeding the maximum volumetric flow rate.

How about as a stop-gap measure, just put a message on the page saying "don't set these to 0 if using auto speed" or something like that? I can avoid the problem now I know what causes it, but I'm sure others will fall into the same trap. Or, if you like, just close the issue.

@supermerill
Copy link
Owner

How about as a stop-gap measure, just put a message on the page saying "don't set these to 0 if using auto speed"

currently, there are Gap fill extrusions are ignored from the automatic volumetric speed computation unless you set it to 0
I can add And as gapfill can have very thin extrusion, it may reduce the printing speed by a lot so it's not recommended
?

I guess I just don't understand the auto-speed logic, it seems all backwards. I suppose this is a Prusa Slicer thing?

no, it's older.
As varying extrusion rate can be difficult, creating all sort of artefacts, this mode ensures that it stays constant as long as possible. It's a bit less relevant now with all those pressure advance.

@jankolkmeier
Copy link

I noticed something (that I thought was odd) about autospeed for gap moves and had this image prepared for a new bug report, but I just found this discussion which seems to be talking about the same issue:

Gap Autospeed affects other feature speed

While this may be working as intended, I have to agree with others here that it is unintuitive.
My primary confusion is this: After setting gap speed to auto, I notice that print time has doubled. I want to inspect what's going on using the slicer preview. What I expect to see is that the percentage/time of "gap" extrusions has significantly increased (the white extrusions in the preview). Instead, I actually see that gap move time has decreased, but times of other moves, such as infill and perimenter, have significantly increased - although I made no change regarding those speeds.

The suggested change to the tooltip unfortunately does not clear up the confusion for me. In fact, it confuses me more: Why would thin gaps negatively affect the speed when using autospeed? Thin extrusions require less flow and thus should allow for faster moves? Apologies if I am missing or confusing some context required for understand this, @supermerill .

As a side note, the main reason I was interested in autospeed for gaps was to limit speed on extremely fat gaps, as I had previously exceeded my extruders capabilities with a fixed gap speed on those fat gaps.

@supermerill
Copy link
Owner

supermerill commented Jan 16, 2022

Thin extrusion hit the max speed with very little flow rate.
The whole point of the auto-speed is to keep the same flow rate for the whole print if possible.
So it keep this extremely slow flow rate for everything.
So for the normal extrusions, it has to slow down a lot to keep that very low flow rate.

I can add a warning dialog when you set an autospeed flow rate and the gapfill is at 0....

@jankolkmeier
Copy link

Thanks a lot for clearing it up, I didn't realize the purpose of autospeed is to prioritize "constant pressure" over "as close to the max volumetric speed as possible". I was simply misusing this feature then. Reading it all back now makes sense, and I should have more closely read the tooltips under the "Auto Speed (advanced)" section.

I've tried to come up with a wording for a warning or popup that explains the issue without leaving room for confusion about the Auto Speed feature, but I'm afraid it is too wordy:

Auto Speed will try to maintain a constant flow rate accross all print moves.
It is not recommended to include gap moves to the Auto Speed calculation (by setting this value to 0).
Very thin gap extrusions will often not max out the flow rate of your printer.
As a result, this will cause Auto Speed to lower the speeds of all other print moves to match the low flow rate of these thin gaps.

PS: To solve my original issue about fat gap moves specifically exceeding maximum flow, instead of Auto Speed I found that I can limiting maximum flow through filament_max_volumetric_speed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
working as intended unless you prove me wrong.
Projects
None yet
Development

No branches or pull requests

4 participants