[BUG] FAST_PWM_FAN_FREQUENCY exception bug

[trengtor]

Did you test the latest bugfix-2.0.x code?

No, but I will test it now!

Bug Description

When you commented #define FAST_PWM_FAN_FREQUENCY with enabled FAST_PWM_FAN option it may cause to fan damage. In the code does not provide (forgotted) handling for such a situation. At the same time, everything is compiled without errors and warnings.

See screenshots




.

Bug Timeline

No response

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

2.0.8.2

Printer model

No response

Electronics

No response

Add-ons

No response

Bed Leveling

No response

Your Slicer

No response

Host Software

No response

Additional information & file uploads

I am not planning to test this on a bugfix. Just check the code yourself. Today I encountered such a situation with one of the users of Marlin.

[trengtor]

It's necessary to explicitly assign 500 Hz (for example) when FAST_PWM_FAN is enabled and FAST_PWM_FAN_FREQUENCY is not specified

[descipher]

Currently if you optionally enable FAST_PWM_FAN and have not validated the desired correct frequency for the target it will use the default frequency which is approximately 32Khz.

It is quite possible that this frequency could be wrong for the target and may even damage a fan that cannot handle that default.

So are we requesting a different default or that the user MUST specify one in order to run FAST_PWM_FAN?

Keep in mind that the same issue can occur in either case.

[robbycandra]

It is already done in Conditional Post

/**
 * FAST PWM FAN Settings
 */
#if ENABLED(FAST_PWM_FAN) && !defined(FAST_PWM_FAN_FREQUENCY)
  #define FAST_PWM_FAN_FREQUENCY ((F_CPU) / (2 * 255 * 1)) // Fan frequency default
#endif

[descipher]

It is already done in Conditional Post

Yes thats where it is set if already not defined. The question to this submission is more about what is the expectation for most fan use cases. I can say that most fans will likely not function at that frequency or higher and depending on the MOSFET it could overheat at the default.

[trengtor]

Currently if you optionally enable FAST_PWM_FAN and have not validated the desired correct frequency for the target it will use the default frequency which is approximately 32Khz.

It's can be very high frequency & may damage coolers. I think need to reduce this default number.

[descipher]

I agree, however 500Hz is quite low for a “Fast” PWM the STM32duino library defaults to 1KHz and thats much less likely to result in a scenario where a small MOSFET heats itself to death. I will setup a PR to address this issue by using the library default instead. We have other observations that indicate there is a risk of human error when setting fast PWM.

[trengtor]

I agree, however 500Hz is quite low for a “Fast” PWM the STM32duino library defaults to 1KHz and thats much less likely to result

Thanks!

[descipher]

For any one with a BTT SKR MINI E3 V2
FAN 0 and FAN 1 are driven by a small low current MOSFET .
6Z MMBF170 Mot M SOT23 tmosfet n-ch Vds 60V 0.5 A
They can be easily damaged by high frequency since they cannot dissipate much heat in a SOT23 package.

[thinkyhead]

Are there any boards or MCUs which may be better off with the current FAST_PWM_FAN_FREQUENCY value ((F_CPU) / (2 * 255 * 1)) or is it safe to assume 1kHz across all hardware?

Ref: #12638

[descipher]

It would be highly unusual for any hardware we drive to set it from 32k to 320kHz as usable for a typical fan. 1kHz is a very good proven default for all boards. If there is a need for higher it would normally already be set via the fast fan pwm frequency define.

[thinkyhead]

1kHz is a very good proven default for all boards

The trouble with 1kHz as a default is that it is in the audible range, and this can produce a noticeable whine with some fans. So ideally, the default should be something above the audible range for MCUs that can manage higher frequencies.

[descipher]

While thats true, this PR’s intent is to protect the hardware from an absence of configuration and not to complete it when users are not aware that the frequency must be specifically set to support the target board. Unfortunately we cannot go above the audible range and guarantee it will not damage components by default. Even at 18kHz we can destroy the common MMBF170 if the wrong type of load is connected. Each fan type will have its own set of response characteristics and I think that should be handled by the configuration files for a specific target. Yes this change could have undesirable audible sound but undesirable damaged component is a much more serious problem. If we have common targets that already have the feature enabled it should be easily identified and we can set the define to match the previous default. I will do a scan for them tomorrow and update this discussion.

[descipher]

Ditto from the PR

Based on the config files in all of github almost all of the target boards have no configuration except for the conditionally derived ones. Where the CPU is non AVR and FAST_PWM_FAN was enabled the config value was set to 31400Hz. So in reality the default is 31400 where it was in use with fan types that can support it.

The default can still damage a target that is not designed to handle the 31400 value.

So it would appear that the majority of failures where damage occurs is when the conditional calculates to values higher than the 32kHz range.

Thus there is no single way to resolve the issue completely and it becomes the lesser of two evils. Which is to do what you have already done with the current edits in the PR.

[thinkyhead]

…if the wrong type of load is connected…

Do you mean, something like a -2.5V / +2.5V load instead of a GND / 5V load ?

[descipher]

Some fan circuits are highly capacitive and this results in high current spikes. If the spike level exceeds the mosfet current rating it will likely be damaged at higher frequency.

[robbycandra]

@descipher, I am curious, which one takes more computing resource, SOFT_PWM or FAST_PWM?

[descipher]

Software based pwm uses more compute. Fast pwm just sets the hardware timer to generate the pulse width and frequency on a specific pin.

[robbycandra]

But we already use software pwm for temperature control. Is add one more pin on the soft pwm loop still take more computing power than using hardware pwm?

[descipher]

Yes hardware pwm is still less compute.

[robbycandra]

I see... Thanks.
So FAST_PWM_FAN has its own benefit. Less Computing Power and Higher frequency. It is not good for the heater and fan, but I think there are other things that can use FAST_PWM using FAN pins, maybe like LED.

So I prefer not to force FAST_PWM to be used on a fan. And let the FAST_PWM go FAST.

Why not just add a warning that FAST_PWM is not suitable for a fan?

[tpruvot]

its required for fans, without it even tiny ones do coil noise at 1kHz... but yea, 32kHz may be higher than required... also the same 4cm/24V fan doesn't do (electric) noise with SOFT_PWM

to note:

but yea, at 1kHz imo its not the real frequency noise you hear... the coil whine is very high in freq...

[robbycandra]

@tpruvot, yes SOFT_PWM runs very well on my fan.

[tpruvot]

8 to 16k should be a better default.... but 1k default imo its wrong... for FAST_PWM which is only meant to do more than 1kHz... FAST_PWM does not mean Hardware PWM.... without any define, its 1kHz Hardware PWM, nice for leds

[descipher]

Well it's not a configuration default, it is a default to use when its not configured thus protecting users from self harm.

[descipher]

The default is 31400 and it is commented out.

[robbycandra]

@descipher, After reading your comment, I push a PR to add a warning. Please check.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.