Skip to content
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

custom macros defined in mmu_macro_vars.cfg aren't kept on release upgrades #471

Open
HitLuca opened this issue Oct 18, 2024 · 3 comments
Open
Labels
believe fixed / answered The bug is believed fixed in latest release config issue Believe is fixed with config change

Comments

@HitLuca
Copy link

HitLuca commented Oct 18, 2024

I have seen for a bunch of version upgrades that any macro I have defined in mmu_macro_vars.cfg isn't kept, resulting in having to dig around to find their definitions on the backed up folders.
An example below:

[...]
variable_user_post_load_extension: 'MY_POST_LOAD_EXTENSION' 

[gcode_macro MY_POST_LOAD_EXTENSION]
gcode:
    MMU_SYNC_GEAR_MOTOR  
    CLEAN_NOZZLE

Having the macro defined in this file makes sense, and having it defined right after I use it makes easier to keep everything under control.

Is there a suggested approach to solve this? Can we keep custom macros between upgrades? Happy to provide more details

@wdcocq
Copy link
Contributor

wdcocq commented Oct 21, 2024

I'm not sure if it's documented anywhere. But I wouldn't advise putting it in mmu_macro_vars.cfg. These files get indeed overridden in an upgrade.

So for now it's probably better to add it in something like /mmu/mmu_custom_macros.cfg (should not be touched by an upgrade, but would still be in your backup) and include that in printer.cfg

That said, I'm not the maintainer so maybe this will be supported in the future.

@HitLuca
Copy link
Author

HitLuca commented Oct 21, 2024

I ended up moving my macro to mmu.cfg since that one gets copied when upgraded. That's where I also have a temperature sensor entry for the mmu board (which would be convenient to automatically add on first ercf install imo)

During upgrade I would then prefer to have a warning or automatic check that lets me know some functionalities won't be transferred, as in this case I would end up discovering it after the first color change of a (possibly) already long print

@moggieuk
Copy link
Owner

moggieuk commented Oct 25, 2024

To allow for upgrading functionality all the packaged cfg files are replaced with new ones on upgrade (technically hardware related ones are not changed). All the klipper parameters in mmu_parameters.cfg and macro variables in mmu_macro_vars.cfg (and addon cfg's) are also retained. If you want to add functionality you should do so in your own cfg file and [include] that in your printer.cfg after the other Happy Hare includes. This will keep it separate and will then upgrade cleanly.

Note that nothing is lost .. there will be a date stamped backup of the whole mmu config directory. Note also that you should be able to include your custom cfg's in that directory if you want to keep functionality together.

@moggieuk moggieuk added believe fixed / answered The bug is believed fixed in latest release config issue Believe is fixed with config change labels Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
believe fixed / answered The bug is believed fixed in latest release config issue Believe is fixed with config change
Projects
None yet
Development

No branches or pull requests

3 participants