-
-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add a variable to be able to override some future mmu variables #501
Conversation
@Frix-x please check this before merge develop in main... |
Mhmm I'm not sure this is a good idea: I would use the Klippain vars all the time to keep some consistency and avoid problems. Is this possible? I'm not sure to understand all the impact of this and what are the HH variables in question... |
The future version of HH has is own macros and introduce some new "variables" already use in klippain like for Park position, travel speed, home mmu, check gates... with HH default values. So if user want to use HH automatics macros it use HH variables. The HH macro are very cool and it's a good think if I replace the one in klippain to use the one from HH. I don't know if I made myself understood correctly? |
Ok, so I think the best would be to remove the Klippain variables and use only HH vars and macros to leverage everything on HH: this will avoid duplicates and will also make it easier to maintain since there is less code in Klippain :) |
so Klippain requires HH installed to run a park macro for non-HH users? the wording is confusing for me "use only HH vars and macros" |
No, I was just saying that it would be easier to use HH variables for HH macros and Klippain variables for Klippain macros, and also the easier since there would be nothing to do. But now that I'm looking a bit deeper, I see that HH does a lot of stuff like defining another PARK, etc... So I would say that these functionalities should stay in Klippain as they are used by a lot of people and would avoid having different behavior when we use an MMU or not. What do you think about this? |
I haven't looked deeper into it yet. I would rather go with your suggestion and if there are potentials for optimizing I would go for it then. (Without deeper look: like include only one park defined if mmu is used) |
I must make some test but I think with the new version of HH we can remove all the user_variable in variable.cfg My question is rather about the new variables that are used by HH and that sometimes duplicate that of Klippain. My opinion would be that they should be overrided. But in this case either we just add a variable in variables.cfg (like variable_allow_klippain_override_mmu_variables: True ) to give the user the choice... Or we do it automatically and the variables concerned in the HH configuration file will be ignored without the user being able to do anything about it. |
could you please list the vars in question and their same/different functionality? there are at least three things to consider:
|
Or we can just put a routine in the startup delayed gcode to just "copy" the Klippain vars into the HH vars to avoid having to override the macros but still have the same values copied. This will be much easier to maintain and will allow both to work independently while allowing them to be decoupled. I mean having in the startup things like this for every duplicated variables:
|
That exactly what I have made... but just with an if with a variable to let user choose which one he wants to use with mmu macro. i use this:
|
Do we really need a variables for this? I would prefer to do it automatically for everyone to avoid having different behavior between people. It will probably also help debugging. But at least we are ok on the technique, that's a good point :) |
i think this is not even all of it. And regarding integration, i'd rather have it not as delayed gcode but within startup macro with proper print output that MMU is enabled. |
in the future HH some variables are already define in HH. This variable can be use to choose between klippain default variables (for exemple for park position....) or the one define in the future upgrade of HH