[Bug] Fan speeds incorrect based on layer time and cooling settings

[psiberfunk]

Bambu Studio Version

1.7.3.50

Where is the application from?

Bambu Lab Official website, Bambu Lab github releases

OS version

Windows 11 / Win64

Additional system information

N/A - not a rendering/performance issue.. is a slicer bug.

Printer

X1C

How to reproduce

Slice the attached file, observe the fan speed, for example, on layer 16, which shows a fan speed on the whole layer of 49%, whereas the layer TIME on this layer is 30.7 seconds. Accordingly, the fan speed should be 10%, and not 49% !

Obviously this has a huge impact when you're dealing with a high-warp filament like ASA...

Actual results

Slicer calculates the incorrect fan speed. See these screenshots as proof:

Expected results

Slicer should properly calculate fan speed according to the rules laid out. I can find no reason for why the fan speed should be 49% at this layer... and other layers are very obviously wrong as well.

Project file & Debug log uploads

BambuStudio_FanSpeedIssue_CaliCross_XY.zip

Log file N/A because this isn't a crash or similar type of issue.

Checklist of files to include

• Log file
• Project file

[SaltWei]

If you have looked at the code implementation, you would notice that the layer time used for calculating fan speed when generating gcode is a conservative value that doesn't take acceleration into account. Therefore, the layer time is shorter, resulting in a higher calculated fan speed.

On the other hand, the layer time displayed in the preview interface considers acceleration and jerk constraints, resulting in larger time values.

[SaltWei]

If considering jerk and using trapezoidal acceleration and deceleration to estimate layer time at generating gcode stage，the code will be very complicated, which cause gcode generation very slow.

So this is not bug, but as expectation with current code implementation（which may not accurate）

[psiberfunk]

Ok, @SaltWei I can see how it's both a bug and "not a bug". It's a bug in the sense that the display and the fan time are very obviously discordant, and not a bug in the technical sense that the code is doing what it's designed to do.

Part of the difficulty here is "what's the right behavior?" Should the fan speed be set according to the "rough estimate" at GCODE generation time, or the more correct preview time ?

Part of what i'm missing here is that GCODE generation and previewing almost always go together (preview is usually shown after slice).. how can the experience be any slower if the preview calculations are simply done sooner in the process ?

[dgauche]

I see similar issues in PETG which results in a change in print quality where the fan speed changes.

[fangly]

This behavior of the application is both unexpected for the user and can leads to significant issues, like loosing time tuning a filament or wasting filament with failed prints. So, my 2 cent is that is actually a bug.

[BambulabRobot]

This issue has been marked as inactive due to no response for 90 days.