Interesting. I have just connected Noctua fan (via 74AHCT125 - QUAD LEVEL-SHIFTER) to GPIO19 (it is supposed to be one of the hardware PWM pins), and it seems to work well. I haven't attached the scope, but there's clear difference between say 20% and 100% duty cycle. I can turn off the fan with 0% duty cycle, so everything seems to be working fine.

What does it do in your case?

Interesting. I have just connected Noctua fan (via 74AHCT125 - QUAD LEVEL-SHIFTER) to GPIO19 (it is supposed to be one of the hardware PWM pins), and it seems to work well. I haven't attached the scope, but there's clear difference between say 20% and 100% duty cycle. I can turn off the fan with 0% duty cycle, so everything seems to be working fine.

What does it do in your case?

In my case when set to anything greater than 0% the fan does not maintain a constant speed but by the sound seems to run close to 100%, it "revs" - runs high than slows down. I didn't use a 74AHCT125 since the Noctua PWM specifications white paper indicates that one isn't needed. I did not connect a scope probe to the fan's tach output. I stuck with the default pwm hardware pins to hopefully maximize my success.....

Well, this is what most people struggle with. The documentation says:
External pull-up is not necessary as the signal is pulled up to 3,3V/5V inside the fan.

People discuss this a lot on various forums as it is unclear which number it is, but if it is 5V, it could damage your Pi. Generally they recommend to use level shifter and convert it to 5V PWM signal. So I did. The circuit costs close to nothing, and can be easily ordered from sites like DigiKey.

With that, my NOCTUA NF-F12 industrialPPC-2000 PWM runs fairly smooth and can be regulated without any issue.

Unfortunately I don't have a scope, so I can't check what's going on on the pin when it runs.

This is how I wired it (it also shows relay controlling LED strips and DHT sensor to measure temperature)

I'm convinced that the quad level shifter is not necessary. I did some more readings this morning. These tests were performed using HardwarePWM with a Noctua NF-A14 iPPC-3000 PWM in circuit:
Voltage measured with my scope: 3.3v at multiple duty cycles.
Current measured with a multimeter in circuit and hardwarePWM set to 100% duty cycle: 20 µA.
The Pi GPIO should be able to handle this without issue.
As I mentioned before, with Octoprint-Enclosure the upper frequency limit appears to be just above 5 kHz. Using the same circuit and the same GPIO pins, hardwarePWM sets the frequency correctly. This is either a configuration issue unique to Octoprint-Enclosure or a compatibility issue between Octoprint-Enclosure and the Pi 4 B.
I'm using a Raspberry Pi 4 B. Are you using the same?

So, today I'm basically using https://sourceforge.net/p/raspberry-gpio-python/wiki/PWM/, no changes what so ever.... not a custom driver or anything...

Could you please write a small script and test if that can make your pi

p = GPIO.PWM(channel, frequency)
p.start(dc)   # where dc is the duty cycle (0.0 <= dc <= 100.0)
p.ChangeFrequency(freq)   # where freq is the new frequency in Hz
p.ChangeDutyCycle(dc)  # where 0.0 <= dc <= 100.0

It might be a limitation on that library.... I'm adding support on PWM from I2C chips on python 3... so need to find a chip that has 25kHz....

Guys, you are forcing me to buy a scope and check what's going on with my fan that it works :-)

Anyway, people recommend to use https://github.com/joan2937/pigpio, that should be capable of the desired frequency.

Some information here:
https://www.raspberrypi.org/forums/viewtopic.php?t=244194&start=25

I saw that library, never used, will install and run some tests, I'm interested to see if requires sudo or any special permission because that is also a major issue with the enclosure and setup for most users...

if @wmonzel could test hist pi, default library, and measure the frequency would be nice.... I'll work more on the plugin tonight...

@haplm : hardwarePWM does use PiGPIO, so I think you're on to something. I didn't realize that octoprint-enclosure did not.
BTW it occurred to me that the max current draw would be with a 0% duty cycle. I've checked and the current only goes up to 51 µA at 0%.
@vitormhenrique: I'll be glad to run that script, but it will have to be in the morning. I want to make sure I've disabled hardwarePWM and possibly PiGPIO too.

Thank you both for your help.

@vitormhenrique I haven't taught myself python yet, so I'm probably doing something wrong. My test script pwmtest.py:
p = GPIO.PWM(channel, frequency)
p.start(0) # where dc is the duty cycle (0.0 <= dc <= 100.0)
p.ChangeFrequency(25000) # where freq is the new frequency in Hz
p.ChangeDutyCycle(20) # where 0.0 <= dc <= 100.0

Results:
pi@octopi:~ $ pwd
/home/pi
pi@octopi:~ $ python pwmtest.py
Traceback (most recent call last):
File "pwmtest.py", line 1, in
p = GPIO.PWM(channel, frequency)
NameError: name 'GPIO' is not defined

What basic steps have I missed?

I looked into raspberry-gpio-python and there is a ticket: https://sourceforge.net/p/raspberry-gpio-python/tickets/173/ that indicates that gpio-python implements software pwm only. Software pwm doesn't seem like a good idea at higher frequencies.

@vitormhenrique OK, I figured out that some initialization was in order: Import RPi.GPIO, GPIO.setmode, GPIO.setup. I can provide the updated test script if you like.
I tired several different frequency settings and came up with the following results. I did not bother changing the duty cycle (all tests run at 20%) since the waveform duty cycle appeared to be fairly stable.

This generally agrees with my earlier observations with Enclosure.

@wmonzel my bad, my script was more a pseudo code than a copy paste and run, but glad to know that you figured it out how to get it running...

as I thought the issue is more on the library than actually on the enclosure plugin...

We need to test with pigpio and see if that is better pip install pigpio

User guide here: http://abyz.me.uk/rpi/pigpio/python.html#set_PWM_frequency

and the circuit python Adafruit library that I planed to use for python 3 port:

https://github.com/adafruit/Adafruit_CircuitPython_Motor

@vitormhenrique no worries regarding pseudo code. I could use to learn python. Since hardwarePWM uses pigpio, the tests I've run with hardwarePWM should be good enough to validate pigpio's effectiveness. The output waveform with hardwarePWM is very stable and accurate. I have not compared CPU load but it's a safe bet that using hardware pwm beats software pwm in this area - another advantage for using the hardware pwm gpio pins. I strongly suspect that the waveform stability of a software implemented pwm will further suffer as the CPU load increases, especially at higher frequencies.

I use hardwarePWM as a work around to control my enclosure fan. But I've yet to figure out a way to use hardwarePWM to control fan speed based on some other variable, like temperature. That's where your plug in shines. Right now I periodically monitor the enclosure temperature and adjust the fan speed accordingly.

I'm not sure what you gain by using the circuit python Adafruit library (hardwarePWM doesn't seem to use it), but I do know that hardware based pwm is only available on GPIO12, 13, 18, and 19.

It is weird. The enclosure plugin suddenly lost the ability to control the fan, and I had to install pigpio + hardwarePWM. That works just fine...

Hi @vitormhenrique,

I've modified handle_pwm_linked_temperature to use PiGPIO instead of raspberry-gpio-python and have run a few prints with good results. The change within handle_pwm_linked_temperature is to call a new function write_hwpwm instead of write_pwm. Within init.py I also added the necessary "import pigpio" and two small functions (modules? Sorry, I'm still learning Python so I may not be using the right terms) write_hwpwm and startHWPWM. All other sections of your code are unchanged and continue to use RPi.GPIO. I didn't even have to disable the hardwarePWM plugin, I just left the duty cycle at 0. I plan to do some more testing but wanted your input since you mentioned that you are working on a major rewrite. Is this something your are interested in? At the moment I've made the changes outside of Git, so I would either need to attach the file here or go through the normal Git process.

@wmonzel could you please share your changes?
I am also interested in that because with my Arctic PWM FAN I have a really high gap between 0 % and 1 % when using this low PWM frequency.

@wmonzel could you please share your changes?
I am also interested in that because with my Arctic PWM FAN I have a really high gap between 0 % and 1 % when using this low PWM frequency.

Hello @darkcheater, sorry for the delayed response. I just noticed it last night.
One file has changed: __init__.py. I've cloned the repo under my name and created a fork with the change. Hopefully you will be able to see it. This is based on @vitormhenrique 's current push. If your current copy of __init__.py is different let me know.

Notes:

• OctoPrint-Hardwarepwm is required optional but recommended. See https://plugins.octoprint.org/plugins/hardwarepwm/
• Like Octoprint-Hardware, this change requires the PIGPIO Library. See the Oct 20 2020 note from @haplm for installation tips.
• The code is set up for one use case only - Temperature controlled Hardware PWM. All other Enclosure settings are unchanged. Any other PWM device will continue to use the existing software based PWM.

@wmonzel
I am using the enclosure plugin to control many hardware pwm pins which i realised dont work with RPi.GPIO. I too tested OctoPrint-Hardwarepwm plugin for my LED strip light and all the flickering is gone. With RPi.GPIO and 100% duty I still have flickering and anything less is just unusable, brightness control is off the table with RPi.GPIO. I have not tested it with my pwm fan which is linked to temperature like you did but im sure it will preform better than it currently does.

I would like to see all the hardware pwm pin available to use PIGPIO Library with the Enclosure plugin in future updates.

Hello @ahmaddxb
You might try setting the frequency to something slightly greater than 100Hz if in a 50Hz AC country or 120Hz if in a 60Hz AC country. Something slow enough for software PWM to keep up with but fast enough to avoid detectable flicker. This would allow you to keep using RPi.GPIO. The difficulty with just switching to hardware based PWM is that it is only available on GPIO12, 13, 18, and 19.

I'll have a look at possibly expanding what I've done within my own branch (wmonzel/OctoPrint-Enclosure) and will let you know if I have something worth testing.