Set virtual_sdcard path to printer-specific folder in multi-printers setups
#224
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Is your feature request related to a problem? Please describe
When creating a multi-printers setup with KIAUH, uploaded gcode files meant for different printers end up in the same
~/gcode_filesfolder.This is not ideal because gcode is often sliced for a particular printer, so it doesn't make much sense to share the gcode folder across printers (unless all connected printers are the same model and can use the same gcode).
Most importantly, when using Moonraker's object processing by enabling
[exclude_objects]in Klipper andenable_object_processing: Trueinmoonraker.conf, it seems like every uploaded gcode file is processed once for every connected printer, because multiple instances of Moonraker are watching the same folder. For instance, with two printers, every object will end up with duplicate EXCLUDE_OBJECT_DEFINE, EXCLUDE_OBJECT_START and EXCLUDE_OBJECT_END instructions, which end up generating warnings (and possibly other issues) during prints.Describe the solution you'd like
I'd suggest setting Mainsail's
[virtual_sdcard]paths to independent folders for each printer, as a default and recommended configuration (in the same way that configs are separated into independent subfolders inklipper_config).Describe alternatives you've considered
No response
Additional information
No response
KIAUH is primarily a setup helper, not a configuration helper.
If users wish to use individual gcode_files folder (which is recommended - you gave some reasons yourself) they have to adapt their respective configs to account for that. The configurations KIAUH installs upon creating single and multiple instances are only examples and are always meant to be replaced by a working configuration. They are so sparse, they can't even be seen as a starting point tbh.
I prefer to automate as few as possible modifications to any configuration files. It's simply against my philosophy and i tend to only add/modify entries which are really useful and/or required to get something to work.
Apart from that, it is way easier for a user to change the gcode path as, for example, changing the location Klipper expects the printer.cfg to be. Also the cost-benefit ratio for the feature you ask for is, in my opinion, almost 0. It would take me hours of work to develop and test that function to make sure it works correctly under every condition i can imagine in that situation (and even then it's not 100% failsafe) where in turn it takes a user 1 minute to change those path set in the config file and maybe create the required sub-folders themself.
I hope you can understand.
Thanks for the quick reply @th33xitus.
Newcomers might not necessarily be aware that paths need to be made separate in the first place. I found out by noticing warning messages, then digging and eventually finding out about the preprocessor conflict.
That said, I can totally understand how implementing a helper for this might be out of scope for KIAUH. It might make more sense to mention the different paths in the documentation for enable_object_processing.
I'll see if there's a way to communicate this, so that new users are made aware and hopefully save some troubleshooting time!
The thing is, that all those multi-instance functions and multi-instance setups in general are not officially supported by Klipper nor by Moonraker. So i am not sure if there will be a high chance of success when asking for changes in the object processing documentation of Moonraker, because with an "in spec" setup there is only one gcode folder per host. And in fact, it is rather a Klipper configuration which is necessary to get changed to make it work. Moonraker not so much.
Im not sure what approach is the best in that case. And im also not sure how i could help with that in KIAUH, other than maybe displaying a note at the end of a multi instance installation. But things like that often get overseen anyways.