PrusaSlicer
PrusaSlicer copied to clipboard
prusa3d
How to distribute printer mods profiles
Version
Any
Operating system type + version
Any
3D printer brand / version + firmware version (if known)
Any modded printer [e.g. Creality Ender 5 Plus with E3D Volcano and Bondtech extruder]
Behavior
I've previously written official PS profiles for Anycubic predator. I have a generic idea of how it works, but not a dev here. I think I understand we can write an all-in-one "generative" .ini file in /resources/profiles/ as i did for the predator and that generates system printer+print+filament profiles.
I'm also familiar with writing custom profiles that I distribute to my company's team and they install the printer, print, and filament profiles individually in their prusaslicer user config folder [as in .config/PrusaSlicer on linux].
I seem to understand we of course don't want modded printer profiles in official PS distribution.
I'd like to maintain a single, modular, "generative" / all-in-one "Creality-mod.ini" file that generates all printer+print+filament profiles for all layer heights and everything as I did for the Predator, and distribute them easily to my team.
I could make a file, place it in /resources/profile, recompile and distribute a custom PS to all my team, but there must obviously be a better way.
Is there a way to import a "generative" / all-in-one .ini config file that then generates all printer+print+filament profiles for a modded printer?
Is this a new feature request? Yes
You can place your custom ini bundle to data directory.
See https://github.com/prusa3d/PrusaSlicer/wiki/Vendor-bundles-and-updating-process#custom-vendor-configuration-resources
That's so cool, your screenshot is an example or the actual prusa farm [just out of curiosity]? Do they support auto-updating on PS start via git tracker? Thanks!
Ah ok, I just read that PS won't download anything if not from prusa3d.com, that's understandable but still, too bad. Why does the doc use example.com then as an example? Is there a case where the index can at least be read from elsewhere and alert the user of an available update, even though PS will refuse to the download it?
That's so cool, your screenshot is an example or the actual prusa farm [just out of curiosity]?
No it's just example (slightly modified copy of LulzBot bundle).
Ah ok, I just read that PS won't download anything if not from prusa3d.com, that's understandable but still, too bad. Why does the doc use example.com then as an example?
It was possible in the past (our config updates were updated from git). I will update the document.
Is there a case where the index can at least be read from elsewhere and alert the user of an available update, even though PS will refuse to the download it?
I don't think so. Non-Prusa URLs are rejected.
It should be still quite easy to distribute your ini bundle. Users can use Help -> Show configuration folder and just copy/overwrite the file.
ok thanks. We of course don't want to have a checkbox in settings to enable this right?
As the use of PS grows I'm certain others are distributing their own profiles outside of the official ones and auto-updating would massively streamline the UX especially for non-technical users. And this would spur wide testing of new non-prusa3d.com profiles.
For instance, in our experience, the Extrudr profiles that were recently added to PS are way too close to generic filaments and fixing those temps to the ones we use internally make a night-and-day difference.
If others could test this, and have auto-updates, we could make much faster improvements [larger user base] to then integrate these changes into the original prusa3d.com profiles.
The security concerns are around the execution of a malicious .ini file or gcode dangerous for machines?
For instance, in our experience, the Extrudr profiles that were recently added to PS are way too close to generic filaments and fixing those temps to the ones we use internally make a night-and-day difference.
Extrudr profiles were actually provided directly by the manufacturer :-). You can send proposed changes.
Yeah I imagined as much, i will definitely propose changes as soon as i have a spare minute. I was only using this as an example, if there had been a ~widely used unofficial profile that auto-updated every time we made a tweak, double-checking them with other users, the manufacturer wouldn't have even had to provide them as we would have had them in the first place, correct and tested right away, and would have simply then proposed them to become an official profile, before they published one with temps that in our experience are simply wrong [their semisoft tpu is full of bubbles at 240, you must print it <227deg, it is immediately apparent].
their semisoft tpu is full of bubbles at 240, you must print it <227deg, it is immediately apparent].
It usually happen when the TPU is not dry (it really doesn't matter much whether it is freshly unpacked or not). It is highly hygroscopic material in general. But let's not cluster this issue. As of the main topic of this issue, we will discuss it.
Yes of course, we're speaking fresh out of the box, we've been using extrudr as our main supplier for over a year and absolutely recommend their great filaments, and have fine tweaked temps for all of their materials over time.
But yes, back to the main point, generally speaking, when installing an unofficial profile, user could be prompted with a huge warning [or from settings, without even prompting the user] to enable autoupdate.
The risk factor is the same, once the unofficial profile is manually installed, whether it gets updated or not does not increase risk level, unless we're afraid of authors of legit profiles going rogue and only afterwards inserting malicious code, but then again if users manually upgrade they will be affected anyway.
I might obv be missing something, but this is my current line of reason.
As per my previous issue, As I'm developing a custom vendor profile for my company, that won't be published since it's of no use to other people, I struggle to allow for auto-update using the link since only files.prusa3d.com links are allowed
I'd like either to be able to create custom secure prusa3d links or to allow for custom links under a different domain for vendors profiles that won't be published
@alessandrogenoni if you want to just distribute bundles internally, you can set up any file sync utility (e.g. rsync, syncthing or even dropbox and similar) or use git and sync <data_dir>\vendor\ with directory on your server/master pc.
You can also build your internal version of PS with whitelisted internal domain.
I understand that there are other options that we are exploring and using, but everything is much harder and need the users to manually setup things. Also, building out own PS version is not really an option at the moment. The easiest way would really to be able to use the built-in updater of PS...
Hi! I tried infact to modify the code and re-build. I modified https://github.com/prusa3d/PrusaSlicer/blob/master/src/slic3r/Utils/PresetUpdater.cpp#L266 by commenting the check. It did compile but there's no different in behaviour. Does anyone know how to allow it?
Hello! I saw that the preset updater is being worked on for the new release: could it be the moment to allow, maybe with a specific setting, the ability to update a profile from a non-prusa3d online directory? This would allow for both ease of use for privates and company to distribute new profiles!
@alessandrogenoni thanks for checking in, may I ask where the preset updater is being improved? Thanks!
I started complying and using a modified version of the slicer and with the new betas there's a new update routine including a compressed file with all the vendors files.
For this scope, this is not an improvement since before the workaround was simply to avoid the check on the URLs. Now you need to include a few lines of code that actually download the profile and place it in a specific cache folder.
Since the profile updater now looks for updates only from the URLs in the vendors profiles in the downloaded archive, any custom vendor profile has to be coded directly into the update routine of the slicer.
I'm sure one could write a better code to integrate custom profiles but unfortunately this is not my domain and I'm already happy that I managed to make it work like this.
My point is that I don't see why prusaslicser wouldn't allow for custom profiles. If this is for security reasons, there could be a switch in setting to let the user choose a less secure update with external sources on custom profiles