[BUG] LCD fan settings glitch

[yangwenxiong]

Bug Description

Recently, I downloaded the latest marin 2.0 firmware. When testing the main controller on the motherboard of stm32F407xxx, I found that when setting the fan on the screen, the setting fan did not correspond to the set fan number, that is, I wanted to set fan 2, but the result turned into fan 3.I think there's a bug

My Configurations

The default configuration is stm32f407xx main control board

Steps to Reproduce

Expected behavior:
Turn on fan x on the 12864 screen and the corresponding fan x will be turned on

Actual behavior:
Open fan x on the 12864 screen, the corresponding fan x is not corresponding, open other fans

Additional Information

[studiodyne]

@thinkyhead
There is a bug on LCD fanspeed , since 2020 03 19
Fanspeed does'nt work on lcd , and always set 0. To have the speed , i have to set ' recorded value ' secondary item that turn on fans

I thinks this bug and mine are the same

And i have discover another bug
all_axes_homed() return always false
Look the video here #17573

[thinkyhead]

all_axes_homed() return always false

Why is that? Is it because axis_homed never has the XYZ bits set at the same time?

FORCE_INLINE bool all_axes_homed() { return (axis_homed & 0x7) == 0x7; }

[NAPCAL]

@thinkyhead
Here is two videos of the LCD fans issue. 2.0.5.3 both boards. Bugfix the same.
BigTreeTech SKR GTR 6 fans
BigTreeTech SKR Pro 3 fans

I went back in the release versions and it first shows up in 2.0.3

[studiodyne]

If you have single nozzle config , i have fixed , an old bug in the fanspeed menu
Try the last bugfix2.0. Take a look in the cfg.h , now singlenozzle can store fanspeed for each tool , or not.

Explanation : Fanspeed1 = fanspeed1 of Extruder1 , fanspeed2 for extruder 2 , this option can be enabled/disabled in cfg.h in the last bugfix2.0

Report us

[NAPCAL]

@studiodyne
Here are the results using the current Bugfix 4/30/2020. No change but maybe a more useful video on the BTT SKR GTR

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[thisiskeithb]

PR #18400 should fix this issue.

[sjasonsmith]

I'll re-open this since my PR isn't actually merged in yet. That way we don't lose track of comments if anyone provides more feedback.

For anybody who was experiencing this fan issue, please feel free to try the fix referenced in the pull request above.
I only tested it with three fans, but I am assuming it will fix the 6 fan case also.

[NAPCAL]

Also I don’t think you can send a M106 or M107 command without a fan number, it may not default to fan1.

[sjasonsmith]

Also I don’t think you can send a M106 or M107 command without a fan number, it may not default to fan1.

I think I did that and it worked, but that isn’t what I was testing so I wasn’t paying too much attention.

[NAPCAL]

Applied the PR code change to 2.0.x Bugfix, no change. It looks like the array or index when selecting a fan above fan1 and below the max fan causes the selection of the highest shown on the LCD unless Fan2 is the highest. Also, if selecting the highest on the screen, it will select the next fan unless the next fan is greater than the max fan. See this Video of this issue

[sjasonsmith]

@NAPCAL you said here this is not fixed, but on the PR itself you seemed to indicate it is fixed?

Which of these is correct?

[NAPCAL]

It is fixed, tired me the first time I copied the the removed code. Thisiskeithb let me know there was a 2nd set of changes that time around I made the correct changes. I tested it on my BTT Pro (3 fans) & BTT GTR/M5 (6 fans) both passed with the new code.

[sjasonsmith]

Thanks @NAPCAL! @yangwenxiong, we haven’t heard from you yet, but this should now be fixed.

I’m going to flag this issue as stale, which simply allows our maintenance bot to close the issue in 5 days if there is no more activity on this issue. Please only reply at this point if there is still a reason to keep the issue open.

[yangwenxiong]

I’m going to flag this issue as stale, which simply allows our maintenance bot to close the issue in 5 days if there is no more activity on this issue. Please only reply at this point if there is still a reason to keep the issue open.

Uh-huh,Nice ,It's working. Thank you

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