fan: Support multiple part fans

[viesturz]

Multi extruder setups can have separate part cooling fan for each extruder. This change allows runtime switching between fans using ACTIVATE_FAN command, similar to ACTIVATE_EXTRUDER.

The fix is to essentially make [fan] the same as [fan_generic] and use ACTIVATE_FAN to specifcy which fan is the printer fan. Inactive printer fans may be manually controlled using existing SET_FAN_SPEED command.

This helps primarliy with PrusaSlicer gcode, that just emits M106 S110; T1; when changing tools. Making emulation with macros quite complex.

[viesturz]

A possible alternative would be to add a T# param to M106.
That is however something no slicer currently supports IMO.

Cura supports cooling fan number using P#, that needs to be configured on the slicer side.
I think it's prefferable if a slicer can operate on Tool level abstraction and can omit configuring hardware details.

[github-actions]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
   If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[github-actions]

Unfortunately a reviewer has not assigned themselves to this GitHub Pull Request and it is therefore being closed. It is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[KevinOConnor]

Thanks. Sorry for the delay in responding. As high-level feedback, I'm not sure we should add new commands that are used solely to control the behavior of old g-code commands. That is, M106 and M107 are old poorly defined commands, and I suspect it may be more transparent for users to define their own macros if they need those commands to do something else. For example, something like:

[gcode_macro M106]
    variable_active_fan: "fan_generic primary_fan"
    gcode: SET_FAN_SPEED FAN="${active_fan}" SPEED={params.S|float / 255.0}

-Kevin

[viesturz]

Thanks for the feedback.
I can see this going roughly three directions:

Custom macros for each user

 - users need to tinker around to find a working slicer/macro combo
 - no agreement what gcodes to use
 - Slicers seem to be adding hacks for Klipper already, making it even more messy

Klipper provides better support for M106/M107 for existing slicers

+ Known documented way how to setup multiple fans
+ minimal/no changes to slicers.
- more code in Klipper

Slicers start using SET_FAN_SPEED / fan_generic for multi material setups

+ Known documented way how to setup multiple fans
~ need a Klipper gcode dialect, this seems to be happening already however
- SET_FAN_SPEED does not support the main fan, making migration painful - this should be easy-ish to fix however

Can you share some guidance where do you see Klipper going?

[KevinOConnor]

Well, if you want my opinion, I'd prefer if slicers didn't mess with the fans at all. That is, I suspect the overwhelming majority of users would get better results if the fan got turned on at an early layer (eg, layer 2) and the fan speed was never changed after that. I suspect I am in the minority with that opinion though. That is, I suspect that the slicers are trying to be way too clever, and I also suspect many users think "too clever" is a good thing.

That aside, I agree with your concerns on a lack of standardization. I have the same comments mentioned at #6294 (comment) - I think we should have a consensus on a "vision" before making changes so that we don't inadvertently make the lack of standardization worse.

-Kevin