integration of Ellis' bedfan control

[qratz]

This is my attempt at integrating Ellis' bedfan control into klippain. Instead of overriding SET_HEATER_TEMPERATURE as in the original i left that behaviour untouched and changed M140, which to my knowledge has not been used anywhere else in klippain. In this version bedfans will only be activated when using M190/M140, but not using SET_HEATER_TEMPERATURE.

[Surion79]

i did that once and discussed with frix about it. we scrapped the thought and used the filter function for it, since it can be acommpanied with chamber soak, the solution is workable. I think there was also a technical restriction, but can't remember anymore. @Frix-x Do you maybe remember?

[Frix-x]

Looking at this with a fresh eye, there are two points to consider:

• There is already the filter fan function, and this can work very similarly to a bed_fan module if set up properly to heat up the chamber. And this is indeed what is done in Klippain, as it is used in the chamber heating phase of the START_PRINT macro to accelerate the heat spread, and then the speed is reduced during printing to "filter gently", but this can also "move air gently" if there's no filter in the device.
• But there are still some slight differences with the implementation here, which is more generic and works in the background without the need to set the speed in the macros, but it is also less flexible since the behavior is difficult to tweak manually.

So my question would be more: what is the preferred way? Because we have three options:

1. We can evolve the current behavior of the filter fan to something like this (but I don't like it very much since it's not very flexible).
2. We can implement it in parallel and let the user use one way or the other and add a warning at startup if both are included: the user would have to choose.
3. We can implement a dummy file called bed_fans.cfg that just silently includes the original filter_fan.cfg to get the same behavior but not confuse the user about the "bed fans not supported" and we can also make some slight tweaks like if it's bed_fan integrated, it doesn't need to filter for 10 minutes at the end of printing for example, but I think it's the only difference between the two that would be useful...

[qratz]

There are some things to consider:

1. Many users use both, a filter, e.g. nevermore, and bedfans together. The amount of air pushed through the filter is less than what the bare bedfans push
2. there is obviously the semantics: bedfans are not filter... i do realize that that is a very minor issue (now?!) but might be more relevant going further.

As for the bedfan tweaking, using the approach of this PR, or Ellis' approach in general: Depending on how many fans are used, the user has to determine the lower fan speed that is used during bed heat up, which should not be to high to keep the heat up unbothered. The second value is the higher speed that is used when target heat of the bed is reached. That speed should also be not to high, as chamber temps can ramp up to a critical amount with just 4 bed fans.... So basically two values. For example: i use values of 0.05 during heat up and 0.37 during soak and print. that keeps my chamber temps at around 65C. That is with 4 fans in a V2 350mm³.

[Surion79]

For keeping it generic, i would avoid using rename_existing on core macros. Using the filament based filter speed won't work in combination with fixed bedfans values when it is already mentioned that a wrong configuration might have catastrophic results if chamber is too hot. I started using bedfans but changed to the filter config because it is enough for using the filter config combined with chamber soak to have a heated chamber. I am using 3 v6 nevermore in my v2 350.

I also don't like to have 4 different configuration options between having none, one of both, the other of both and both. it will be a pita to maintain and might be locking out other future features.

[Surion79]

my biggest issue is overriding M140

[qratz]

my biggest issue is overriding M140

I don't know why it should be an issue. M190 is already overriden and the change in M140 is rather small. The original by Ellis' suggested changing SET_HEATER_TEMPERATURE and then redirecting M140 to there which, imho, is a far bigger change. By "just" overriding M140 we get the automated fan handling during print and the soaking macros, but if someone still wants to just heat up the bed without fans, there is still SET_HEATER_TEMPERATURE, which is used by mainsail and fluidd GUI.

[Surion79]

if you don't mind i would take a slightly different/extended approach in an own branch at klippain and try a more sophisticated integration in conjunction with the filter integration. just got an idea from the Doomcube community