The Rise and Fall of Dynamic Fan Speeds

[Mark-Dunn-OIL]

Description of the bug

I created a part to focus on the dynamic speed and cooling problems I was having:

This is sliced with the settings:

What I would expect to see is a smooth interpolation of the part cooling fan speed as my oval overhang is printed.

What actually happens is:

• The move commands are grouped by integer fan percentages.
• There is an interpolated part cooling fan speed set before each group.
• The group is printed.
• The fan is turned off.

Unfortunately all this dynamic cooling interpolation work is rendered useless by turning the motor off after each grouping. The fan is given almost no time to spin up before being switched off again. (NOTE the difference in speed)

NOTE: If 'Keep Fan Always On' is enabled then the variable 'Fan Settings: Fan Speed: Min' is used instead of turning the fan off, crushing the interpolation in a similar way.

I loaded up your released versions to discover when the bug occurred.

• It was last working properly in 2.6.0 Alpha 6 Test 1
• It was working with some odd blank lines but clearing out all the configurations fixed 2.6.0 Beta 1
• It was working with some odd blank lines from 2.6.0 Beta 2 to 2.6.2
• It was confused at 100% overlap but working properly with less than 100% overlap in 2.7.0 Alpha 1
• It is not working from 2.7.0 rc-1 to 2.7.5-rc1

This has been reported in different guises many times

• Dynamic overhang speed used for bridges #10410
• Anticipation of Dynamic control of fan speed on overhangs  #10130
• part cooling fan ramp-up time #10004
• GCode spam on perimeter overhangs caused by M106 enable fan commands #11856
• Inadequate fan control when printing overhanging perimeters #12520
• Dynamic Fan Speed Interaction with Fuzzy Skin #12147
• M106 M107 Spamming with Dynamic Fan Speeds #11981
• Overhang Perimeters use Travel speed and ignore limits #10229
• Dynamic overhang speed does crazy things not what expected #12094

Other Errors:

1. On the User Interface there is no discernible difference between ‘Speed for overlap 0% (bridge)’ and ‘Bridges Fan Speed’
   Both variable names quite rightly show they represent the bridge speed, one should be removed.

2. M106 commands SHOULD be grouped into integers between 0 and 255 to match the PWM not integer percentages which don't.

Code Snippet for 2.6.0 alpha 5:

;TYPE:External perimeter
;WIDTH:0.259999
;HEIGHT:0.15
G1 F2400
M106 S186.15				// 73%
G1 X62.821 Y58.482 E.00779
G1 X63.023 Y57.786 E.0103
M106 S188.7					// 74%
G1 X63.273 Y57.191 E.00917
M106 S181.05				// 71%
G1 X63.591 Y56.605 E.00947
M106 S173.4					// 68%

Code Snippet for 2.7.5-rc1

M106 S66.3 ; enable fan			// 26%
G1 X58.594 Y60.8 E.00417 ; perimeter
G1 X58.551 Y59.999 E.00416 ; perimeter
G1 X58.573 Y59.422 E.00299 ; perimeter
G1 X58.651 Y58.787 E.00332 ; perimeter
M107 ; disable fan				// 0%
M106 S63.75 ; enable fan			// 25%
G1 X58.75 Y58.274 E.00271 ; perimeter
G1 X58.904 Y57.711 E.00302 ; perimeter
M107 ; disable fan				// 0%
M106 S63.75 ; enable fan			// 25%
G1 X59.187 Y56.948 E.00422 ; perimeter
M107 ; disable fan				// 0%

Project file & How to reproduce

2.7.5 rc-1 Project:
Overhang.zip
The gcode for all the versions tested is here:
versions_test1_gcode.zip
I tried to narrow the fault down further, but could not compile Prusaslicer in Windows using your instructions - sorry.

Like others before me, I think dynamic speeds and dynamic part cooling fans are the fundementals of how our plastics should be put down. Along with hotend temperature, build plate temperature and enclosure air temperature. Of course, in the real world they all have momentum and therefore the acceleration should be taken into account. Multi axis printing anyone!

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.7.0 rc-1 to 2.7.5-rc1

Operating system

Windows 11

Printer model

Voron 0.2

[Mark-Dunn-OIL]

While repeating this test with a released version (2.7.4)
With no configuration - so the configuration wizard ran.
Then I applied the configuration changes similar to the ones above.

I noticed both dynamic speed and dynamic cooling were ignored.
(Those were the only features I was looking at)

When Prusaslicer was closed and re-opened then re-sliced then the features were then present.
I did not notice this oddity with the non-release versions.

So, for completeness, here is the gcode snippet:

M106 S33.15                                                   // 13%
G1 X60.898 Y58.645 E.00472
G1 X59.676 Y58.667 E.00511
G1 X58.446 Y58.594 E.00515
G1 X57.407 Y58.453 E.00438
M107                                                              // 0%
G1 F31401.182
M106 S33.15                                                  // 13%
G1 X56.409 Y58.237 E.00427
M107                                                            // 0%
G1 F32017.621
M106 S33.15                                                // 13%
G1 X55.446 Y57.943 E.00421
M107                                                           // 0%
G1 F32930.2
M106 S30.6                                                 // 12 %
G1 X54.589 Y57.598 E.00386
M107                                                          // 0%

The test values are slightly different but the same fan pattern is there.
So while interpolation is going on, it is still borked by the 'Motor Off' (M107 Commands) after every move.

[Mark-Dunn-OIL]

For some real world testing I first had to delve into the Klipper configuration.
I have played with my Klipper part cooling fan configuration to get it as responsive as I can:

[fan]
pin: EBB36: PA0
max_power: 1.0
kick_start_time: 0.1                                                  # default
off_below: 0.1                                                        # starts at 8 so set to 10
cycle_time: 0.01                                                      # default 

In PrusaSlicer 2.6.0 Alpha 6:
The fan speed moves around on the GUI (Mainsail) and the print shows it pretty responsive at either end of the print where the layers take longer to print. In the centre section the fan is not responsive enough for the speed of the printing. Clearly some tuning is required from the 'extreme' settings in the test.

In all later versions:
The part cooling fan speed is always zero in mainsail and the part shows no evidence of cooling.

[Gunner087]

The project file and gcode file below shows this issue is still present in 2.8.0 on macOS Sonoma 14.5.
Project.zip

[Ma-xik]

may be this could help
https://github.com/Di-Strix/gcode-post-processing
still didn't tried but i dream about improving cooling in prisa like it made in orca