prusa3d / Prusa-Firmware

Firmware for Original Prusa i3 3D printer by PrusaResearch
GNU General Public License v3.0
2.02k stars 1.05k forks source link

Hi Pitch noice coming from print fan #460

Closed Richardgriff closed 4 years ago

Richardgriff commented 6 years ago

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.

jettoblack commented 6 years ago

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.

cnschu commented 6 years ago

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.

magkopian commented 6 years ago

@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.

vestom commented 6 years ago

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)

kacperd2808 commented 6 years ago

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?

tdctaz commented 6 years ago

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.

Luxovious commented 6 years ago

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.

Rick-T commented 6 years ago

+1

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

justinvoelker commented 6 years ago

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.

hagronnestad commented 6 years ago

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

mvasilakis commented 6 years ago

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.

maximlevitsky commented 6 years ago

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.

sorlok72 commented 6 years ago

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

sarf2k4 commented 6 years ago

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

Dolnor commented 6 years ago

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.

fedhat commented 6 years ago

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.

miksumortti commented 6 years ago

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(?)

asmaps commented 6 years ago

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

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

aemileski commented 6 years ago

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

OndraMac commented 6 years ago

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

plug-it-in commented 6 years ago

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

scorfman commented 6 years ago

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

TaylorCowin commented 6 years ago

same as all

ghost commented 6 years ago

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!

bamminger commented 6 years ago

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

scorfman commented 6 years ago

@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.

bamminger commented 6 years ago

Ok thanks, let's hope they fix it πŸ˜’

Zequez commented 6 years ago

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 .

miksumortti commented 6 years ago

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

WannabeSpaceman commented 6 years ago

@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?

miksumortti commented 6 years ago

@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.

Garpski commented 6 years ago

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?

lenisko commented 6 years ago

@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.

miksumortti commented 6 years ago

@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.

lenisko commented 6 years ago

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

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

miksumortti commented 6 years ago

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

lenisko commented 6 years ago

@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?

alcor6502 commented 6 years ago

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

miksumortti commented 6 years ago

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

surrealseven commented 6 years ago

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);

alcor6502 commented 6 years ago

@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

haleypearse commented 6 years ago

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.

alcor6502 commented 6 years ago

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

alpha1125 commented 6 years ago

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...

alpha1125 commented 6 years ago

@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?

lenisko commented 6 years ago

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

alcor6502 commented 6 years ago

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.

alpha1125 commented 6 years ago

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 ! πŸ‘

alcor6502 commented 6 years ago

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

trevjonez commented 6 years ago

@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?