Marlin: [BUG] Ender3 | Problems with PWM drive parameters for fans

[yudi-jpn]

Bug Description

While #define FAST_PWM_FAN is defined, the PWM control of the print head fan and the main board fan is only ON or OFF, and it is not variable.
FAN speed cannot be controlled by PWM.

FAN parameter adjustment with the rotary encoder is also "100 >= n" on or "0 == n" off, and the fan control by PWM is disabled.
(The variable is unknown.)

If the FAN SPEED menu is continuously pressed with the rotary encoder while setting the FAN speed, the stored parameter will be lowered in the form of “n--;”.

However, there is no change in FAN speed.

My Configurations

Configuration.h
#define BLTOUCH
#define NOZZLE_TO_PROBE_OFFSET { -44, -5, -0.67 }
#define AUTO_BED_LEVELING_BILINEAR
#define LCD_BED_LEVELING
#define Z_SAFE_HOMING
#define DISABLE_M503
#define PREHEAT_2_TEMP_BED 70
#define SLIM_LCD_MENUS
//#define SPEAKER
#define FAST_PWM_FAN

Configuration_adv.h
#define BOOT_MARLIN_LOGO_SMALL
//#define ARC_SUPPORT

Configuration.zip

Steps to Reproduce

1. Define
   #define FAST_PWM_FAN

2. Try changing the fan speed from the menu or g-code.

3. Variable speed change by FAN PWM is not reflected.
   It seems that PWM is not used and it is reflected only by either 0 or 1 of FAN energization.

Expected behavior:
FAN variable speed control by PWM control

Actual behavior:
The variable speed control of FAN by PWM control is always in the state of either energizing or shutting off.

Additional Information

About Marlin2.0.x, it is the version downloaded today.
Not a night version.
The build date is unconfirmed.

There is a possibility of my carelessness.
Sorry at that time.

[thisiskeithb]

Do they work with FAST_PWM_FAN disabled? It’s not enabled on the stock Ender-3 config and my original fans died ages ago, so I can’t verify.

[yudi-jpn]

@thisiskeithb
Thank you.

This configuration file was rewritten and verified by me this morning.

I felt this was a strange phenomenon from the 2.0.x-bugfix version, but I was more concerned about the ABL problem and I left it there.

This morning I was inadvertently testing the fan speed PWM control in //#define FAST_PWM_FAN.

I will check this in a defined and undefined state.
(Due to poor physical condition, I will leave first to apologize that the verification is slow.
Because the weight has dropped to 42Kg. )

Regarding the bug that the FAN SEPPD value decreases by one, isn't the same situation occurring in other 3D printers?

Thank you in advance.

[yudi-jpn]

I checked the configuration file and it was in the defined situation that the compilation was done.
#define FAST_PWM_FAN

I am preparing a sketch of Arduino on a spare computer.
then will check this definition commented out.
//#define FAST_PWM_FAN

Thank you politely

[boelle]

@yudi-jpn since 2.0 was just released a few days ago has this changed this issue at all?

[yudi-jpn]

@boelle
Thanks for your comment.

This is probably the symptom I've been interested in since the beta version of the "2.0 bugfix".

Today is only one day off per week, but I didn't touch Marlin because I had a thorough examination of my throat and brain at the hospital.
I'm really sorry.

Points to worry about
In case of 1-100%, always power to FAN. (Always full speed)
When 0-99%, the FAN power supply is always cut off. (Even I can't hear PWM noise.)

When the FAN value is 100%, 1 to 99% is 100% speed.
If the FAN value is 0%, 1 to 99% is 0% speed.
Values ​​that should not overlap are overlapping in this case.

I think the 1-99% parameter is gone.

I don't remember whether the parameter value was 127 or 255, but the FAN control is in the state of 0 and 1 instead of PWM.

I will also check with this definition disabled.
(Sorry sorry to keep you waiting)

Thank you in advance.

[yudi-jpn]

I'm sorry to have kept you waiting

"Marlin 2.0.x bugfux" The build of 2019.12.10, I tested this firmware today.

I misunderstood the night version and the release of the top file.
This time, it verified with the night version.

In the definition below, the fan control by PWM is always only energized or cut off. (Not normal)
#define FAST_PWM_FAN

In the definition below, fan control by PWM is performed normally. (However, if the FAN parameter is a value other than 100%, it will decrease each time the rotary encoder is repeated, such as i--.)
//#define FAST_PWM_FAN

Configuration(20191210).zip

Thank you in advance.

[thisiskeithb]

If you're trying to use the stock Ender-3 config, leave FAST_PWM_FAN disabled. It's not compatible.

[yudi-jpn]

@thisiskeithb
Was it a compatibility issue?
Sorry for my mistake.

Does the same symptom appear in other printers regarding the phenomenon that the parameter decreases?

Share the video temporarily.
https://photos.app.goo.gl/m7dqkSMC8LB1U3Qm8

[boelle]

just try to leave FAST_PWM_FAN disabled if you use the stock ender3 config and let us know if that solves the problem

[yudi-jpn]

@boelle
Thank you.

The board is a rewrite of the manufacturer's original board. (Is this stock?)

When FAST_PWM_FAN is disabled, FAN speed is reflected normally.

However, even in this configuration, if the rotary encoder is pressed several times while the parameter is between 1 and 99%, the value decreases by one.

Should I mark up this case as resolved and have a new thread on the bug that the parameter value decreases?

Thank you for your kindness.

[ricardomenzer]

However, even in this configuration, if the rotary encoder is pressed several times while the parameter is between 1 and 99%, the value decreases by one.

I'm experiencing this same issue. Board is ANET V1.0. Everytime I enter the menu for Fan Speed, it will decrease by 1, except when it is a multiple of 20%, in which case it doesn't change at all. For example, it doesn't change when it is 0%, 20%, 40%, 60%, 80% or 100%.

[yudi-jpn]

I interpreted the value divided by 5 (examples that @ricardomenzer pointed out: 20%, 40%, 60%, 80%, 100%) as the key point of PWM control.

I'm curious about the possibility that some of the code has been simplified due to firmware improvements.

In units of 20%, I have not yet confirmed by operation.
However, I think this is probably the same situation.

"Marlin 2.0.x" is much more agile than "Marlin 1.9.x".
So I'm curious about the possibility that something has been simplified for more efficient control.

Thank you carefully.

[thisiskeithb]

Everytime I enter the menu for Fan Speed, it will decrease by 1, except when it is a multiple of 20%, in which case it doesn't change at all. For example, it doesn't change when it is 0%, 20%, 40%, 60%, 80% or 100%.

I was messing around with my part cooling fan while printing pointy trees and noticed this behavior in Marlin 2.0 as well but hadn't looked into it further than that.

[boelle]

has this turned in to a config issue rather than a bug as such?

[thisiskeithb]

has this turned in to a config issue rather than a bug as such?

Reverting FAST_PWM_FAN to the stock Ender-3 settings will take care of the originally reported problem, but there is another bug related to setting fan speeds that should be a separate issue.

[yudi-jpn]

@boelle
Thank you.

It was confirmed that this is another problem that should be considered separately from the definition of #FAST_PWM_FAN.

There is a problem that the FAN speed parameter is decreased by 1 each time it is operated by GUI menu such as LCD or OLED.

Currently, this symptom does not occur when the FAN speed divided by 5 is reached, and seems to occur with any other parameter.

examples that @ricardomenzer pointed out: 20%, 40%, 60%, 80%, 100%

For example, it doesn't change when it is 0%, 20%, 40%, 60%, 80% or 100%.

This is a problem suggested by @thisiskeithb.

I'm still inexperienced at GitHub, so I still can't decide if I should thread at my discretion.

If you need a new thread, please help me with the thread.

Thank you in advance.

[McPaul0]

Configuration_adv.h

if ENABLED(FAST_PWM_FAN)

#define FAST_PWM_FAN_FREQUENCY 977
//#define USE_OCR2A_AS_TOP

This solution solves your problem.

[McPaul0]

You may read more here:
https://github.com/MarlinFirmware/Marlin/issues/15077

[boelle]

@yudi-jpn is the issue still the same with all the updates in the last 9 days?

[boelle]

btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible

[McPaul0]

I think It is not an issue, but some kind of feature, peculiarity.
Marlin 2.0 works on 32bit MK which much faster then 8bit.
So many fans cant work at so high frequency.

define FAST_PWM_FAN_FREQUENCY 977 sets the lower frequency.

The same for:
SKR1.3, SKR1.4, MKS SGenL,
Fan: 4010 stock creality, ADDA AD0412MB-G76

[yudi-jpn]

@boelle
Thank you for your reply.

About the new firmware.
Since then, the newly released Marlin 2.0.1 due to my personal time has not been verified.

FAST_PWM_FAN: Commented out and solved (PWM switching frequency not confirmed)
//FAST_PWM_FAN

Issue where FAN speed is decremented by "LCD UI" operation: not solved in current environment (this is a past release)

I will do my best to confirm what I have reported this year.

Thank you politely.

[yudi-jpn]

@boelle

I'm really sorry to keep you waiting.

Having just downloaded the firmware, I redefined where it was needed.
Configuration.h.txt

About the problem that the value of FAN speed is decremented at every UI operation.

I just tested using Marlin-bugfix-2.0.x firmware released on December 19, 2019.
The firmware used is Nightly build firmware.

I have repeatedly selected FAN speed from the user interface.
However, the phenomenon that the FAN speed was decremented again occurred.

In the firmware (2.0.1) environment at the top of the download link, I am still untested.
(Because I decided that it was enough to verify with Nightliy build)

I'm sorry over the trouble.
Thanks in advance.

Everyone, please welcome a good year-end and new year.

[yudi-jpn]

I forgot some corrections in the attached configuration file.

Definition
#define DISABLE_M503
(Because the printer's non-volatile memory is full)

[AnHardt]

The issue is not ENDER 3 specific. Same on BTT PRO V1.1 and likely all other boards.

Would make me wonder if this wouldn't be a interger math problem.
Integer division regularly results in a too small result .

255 -> 100
128  -> %        ----> 128*100/255= ‭**50**.196078431372549019607843137255‬ %

100 -> 255
 50 ->  ?        ----> 50*255/100= **127**.5

255 -> 100
127 ->  %        ----> 127*100/255= **49**.803921568627450980392156862745‬ %

and so on.

[boelle]

So what do we do with this one?

[yudi-jpn]

@AnHardt
thank's

@boelle
thank's

It may be necessary to launch a new thread for this issue.

However, I cannot identify the details that cause the bug.

Difficult to express.

[github-actions[bot]]

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.