Extruder: Disable/Enable pressure advance.

[viesturz]

Add a parameter to enable/disable pressure advance without changing the configured values. Useful for MMU units to allow performing filament unloads without tedious restoring of previous pressure advance.

Somewhat related: prusa3d/PrusaSlicer#11021

[thijstriemstra]

Exturder: Disable/Enable pressure advance.

Hadn't seen that typo before 😄

[Zeanon]

I just noticed, you renamed pressure_advance_smooth_time to pa_smooth_time but didn't change the object call in the get_status method

[viesturz]

Thanks, fixed.

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

[KevinOConnor]

Thanks. As high-level feedback, I'm not sure this is something we should add to the mainline Klipper. It adds additional complexity to the code and I'm not sure what users gain from it - if they want to disable or enable pressure advance they can just set it to zero and a non-zero value.

Cheers,
-Kevin

[viesturz]

Thanks for the input, however hear me out.

On the technical side, each extruder may have a different perssure advance value and active extruder can change, making it significantly tedious to track the state using current commands. Possible, but tedious.

The main "user value" goal I'm chasing is to have a stable "klipper dialect" for multi extruder/multi material setups.

Klipper macros are very flexible and can emulate existing gcode flavors with ease, and this leads to each user doing their own bespoke setup. Right now MMU users are fairly advanced and able that, but it is a significant barrier of entry for the rest.

On the other side, slicers are starting to add "klipper" as a separate Gcode dialect (Prusa).
So I'm arguing that time is right to provide some common structure for both.

So far I have been adding a few small PR towards that, mainly to test out the waters. Would be great if you can comment on the overall direction. The folks in Discourse and Discord seem to be very split between - just use macros and yes please.

[KevinOConnor]

Thanks for the feedback. I agree with your comments on the problems resulting from a lack of standardization. I agree it would be good to address those problems.

I guess my main feedback is that I think there needs to be some consensus on the "vision" for the final state before we start making changes. My fear is that, without that vision, small incremental changes could make the lack of standardization much worse. That is, in addition to "many users using macros" and "many users using slicer features", we'll add "many users using new Klipper parameters" - thus even less standardization.

It's also worth considering that, in addition to the possible mechanisms listed here, another approach is to have a hardware specific Klipper module for each mmu (eg, an "ERCF Klipper module"). That is, an mmu has many actions it needs to do in order to reliably switch filaments - it may make sense to have a module for it, and if so, that module may be a good place to handle things like restoring pressure advance. To be clear, I'm not suggesting this is the "right way", just another possibility to consider when discussing a long-term "vision". The idea of using "plugins" may also be relevant - https://klipper.discourse.group/t/possible-klipper-plugins-instead-of-macros/9819

I think Klipper Discourse would be a good place to discuss that vision.

Cheers,
-Kevin

[viesturz]

Thanks for the input, totally agree, setting up something in discouse.