# Constant cycling of part cooling fan, fan uncontrollable **URL:** \ **Category:** General Discussion\ **Created:** [September 2, 2024, 12:36am UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602 "2024-09-02T00:36:36Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![yodor1](https://avatars.discourse-cdn.com/v4/letter/y/919ad9/32.png) [@yodor1](https://klipper.discourse.group/u/yodor1)\ **Post date:** [September 2, 2024, 12:36am UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/1 "2024-09-02T00:36:37Z")
### Basic Information: Printer Model: delta/custom MCU / Printerboard: SKR 3 EZ / STM32H723, SKE Pico Host / SBC : RPI zero 2W klippy.log ### Describe your issue: Klipper loosing control on the part cooling fan. Fan continues cycling after print is done and M106 is unable to control it. I was able to sample specific gcode for testing and uploading it here. After the attached gcode is executed fan is in constant cycling state and can not be controlled from mainsail or from sending M106 commands. I have tried setting various cycle\_time values in config but not helping also tried hardware\_pwm true/false. Attached gcode contains only M106 commands so you can test without actually printer doing any movement or extrusions. [fanonly.gcode.zip](https://klipper.discourse.group/uploads/short-url/nETsjTOWVleMM9zVy5EUMXEz2yk.zip) (114.5 KB) I’ve also tested on other printer with SKR PICO board and the problem is the same. Anyone having this issue ? [klippy.log.zip](https://klipper.discourse.group/uploads/short-url/tbaKtSF970wP93K69RQtZlesMIK.zip) (48.7 KB) ---
**Author:** ![EddyMI3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/eddymi3d/32/1981_2.png) [@EddyMI3D](https://klipper.discourse.group/u/EddyMI3D)\ **Post date:** [September 2, 2024, 6:02am UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/2 "2024-09-02T06:02:19Z")
Hello @yodor1 ! You may try this: ```auto [fan_generic fan] pin = HEATER1 hardware_pwm = false cycle_time = 0.01 kick_start_time = 0.250 ``` ---
**Author:** ![yodor1](https://avatars.discourse-cdn.com/v4/letter/y/919ad9/32.png) [@yodor1](https://klipper.discourse.group/u/yodor1)\ **Post date:** [September 2, 2024, 11:36am UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/3 "2024-09-02T11:36:47Z")
This is the part cooling fan, if I set the section to fan\_generic it will not respond to M106 at all, but if you mean just to try the other settings I’ve tried and the issue is still present. Tested using this [fan] pin = HEATER1 hardware\_pwm = false cycle\_time = 0.01 kick\_start\_time = 0.250 Also tested in different pin and is the same, seems to me some timer code gets wild ---
**Author:** ![EddyMI3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/eddymi3d/32/1981_2.png) [@EddyMI3D](https://klipper.discourse.group/u/EddyMI3D)\ **Post date:** [September 2, 2024, 12:00pm UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/4 "2024-09-02T12:00:44Z")
According to this: ![grafik](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/f/fb92d3374c370b60216d06188ce1071cdf705239.jpeg) And this ```auto [board_pins] aliases = EXP1_1=PC5, EXP1_3=PB1, EXP1_5=PE9, EXP1_7=PE11, EXP1_9=, EXP1_2=PB0, EXP1_4=PE8, EXP1_6=PE10, EXP1_8=PE12, EXP1_10=<5V>, EXP2_1=PA6, EXP2_3=PE7, EXP2_5=PB2, EXP2_7=PC4, EXP2_9=, EXP2_2=PA5, EXP2_4=PA4, EXP2_6=PA7, EXP2_8=, EXP2_10=, HEATER0=PB3, HEATER1=PB4, HEATER_BED=PD7, FAN0=PB7, FAN1=PB6, FAN2=PB5, ``` and this: ```auto [fan] pin = HEATER1 hardware_pwm = false cycle_time = 0.01 kick_start_time = 0.250 ``` You are controlling the fan as the heater. You should do: ```auto [fan] pin = FAN1 # (or FAN2, accordingly where you it connected to) hardware_pwm = false cycle_time = 0.01 kick_start_time = 0.250 ``` ---
**Author:** ![yodor1](https://avatars.discourse-cdn.com/v4/letter/y/919ad9/32.png) [@yodor1](https://klipper.discourse.group/u/yodor1)\ **Post date:** [September 2, 2024, 2:55pm UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/5 "2024-09-02T14:55:03Z")
yes pin is quite correct as I said I also tested on other board/printer with skr pico and the issue is the same The issue is present on whatever pin I connect the fan to. Also on the other board with different fan is still the same. ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [September 2, 2024, 8:06pm UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/6 "2024-09-02T20:06:55Z")
I’m not sure that I understand what you are reporting here. For me, it looks like: - You are flooding Klipper with `M106`. Either intentionally as shown in the example Gcode or unintentionally due to a slicer bug - It is known that a flood of `M106` commands will eventually kill Klipper as it is blocking its queue - In the first place, this is not considered a bug, since you can - The provided `klippy.log` does not match the described behavior. In the log, Klipper shuts down with `MCU 'mcu' shutdown: Command request`, which is indicating that Klipper received an Emergency Shutdown command - When Klipper shuts down due to an error or emergency stop, it is normal and expected that the fans can no longer be controlled and run at full speed to prevent further damage ---
**Author:** ![yodor1](https://avatars.discourse-cdn.com/v4/letter/y/919ad9/32.png) [@yodor1](https://klipper.discourse.group/u/yodor1)\ **Post date:** [September 2, 2024, 11:57pm UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/7 "2024-09-02T23:57:46Z")
Thanks @Sineos, The gcode attached is part of a real gcode file (big enough). I’ve intentionally extracted only the M106 commands so it is easy to replicate and demonstrate the issue. I can understand that so much changes one after another are not in real use, but still this is not quite correct to me as after entering the cycling state it never goes outside of it - queue should get to its end. I’ve manually input M112 right after triggering the issue - this was suggested from klipper documentation - so it is more easy to debug the MCU state - other than that printer does not go to shutdown. So unresponsive fan is not because of shutdown state. I’ve left the printer on idle while fan is uncontrollable for a lot of time (queue should have gone to the end for that time I think) Here is klippy.log in the error state without M112 [klippy-no-m112.log.zip](https://klipper.discourse.group/uploads/short-url/93pZU3rQ2RV1LOVMNFiqCn71ZFX.zip) (7.9 KB) If you need the full gcode not just the M106 I can provide ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [September 4, 2024, 8:06am UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/8 "2024-09-04T08:06:57Z")
> [@yodor1](#): > > I can understand that so much changes one after another are not in real use, but still this is not quite correct to me as after entering the cycling state it never goes outside of it - queue should get to its end. If we just bluntly calculate 100 ms each update (as stated in the PR above) then your gcode file will keep Klipper busy for around 6 hours. Just to reinforce - it is a printer’s firmware duty to execute each command in the correct sequence and at the correct time. It is absolutely not its duty to “interpret” gcode, to second guess it or to try figuring out what could have been the intention. It is the slicers duty to produce meaningful gcode that respects the needs of the printed object, e.g. overhangs, bridges etc, and gcode that can actually be fulfilled by the respective hardware. If the slicer creates a senseless amount of commands that cannot be fulfilled regarding the needed timings and cannot be fulfilled regarding the hardware (a fan just cannot change its speed multiple times a second) then it is a slicer bug. If you force the firmware now to drop such commands in order to not create even more issues, then it is really bad as the firmware cannot know, which is the important command that is reflecting the initial intention. ---
**Author:** ![yodor1](https://avatars.discourse-cdn.com/v4/letter/y/919ad9/32.png) [@yodor1](https://klipper.discourse.group/u/yodor1)\ **Post date:** [September 5, 2024, 4:22am UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/9 "2024-09-05T04:22:51Z")
Thanks for stating your point of view clearly @Sineos. I dont want to enter the endless slicer vs firmware bug discussion but anyways I’m no klipper internals expert. Thought it might be a good idea to share the issue here as the behaviour of klipper seems wrong to me at first. If its made to work like this so be it I can live with it. ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [September 27, 2024, 12:45am UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/10 "2024-09-27T00:45:39Z")
FYI, the fan changes in PR #6670 (and PR #6688) were committed. This should make Klipper more resilient to excessive slicer fan speed changes. -Kevin ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/klipper/original/1X/64419bf2aac6639e6ef5cef200dcd456b0a01ac3.png) [@system](https://klipper.discourse.group/u/system)\ **Post date:** [November 26, 2024, 12:46am UTC](https://klipper.discourse.group/t/constant-cycling-of-part-cooling-fan-fan-uncontrollable/18602/11 "2024-11-26T00:46:09Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.