Prusa-firmware: Hi Pitch noice coming from print fan

Created on 4 Feb 2018  ·  98Comments  ·  Source: prusa3d/Prusa-Firmware

When the print cooling fan come on there is a high pitch noise. I believe this is cause by the high frequency PWM signal going to the FAN.

Most helpful comment

I also noticed that my fan range became prohibitively narrow when enabling FAST_PWM_FAN out of the box. I ended up setting the prescaler on the timer to 1024. If my math is correct, that generates a frequency of about 60hz. I can't hear the fan at all now, and the operating range seems to have even increased a smidge.

If someone else wants to give this a try, enable FAST_PWM_FAN in Configuration.h and change line 1054 in temperature.cpp:
// setPwmFrequency(FAN_PIN, 1);
setPwmFrequency(FAN_PIN, 5);

All 98 comments

On other Marlin-based printers I have fixed this by switching the part fan from hardware PWM to software PWM, which has a lower frequency and thus much less objectionable noise. I don't know if the Einsy has enough CPU power left over to run the fan on software PWM though, or if the Prusa FW still has the functions needed to run software PWM.

the "high pitched noise" the two here are talking about is the fairly sound of a fan, as demonstrated in this video:
https://youtu.be/F4h4cWm9g6o

perhaps there is room for improvement here.

@jettoblack Increasing the PWM frequency so it will be outside the audible range can also get rid of the issue without the need of using software PWM. In Marlin this feature can be enabled by uncommenting the line #define FAST_PWM_FAN in Configuration.h. This has the side effect of the fan MOSFETs running a bit hotter due to switching losses, with most controller boards that shouldn't be a problem though.

Just received and assembled my MK3. I noticed this distinct PWM whine when printing PETG, where the fan speed is "76". If tuning the speed to "255" (full speed) the noise disappears.
Firmware is 3.1.3-245 (stock)

This tip helped with the noise but after 8h of printing I got "print fan error" and had to stop the print. Maybe fan MOSFET overheated?

This is really driving me insane, have a bunch of print I need to print in PETG and after 4 hours I had to abort the process, the constant whining is unbearable.

Same here. Have the mk3 kit-version and I thought I made a mistake during built-up. First time printing PETG now, and although printer is encased, the whining sound is really driving me nuts.
I hope prusa will fix this issue soon.

+1

I have the same problem with my MK3 when printing PETG. The sound is really annoying.

I have nothing to add except a "me too" with the hope that more people means more attention from Prusa. I have completely stopped using the fan when printing with PETG and either completely avoid bridging or clean up nasty/fallen bridges afterward.

The whine is unbearable, I can hear it throughout my house. From the basement to the attic. Only when printing PETG.

I get this too. Sometimes its worse than others. It's definitely louder than it was when the printer was new. Matter of fact I get allot of odd noises that I didn't get when it was new.

I have this too on my brand new MK3. Sadly in my humble opinion its just nature of PWM, I doubt that it can be fixed.

New MK3 printer here arrived this week, same problem. with PETG it's really bad

Same here, glad I'm not the only one with this issues where the fan whines around 50% but gone at about 100%

In the same boat here, would print ABS without a fan and PLA with layer fan at 100%, but switching to PETG I was amazed how loud this problem manifests compared to the general printer operation sound.

Same here. At first I thought it was an issue with the filament sensor or the pinda probe, but soon discovered it was the fan. Voted up the issue in hopes that the firmware team can do something about it.

This seems to work with no PWM noise, though probably far from the right way of doing it

#define FAST_PWM_FAN in Configuration.h

Then fix the scaling of fan speed

I just tested the unscaled fan operating range which seemed to be about 100-118 on my unit and botched a scaling to the M106 command processing in Marlin_main.cpp:

fanSpeed=constrain(code_value(),0,255);

changed to something like:

if (code_value() > 0)
    fanSpeed=constrain(code_value() * 18 / 255 + 100, 0, 255);
else
    fanSpeed=0;

In case of fan speed errors either increase the MIN_PRINT_FAN_SPEED to e.g. 106. (in Configuration_prusa.h), or disable fans check.

This is a workaround, correct way would be to set the pwm timer frequency after enabling fast pwm(?)

I have the same issue when printing PETG. Really annoying!
Kit Printer from June 2018

Demo video: https://www.youtube.com/watch?v=Rf2mNBXZXNA

The noise is from power being applied to the fan out-of-sync with motor commutation, and from power being applied unevenly (PWM is "spikey").

Generally, intelligent fan control will cost additional CPU overhead. Typically a dedicated micro is used for this. [It is really easy to do with a tiny PIC12F1840, for example.]

Sync is easy to solve, as every motor commutation generates a tach pulse. However, the tach signal should never be monitored while doing PWM, as there is a huge amount of hash on the signal.

Instead, to measure rotor RPM, for example:

  1. Apply full power (100% duty).
  2. If not in sync, ignore the tach edges for say 500 ms (usually very noisy, or incomplete).
  3. Wait for next tach state change and start a timer (pulse is clean - can sync to it). This pulse edge can also be more accurately located by a prediction window based upon the sync timer.
  4. Wait for next tach state change.
  5. Wait for next tach state change and stop the timer (one pulse period measured).
  6. Restore the PWM control level.
  7. Calculate the rotor speed from elapsed time (two tach pulses per revolution, so twice the measured period).

The rotor will not appreciably speed-up at full power for only a revolution or two, because of rotor inertia and aerodynamic drag. An internal PWM timer can be re-synced to the rotor, say every 100 revolutions (or more).

A good write-up with scope pictures is at http://www.pcbheaven.com/circuitpages/PWM_3_Wires_Fan_Controller_with_RPM_feedback/

The PWM power signal can be smoothed via dithering. This technique is commonly used to prevent LED lights from blinking at low PWM duty-cycles, and valves from sticking or solenoids moving during PWM dead-time.

Example: 50% duty cycle applies power over 8 intervals as 00001111. That can be dithered into 01010101, same ratio of on and off periods, but much more consistent power application (dead-time spread-out). Ideally a random distribution is used, rather than a repeating constant pattern, to further avoid any artifacts which might be audible.

A simple phase accumulator based (repeating pattern) dithering write-up of mine: https://stackoverflow.com/a/35859455

Same problem :( New fan on the way but its not the solution :(

One more for this very annoying noise , even 255 I have whining , Prusa please fix this

Same issue here. Replacement fan sent by PRUSA did not help.
Video https://drive.google.com/open?id=19QZF4HUR_tc4dW9Y62HQfnHJHeYSrEhl

same as all

Same issue here. Kind of makes all the claims of noise reduction out to be a bit of false advertising. Sounds like a fairly easy fix. Please do so!

Same here with a new MK3. Prusa, is it a fan issue and it has to be replaced?

@bamminger it is not a hardware problem so a new fan won’t fix it. They need to make a change to the software control of the fan speed.

Ok thanks, let's hope they fix it 😒

Are we sure it doesn't require a hardware change in the PCB though? I want
to imagine that if it were just a simple software fix it would be fixed by
now.

On Wed, 15 Aug 2018 at 19:37, Jochen Bamminger notifications@github.com
wrote:

Ok thanks, let's hope they fix it 😒


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/460#issuecomment-413360882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHsVQbAvvFURcW0ff-irUKKjyu7cFWcks5uRKKQgaJpZM4R4sVy
.

^ I have been printing for couple months with fast_pwm enabled without issues.

@miksumortti noob questions, but do I need to append a value to the end of #define FAST_PWM_FAN after uncommenting it and how did you measure the unscalled fan speed to get to the values you did?

@WannabeSpaceman Only uncomment. I uploaded the firmware to printer and changed the fan speed manually (settings->temperature->fan or M106 command through usb) to try at which value range the rpm of the fan changes.

Just in case Prusa are watching / taking notes here is a question for you. If its a software / firmware fix - can it be done or not? if it can be done why has Prusa not done it yet? and if it cant be done why haven't Prusa told us yet?

@miksumortti I have uncommented #define FAST_PWM_FAN in Configuration.h. How I'm supposed to find "unscaled fan operating range" on my Prusa MK3 ?

Was trying with your values in Marlin_main.cpp but got Fan Error.
Fan itself was operating on high speed values, on smaller it was trying to start but couldn't or didn't reacted at all.

With only define change, fan was throwing Error or same symptoms as above.
This issue is really annoying.. I mean I can't even hear my printer EXCEPT those crazy whines from print fan :|

At the other hand, it's sad that Prusa team is ignoring it.

@lenisko Low fan speed values will cause fan error due to the improper scaling method. Correct way would be to set the pwm timers frequency (?), so that the rpm calculating would also be right.
Also as the scaling is applied just to the gcode command, the printer settings fan speed input is not scaled.

Either increase the MIN_PRINT_FAN_SPEED to e.g. 106. (in Configuration_prusa.h), or disable fans check.

@miksumortti thank you for explaining this, I wanted to check changes but couldn't go through calibration process it's failing on XYZ calibration where Y calibration is trying to bench my left side of printer - it's ignoring home location I thin... had to reset and flashed old firmware back again.
I'm 100% sure that I have changed only:

  • #define FAST_PWM_FAN
  • #define MIN_PRINT_FAN_SPEED 112
  • and changed fanSpeed=constrain(code_value(),0,255); to
if (code_value() > 0)
    fanSpeed=constrain(code_value() * 18 / 255 + 100, 0, 255);
else
    fanSpeed=0;

most likely it's caused by something else but maybe you had same problem? I have also noticed big change in hex file size.

Arduino compilation log (with compiler warnings): https://pastebin.com/igbEkTxT
2018-08-27_17-18-50-clover

@lenisko Tested XYZ calibration and it went through without errors.

@miksumortti thank you for checking. Probably something went wrong with compilation process on my side which is weird as I used recommended 1.6.9 Arudino IDE and checked v3.4.0-RC1 branch. Do you mind sharing own hex file?

I tried the @miksumortti solution, but the working range of the fan is really narrow, mine goes from 111 to 119.
I tried to uncomment the following line:

#define FAN_SOFT_PWM

and everything worked fine, the whining stopped and the working range of the fan is perfect.
To compile I followed the instruction on the main page, the source code used is ver. 3.3.1

@acortellini Yep this works well and no need to waffle with fan ranges, just causes some ticking noise at the frequency of the pwm.

I also noticed that my fan range became prohibitively narrow when enabling FAST_PWM_FAN out of the box. I ended up setting the prescaler on the timer to 1024. If my math is correct, that generates a frequency of about 60hz. I can't hear the fan at all now, and the operating range seems to have even increased a smidge.

If someone else wants to give this a try, enable FAST_PWM_FAN in Configuration.h and change line 1054 in temperature.cpp:
// setPwmFrequency(FAN_PIN, 1);
setPwmFrequency(FAN_PIN, 5);

@surrealseven Good catch! The behavior is the same, but without the overhead of generating the PWM pulses. The fan range is very similar, the click in the fan is present in both solution, but I really don't mind, before I can hear the wining to rooms away...
I"ll go with your solution.
Thanks

What about a low pass filter in series with the fan? This could smooth out the DC voltage. But I don't know whether adding a filter could damage the Einsy.

Sure you can install a filter, don't worry about the drivers, those chip are protected against everything. here the data sheet of the mosfets.
https://www.onsemi.com/pub/Collateral/NCV8402D-D.PDF

This has been driving me nuts for a while... the whining fan, from the PWM...

@acortellini thank you for precompiling that firmware w/fix.

Now, if prusa will incorporate that...

@haleypearse I don't see how a low-pass filter, such as a RC filter would damage the einsy in any way... but to be sure, one method could be put an opto isolator in between, thus shielding the einsey...

@acortellini did you use @surrealseven 's fix? or are you using your firmware? What's performing better?

I'm using @surrealseven proposed changes, everything cool and quiet from flashing time :-) clicking noise is not disturbing at all.
I'm leaving compiled __3.4.0-RC2, MK3 variant__ with fan changes only:
Prusa-Firmware-3.4.0-RC2-fan-changes.zip

The two solutions ave the same effect on the fan, but I'm using the @surrealseven mod because the PWM signal is generated internally by the CPU, the soft PWM is using CPU power that can useful elsewhere. It's about a week end everything is fine printing mostly PETG.

Note to anyone following along with this...

@acortellini's firmware, fails self test (at least it did for me).

@lenisko 's firmware, self test passes. Thanks @lenisko ! 👍

I removed my firmware mod, please use @lenisko 's firmware.

@lenisko do you I am not able to see a fork of the project under your account? can you post a diff of your changes?

i've compiled the latest firmware (3.4 final) enabling FAST_PWM_FAN. fan noise is gone! BUT - performed the xyz calibration, noticed the z value in the display only shows a question mark (Z=?). hence i'm unable to do live z adjust as i have no idea what the current z value is - it stays stuck at "Z=?".
i'm using source code downloaded from the 3.4 firmware release page. i've since reflashed their precompiled hex and z value displays as normal. i'm compiling for mk2.5. any idea what i'm doing wrong?

LeifSbr Is it a stock MK2.5 or do you have a mod with higher Z?

My assembled MK3 makes the same noise and Prusa says it's the power unit.

@WilkoV an easy way to test if it is the print fan is to go into the tune menu while a print in running and adjust the fan to 255 (which is 100%). if the noise stops. it is this problem

if you are running octoprint you can test it without starting a print by sending M106 75 which is about 30% fan speed. then a M106 255 to hit the 100% mark to see if it stops whining. then send M107 to turn it off.

@3d-gussner its a stock standard MK2.5.

@Panayiotis-git muchos gracias... that did the trick! i edited the correct platfrom.txt and all is well with the world - for now.

I just started printing in PETG today and now hear this noice from the fan.
What is the solution so far?
And is LeifSbr firmware still showing the "Z=?".

yup managed to get the noise down with custom firmware.
what i did was enable the line #define FAST_PWM_FAN in Configuration.h. ymmv though - not sure what or if there are any long-term effects? it seems to work ok so far...
also managed to resolve the "z=?" issue by editing the correct platform.txt file (see above post).

Add me to another one fixed by this change.

I just put up with the horrible noise. The solution of changing the fan speed as a temporary work around worked, but I didn't want to install custom firmware, never tried a permanent change. I built a cabinet using Ikea tables and thats helped a lot.

@lenisko any chance to compile the latest FW, and put it up again for the masses?

@alpha1125 Here you go. Same changes as before MK3 variant Prusa-Firmware-3.4.0-fan-changes.zip

@lenisko have you had a change to submitted a pull request with the changes you made? In case you don't know... see: https://help.github.com/articles/about-pull-requests/

I looked for a PR on prusa's branch... was this something you are comfortable with submitting as a fix? Or are there 'risks' that I may not be aware of.

Thank you for your time and effort on this matter... it makes it sane to be in the same room as the printer.

@alpha1125 those are originally @surrealseven changes. I would like to stay out of submitting PR to prusa3d/Prusa-Firmware - so far everything is fine with my own printer, but I don't have time to make research about those changes.

Feel free to ask @surrealseven or submit them yourself.

Hi
I use Ultimaker Cura sometimes with my MK3 and i tested to import the Prusa settings for Cura and noticed that fan settings are =100% and the extruder fan don't make that evil sound printing PETG. I haven't noticed any problems with my PETG parts yet.

While we wait for a solution from Prusa, is anyone able to patch the changes from @surrealseven into 3.4.1 seeing as though it fixes stealth mode?

3.4.1 hex file firmware __MK3 variant__ with https://github.com/prusa3d/Prusa-Firmware/pull/1193 merged.
~I didn't tested it yet, will edit this message after flashing to my own MK3, later today.~
Fw and fan changes are working fine but 3.4.1 introduced a bug to OctoPrint communication - it's not working. If you care (like me) rollback to 3.4.0 for now https://github.com/prusa3d/Prusa-Firmware/issues/460#issuecomment-419594988
Prusa-Firmware-3.4.1-fan-changes.zip

I flashed this file and now my printer (MK3) fails calibration. Is there something I have to do besides unzipping and flashing?

Disregard this, the build plate was fully forward on the y-axis and it was failing to properly home (locked onto the rear left magnet as home, instead of front left).

@DrKropp I didn't checked calibration as I flashed it over my old configuration. Aside pointed changes, there's nothing else, so please check other issues related to __3.4.1__ fw. On what it failed?

Referring to @DrKropp's edited message: So the failure wasn't due to the new firmware?

Have flashed my MK3 with 3.4.1fw (fan changes) and it works fine as far as i can tell. Have printed PETG and the scream from hell sound is gone. Good job guys

The failure was not due to the new firmware. It is working beautifully and has silenced the fan on my PETG prints. Highly recommended and I hope this gets rolled into the next official update.

My error was due to overtightening the Y-axis belt pulley and fooling the printer into thinking it had hit an end stop.

Dear all, I am only printing in PETG and used the patched FW "Prusa-Firmware-3.4.1-fan-changes.hex". Which worked very well (-> THANK YOU SO MUCH!).
Now I updated to the updated, new, official FW and my fan is again louder that it could be.
Question: is there an update including the patch from "Prusa-Firmware-3.4.1-fan-changes.hex"?

Hi all, with the latest firmware 3.5 out, is there a solution to quite the fan down? The whining is giving me a headache when printing PETG

3.5.0 firmware with merged https://github.com/prusa3d/Prusa-Firmware/pull/1193

MK3 variant, not tested yet.
Prusa-Firmware-3.5.0-fan-changes.zip

3.5.1 firmware with merged #1193

Tested on my MK3, working fine, fan whining high-pitch noise gone, see no downsides for now:
Firmware 3.5.1 with 1193 merge MK3.zip

Have the same issue with my Prusa MK3, only when printing PETG!

Will flash the firmware now and test it:)

Did print a few small objects, Fan noise is gone :-D

Works against the noise here as well (3.5.1 with 1193 merge). I will report back here in case of running into issues with the firmware.

Work for me too ((3.5.1 with 1193 merge). The high pitched whine is gone, it is now a much more silent low-frequency rattling. Though I'm not sure if that might be a mechanical problem of the fan and not related to PWM at all.

Works for me too (3.5.1 with 1193 merge) . No issue with Octoprint works fine.

3.5.1 with 1193 merge working flawlessly and quietly for me as well

Hey guys, I'm new here. Can someone point me (noob) in the right direction for how to merge 1193 and 3.5.1?

@Yankee-F-Doodle https://github.com/prusa3d/Prusa-Firmware/issues/460#issuecomment-449012060
unless you are not on mk3... simplest method for you would be to follow docs to compile selected branch (3.5.1) and make changes in two files like pointed in there https://github.com/prusa3d/Prusa-Firmware/pull/1193/files. Harder? way https://help.github.com/articles/checking-out-pull-requests-locally/#modifying-an-inactive-pull-request-locally

Update : with 3.5.1 + 1193 I get weird entries appearing on the bottom of the LCD . I have seen small icon of a clock with number 32 next to it. Also seen just 102 flick on screen line and off . Very strange. The file name printing no longer displays on the screen , and I have never seen the Octoprint IP address appearing , so there are some issues here. Is it 3.5.1 or 1193 ...... Anyone know how I can help identify source of this issue ? Or do I have to reflash 3.5.1 and see what happens ?

@plug-it-in that is an issue with your build. one sec let me find the link

Thank you @lenisko , I'm using a mk3. Followed the docs and compiled 3.5.1 with 1193 changes. Confirmed fan noise is better (via gcode command in pronterface). Everything looks good with the firmware except Octoprint gets "init fail" response and timeout when trying to connect. Has anyone encountered this and been able to fix?

Update : with 3.5.1 + 1193 I get weird entries appearing on the bottom of the LCD . I have seen small icon of a clock with number 32 next to it. Also seen just 102 flick on screen line and off . Very strange. The file name printing no longer displays on the screen , and I have never seen the Octoprint IP address appearing , so there are some issues here. Is it 3.5.1 or 1193 ...... Anyone know how I can help identify source of this issue ? Or do I have to reflash 3.5.1 and see what happens ?

That is normal, even with teh stock firmware. Sometimes, random chars appear on the LCD. They will vanish again after the next full LCD update.

Thanks

Kind regards

Pete Rawlings

On Thu, 10 Jan 2019 at 10:33, haarp notifications@github.com wrote:

Update : with 3.5.1 + 1193 I get weird entries appearing on the bottom of
the LCD . I have seen small icon of a clock with number 32 next to it. Also
seen just 102 flick on screen line and off . Very strange. The file name
printing no longer displays on the screen , and I have never seen the
Octoprint IP address appearing , so there are some issues here. Is it 3.5.1
or 1193 ...... Anyone know how I can help identify source of this issue ?
Or do I have to reflash 3.5.1 and see what happens ?

That is normal, even with teh stock firmware. Sometimes, random chars
appear on the LCD. They will vanish again after the next full LCD update.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/460#issuecomment-453048439,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQxraHZcm4_oAnPAUf0J4Ye4zLWwRlZ-ks5vBxcOgaJpZM4R4sVy
.

I'm affected by this issue on my new Mk3 when running the fan at any speed bellow 100%.
I assembled the printer two days ago and updated firmware to 3.5.1-1778.

Does the 1778 build include the fix mentioned here? Because if it does, then the fix is not effective form me. Or, should I instead upload the 1193 build?

Not Shure but you can give it a try. The only thing I got so far. I got the following error Whit the self test: heater thermistor not connected. But it a shot printing fine.

So, should we say this issue is resolved in the latest firmware version 3.5.2/3.5.3?

The noise is gone but it works like crap. Set it by M106 S125 - for me it pulses to high speed every few seconds.

The noise is gone but it works like crap. Set it by M106 S125 - for me it pulses to high speed every few seconds.

Yes yes it does, however this issue was about the noise ... :)

If you disconnect the fan it is even dead silent. ;-)

Should be solved since 3.5.1, closing

Was this page helpful?
0 / 5 - 0 ratings