Constant cycling of part cooling fan, fan uncontrollable

General Discussion
1

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 (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 (48.7 KB)

2

Hello @yodor1 !

You may try this:

[fan_generic fan]
pin = HEATER1
hardware_pwm = false
cycle_time = 0.01
kick_start_time = 0.250
3

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

4

According to this:

grafik
grafik1269Ă—867 195 KB

And this

[board_pins]
aliases = 
	
	EXP1_1=PC5, EXP1_3=PB1, EXP1_5=PE9, EXP1_7=PE11, EXP1_9=<GND>,
	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=<GND>,
	EXP2_2=PA5, EXP2_4=PA4, EXP2_6=PA7, EXP2_8=<RST>, EXP2_10=<NC>,
	
	HEATER0=PB3, HEATER1=PB4, HEATER_BED=PD7,
	
	FAN0=PB7, FAN1=PB6, FAN2=PB5,

and this:

[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:

[fan]
pin = FAN1 # (or FAN2, accordingly where you it connected to)
hardware_pwm = false
cycle_time = 0.01
kick_start_time = 0.250
5

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.

6

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

    1. Also keep Klipper busy with other commands
    2. Multiple (some slicers hundreds) of M106 commands in a row is rather considered a slicer bug than a firmware bug, as these commands serve no practical reason → No fan on this planet can follow multiple speed changes in a second, simply due to electrical and mechanical constraints
    3. Efforts are on their way to mitigate such faulty input. See Queue and collate fan requests (and output_pin and servo) by KevinOConnor · Pull Request #6670 · Klipper3d/klipper · GitHub

  • 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

7

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 (7.9 KB)

If you need the full gcode not just the M106 I can provide

8

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.

9

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.

10

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

1 Like