M106 M107 Spamming with Dynamic Fan Speeds

[Gunner087]

Description of the bug

When using "dynamic fan speeds" M106 and M107 commands are created very close together, often after every single G1 command when printing circular features, resulting in the printer building up a buffer of hundreds of fan commands. This results in the fan pulsing at a high speed above what was requested by the slicer if fan "kick starting" is enabled in the printer firmware. If "kick starting" is disabled then the fan runs for extended periods after it should have already turned off due to the large buffer of hundreds of fan commands. Originally I thought maybe this could be fixed in firmware. I am using Klipper and it only allows a new fan command to be executed every 100ms, so I thought removing this limitation would fix the issue. However the more I thought about it, I realized that it does not matter what firmware you are using, this will still be an issue. With no fan command execution delay, the physical hardware pin controlling the fan PWM could be turned on and off uncontrollably at whatever speed the gcode file is interpreted. This could potentially destroy fans connected to printers that have no limit on how fast the fan commands are interpreted. I have destroyed fans in the past by using a PWM frequency that was too high (I think the capacitors burn up because of AC currents going through them).

The video shows how I can replicate the issue by simply spamming M106 and M107 at the printer using the console in Klipper. Note that fan "kick starting" is enabled in the video since it exaggerates the RPM fluctuation so you can hear it.

IMG_3865_small.mov

Project file & How to reproduce

M106 M107 Issue.3mf.zip
Open the project, slice the part and view the gcode on layer 4. In areas where dynamic fan speed is working, there is an excessive number of M106 and M107 commands.

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.7.1

Operating system

macOS Sonoma 14.2.1

Printer model

Voron 2.4 running Klipper v0.11.0-304

[gman10192]

Spamming of M107 was found to be the cause of my printer locking up the extruder, X, and Y axis. The strange part was the Z and tool lock (U) axis continued to function normally while the software/UI showed the print continuing. It was as if the printer thought X and Y were moving but they physically did not.

It required a power cycle or reset of the main board to unlock X and Y axis.

Jubilee build running a Duet 3 Main Board 6HC and Duet 3 Tool Boards 1LC for each of four tools. Running Duet/RRF firmware 3.5.0 rc2.

[cdheiser]

I spent half the day trying to chase down why my part cooling fan starts oscillating uncontrollably even after a print is finished. I can confirm that the issue described here has the exact same symptoms that I've been chasing where disabling dynamic fan speeds resolves the issue.

I'm running Klipper v0.12.0-60

[bobjackman]

Guys, please upvote this if you're experiencing it.

[bobjackman]

related: #11856

[4res0]

Same problem.
PrusaSlicer 2.7.2
Klipper v0.12.0-102

[DementevAlex]

Also having this issue on Ender 3 with Klipper.
Just printed a model with multiple bridges in a row. The fan stopped spamming almost at the end of a whole layer.

I think there should be some kind of averaging algorithm preventing fan to change speed faster than its kick_start_duration (which should be setup in slicer to be equal the value from klipper).

[awabom]

Still happening in PS 2.8.0

[Felix14-v2]

In my scenario, this issue causes my fan to complete deadlock on overhangs – it just can't start cooling after that.

[lukasmatena]

Fixed in 2.8.1-rc1. Closing.