Marlin

Marlin copied to clipboard

Description

I recently installed cpap style remote cooling, and found I often wished to reduce or force the fan speed mid print, independent of what gcode calls to M106 are done.

This PR adds:

• Fan Lock: inhibits setting the fan speed via gcode. Useful to override the slicer fan settings, particularly when using different speeds for overhangs, layer times, bridges, etc.
• Fan Multiplier: responds to gcode but multiplies by a factor (0 to 10) before applying. I find this very useful when trying new materials that require a lot more/less fan than my default preset, particularly tweaking it mid print.

~~Obviously the PR is still missing configuration.h options, but I'd like to get early feedback or save myself the hassle if the feature is not considered good to merge (I use it and find it useful myself)~~

Requirements

Part cooling fan.

Benefits

Avoid having to re-slice and restart a print when I find the current settings are not good mid-print.

Configurations

Related Issues

This potentially adds another layer of complexity / possible points of confusion for users (bug reports and/or support requests) when a fan is "locked" since they won't know why standard fan commands aren't working.

~~Absolutely, this would definitely be behind a configuration_adv.h flag.~~ done

Do you consider these features worthy?

If so I'll add configuration flags and maybe avoid the float operation in the multiplayer for slower boards.

~~Maybe setting them via gcode is a bad idea, i now use it exclusively from the UI (i only added them for completeness)~~ behind a configuration_adv.h flag

This potentially adds another layer of complexity / possible points of confusion for users (bug reports and/or support requests) when a fan is "locked" since they won't know why standard fan commands aren't working.

They now have to first enable the option in configuration_adv.h and then explicitly lock it from either UI or gcode. It is not persisted to eeprom either so I don't think this would be a problem anymore.

Hi. I created a similar functionality. Perhaps joint work is possible. #27280 Mine :

• Use of percentage (simpler/intuitive)
• Use of two thresholds to target “normal fan speed” in the case of 3D printing for example
• Don't immediately update the current fan speed and wait for an M106, in "sleep temperature mode" the values ​​are stored and I didn't want to check if something was going to break somewhere.
• Do not block the M106. Because only one M106 applies full power, rejecting an M106 without an 'S' is equal to disabling a marlin feature
• Can also lock/unlock, applying a value of +-100%

I don't know if other uses of robotics (laser, cnc, or other), prefer percentage or decimal. That's why I will be really happy to have these two possibilities. For my personal case, I wrote this just because sometimes I slice without checking and the printing cannot be stopped just for fan speed. If you have the time to mix it all together and create one awesome feature I'm definitely all for having two in one. I don't have time and my job will never be more than that

Very good work Sincerely

Note: I made this thing without knowing that you had already done the same , I only found out afterwards, too bad because I would have adopted it (with a few modifications, of course :-))

Let's find the minimum options that get the job done :)

• I definitely use the multiplier often (both to increase and reduce power).
• I seldom use the fan lock, mostly for tests. Maybe this could be replaced with your offsets?

By the way, I didn't use percentage for the multiplier because the existing types use uint8_t so the max possible would be 255%. And they're most likely limited to 100% anyway

The project is for you, I don't have time. You have two blocks of 'work', you can feel free to make what seems the best for you and all. I'm impatient to have this in my cfg advance ! 😃. If you need french translation, I can help ! 🇫🇷 Cordially

This PR is ready for review then