variable_user_pause_macro does not work as expected
sk8board opened this issue · 10 comments
Problem Description:
The variable_user_pause_macro within mainsail.cfg does not execute as expected.
Example:
After the nozzle moves to the pause position, I want the nozzle to go to G1 Z0; in order to stop the nozzle from oozing.
I created a one-line macro to move the nozzle to zero.
[gcode_macro _z_to_bed]
gcode:
G1 Z0;
I call the macro using the variable_user_pause_macro as shown below.
variable_user_pause_macro : "_z_to_bed" ; Everything inside the "" will be executed after the klipper base pause (PAUSE_BASE) function
Result:
The result is the nozzle is driven to position Z 0.00 (into the part) BEFORE moving to the pause position. Based on the description of variable_user_pause_macro, the expectation is Everything inside the "" will be executed **AFTER** the pause
Recommended Change:
Simply swap lines 111 and 112 of the mainsail.cfg file as shown below.
## !!! Custom macros, please use with care and review the section of the corresponding macro.
## These macros are for simple operations like setting a status LED. Please make sure your macro does not interfere with the basic macro functions.
## Only single line commands are supported, please create a macro if you need more than one command.
#variable_user_pause_macro : "" ; Everything inside the "" will be executed after the klipper base pause (PAUSE_BASE) function
This is not a bug, it is working as described. Everything inside the "" will be executed after the klipper base pause (PAUSE_BASE) function
"after the klipper base pause" is the correct description of when this executes. Changing this so it instead occurs after toolhead parking would be a breaking change (so inherently unlikely) and some people would be unhappy that it no longer executes at the correct time for their use case.
Thank you for your response.
Could there be another macro added after calling _TOOLHEAD_PARK_PAUSE_CANCEL to prevent nozzle oozing while paused?
This seem like a desirable solution to a common use case.
Many printers today have a purge and wipe function that is performed when the print is paused and resumed. Adding two lines of code to the mainsail.cfg file would allow the user to perform such functions after _TOOLHEAD_PARK_PAUSE_CANCEL, while using a base Mainsail config.
Could these two lines of code be added? This seems like a simple request and solution.
This macro collection should only support "standard printers". Currently, I can't think of a single printer that has wipe and purge hardware by default and needs it for a pause. For special cases, creating a copy and customizing it as you need makes more sense. Of course, you lose the ability to update, but these updates could also "break" complex workflows.
It is up to @zellneralex, who manages this repo, to decide whether this additional variable makes sense and will be used.
I need to think about it.
In my opinion the description is correct, but as I see it confuses you. Any input how to describe the position better?
Your user macro is added after the Klipper pause. That means the original position is stored and is the anchor for resume. The original idea was to give people the option to add a led change and that needs to be done as early as possible.
I am also not sure if adding more places for user insertion is a good route to go, by the way that was the reason why I hesitated to add these user macros from beginning.
Give me a few days to think about it, I will either make the change or come back here and go in a longer discussion round.
One question do you need that only in pause or would you also need the same at cancel?
In my opinion the description is correct, but as I see it confuses you. Any input how to describe the position better?
#variable_user_pause_macro : "" ; Everything inside the "" will be executed after the klipper base pause (PAUSE_BASE) function
I believe the problem with the description is the term PAUSE_BASE is not commonly known. I believe most people would assume Everything inside the "" will be executed after the klipper base pause (PAUSE_BASE) function means after the tool head has parked from a pause, then the user macro will be performed.
Your user macro is added after the Klipper pause. That means the original position is stored and is the anchor for resume. The original idea was to give people the option to add a led change and that needs to be done as early as possible.
If a macro is going to be available, I believe most people would NOT expect the macro to be between two functions but after functions were completed. Having a macro between two functions does not seem like good practice and will result in a crash like I experienced as I described above.
I am also not sure if adding more places for user insertion is a good route to go, by the way that was the reason why I hesitated to add these user macros from beginning.
If the user macro insertion is well understood by the user, then this only adds to the existing perception of Klipper, which is the versatility of tuning and customization. An additional user macro insertion would be viewed by many Klipper users as a positive user experience if the user has correct understanding of how to use the macro, which requires clear documentation.
I believe the key to success is communication (documentation) to the end user. I recommend the description in the mainsail.cfg file refer the user to a more in-depth description on the Mainsail Documentation website.
If an additional user macro insertion is undesirable, then I believe we have to ask, is there more value for the location of the macro at the end of functions or between functions? I believe most users would find more value for the user macro when all pause functions have been completed.
If variable_user_pause_macro was intended for an LED color change, then is it really a big deal if the LED color change occurs while over the part or at park position? This seems minor to me and there is more value for the macro to be available after all functions are completed.
Again, I believe if there is clear understanding (documentation), then the user would not mind an additional user macro insertion. Before I used this macro insertion, I looked at the Mainsail documentation to gain clear understanding, but I found the Mainsail documentation website was not very helpful for these macro insertions, which resulted in a crash.
One question do you need that only in pause or would you also need the same at cancel?
This is a good question. At the moment I cannot think of a use case for a macro after a cancel park, but I would expect someone will eventually ask for this. I believe the answer comes down to my points above about where is the most value for the location of the user macro insertion. I believe there is more value to the location of the macro when all functions have completed.
With that said, if there is clear understanding (easy to understand documentation) then additional user macro insertions only add more flexibility, which is a key value to the Klipper experience.
Thank you for your consideration.
This macro collection should only support "standard printers". Currently, I can't think of a single printer that has wipe and purge hardware by default and needs it for a pause.
Bambu Lab A1 and A1 mini use their "poop chute" as a purge wiper during a pause. I have noticed Qidi Core XY printers are coming with a purge brush which is used during a pause. Therefore, I would expect Klipper users are going to expect this function if off-the-shelf printers have this function.
@meteyou I appreciate the excellent product that you and others have made with Klipper and Mainsail!!!
Getting the readme in the mainsail docs is planned, but it is a matter of missing free time at the moment. But we are an Open Source project so if you feel there is a lack of documentation you can always contribute and start a better one.
I named it PAUSE_BASE as you can find that word in the macro and should be able to understand the impact that your macro will make there.
If you read the readme the planed intention of the user macro should be clear. See https://github.com/mainsail-crew/mainsail-config?tab=readme-ov-file#new-feature-custom-macros-inside-of-pauseresumecancel_print
To make it clear, the macros here are always only a starting point we cannot find a solution that will make everyone happy.
Your example with close source printers does not match, everyone building an open source printer must understand that you also need to make your own functions like pause/resume/cancel/load/unload …;
As said I will look in it, but we running exactly in the issue I was afraid of when adding that. Anyone can say “but I need a jumpin point there …”
My personally recommendation in a case like this is make a copy of the mainsail.cfg, use it as a starting point and alter it to your needs. See it as example/template that should make your live easier at the beginning. But there will be users that need more complex solution and many others will be perfect fine within the complete printer lifespan.
As said I will look in it and also discuss it in the team.
Getting the readme in the mainsail docs is planned, but it is a matter of missing free time at the moment. But we are an Open Source project so if you feel there is a lack of documentation you can always contribute and start a better one.
Thank you for the invite. Since I have been out-of-work for quite some time, I will be happy to help. Please let me know what you need.
I am grateful for your work. I can relate to the volunteer work of open source. Here is an example of my work.
https://github.com/sk8board/CRServoF_ELRS_for_RP2040_Pico
I named it PAUSE_BASE as you can find that word in the macro and should be able to understand the impact that your macro will make there.
I agree with you. With that said, I am a strong believer in having pictures with words when working with technical content.
Here is an example of what I believe will make multiple macros a very successful user experience. Let me know your thoughts.
To make it clear, the macros here are always only a starting point we cannot find a solution that will make everyone happy.
I would like to respectfully challenge this idea. I am not saying your are wrong. I believe this perspective limits our vision of how to take a product to the next level.
I believe the user wants robust software that has easy flexibility to meet their need while being able to keep software updates for new product features and functions (like what I am asking for here).
I believe, for a team to take a product to the next level, the team needs to challenge each other with how can we provide more for the user and do it in a way that is simple for the user experience. When we do this, we will discover obstacles in the way. Learning to overcome these obstacles will take the product to the next level.
Your example with close source printers does not match, everyone building an open source printer must understand that you also need to make your own functions like pause/resume/cancel/load/unload …;
I believe the next level for Klipper, is a user experience that is more easy and flexible for the user.
To get to this next level, the team would need a vision that desires to move from the perspective of "everyone building an open source printer must understand that you also need to make your own functions" to how do we make Klipper functions like, pause/resume/cancel/load/unload …; robust and easy to customize that more people will enjoy the Klipper experience than the Bambu Lab experience.
I believe Mainsail is the vehicle that can be used to obtain this vision.
As said I will look in it, but we running exactly in the issue I was afraid of when adding that. Anyone can say “but I need a jumpin point there …”
I believe the key to success is robust implementation with easy to understand documentation like I have shown here.
My personally recommendation in a case like this is make a copy of the mainsail.cfg, use it as a starting point and alter it to your needs. See it as example/template that should make your live easier at the beginning. But there will be users that need more complex solution and many others will be perfect fine within the complete printer lifespan.
I respectfully challenge this perspective. Let's find a way to take Klipper to the next level.
As said I will look in it and also discuss it in the team.
Thank you for your consideration. Please let me know how I can help.