The downside, though, is that once you import, there is no common connection anymore between the preset and the “base class.” If you make a change, it only changes the current preset. This allows you to not have a bunch of meaningless entries just to hold your defaults. In fact, on import, the slicer only uses these to fill out the ini file for a specific item. Notice the asterisks around the PLA_Brand_X identifier? That tells the slicer not to show this entry to the user. Finally, you would have a specific “Red Brand X PLA” that only has to set the color and - if you have multiple extruders - maybe the pigment factor that controls how much filament gets purged between colors.įilament_wipe_advanced_pigment = 0.7 Hidden Entries Then a PLA type for “Brand X” which overrides only a few items. For example, you might have a base PLA filament type. What that means is you can export your configuration as a bundle and then rearrange everything so that you have all your common settings in one place and then inherit most of those setting from specific items. Second, you can have one entry inherit items from another preset in the same bundle. First, you can hide certain entries in a bundle. But there are two things that work in our favor.
#SUPER SLICER 3D ZIP#
On the face of it, that might not seem like much of a big deal since you could just zip a bunch of ini files into an archive. However, the slicers allow you to export and import configuration bundles that populate a bunch of profiles at once. You could, of course, keep track of a myriad of ini files and generate them on the fly. This is not great, though, because one preset lives in one file.
The name of each preset is in square brackets, along with an identifier of what kind of preset it is. ini files that have a very simple format. Presets or profiles are usually stored in. If you are like me and use the slicer from different computers, this is a great way to put the files in a shared drive or use something like Syncthing to keep a few copies synced across the network. Speaking of which, both programs take a -datadir command line argument that lets you put the configuration files where you want. If you want to try your hand at it, I highly suggest you backup your configuration directory or switch to a new one. I’ll show you how I have things set up and where the limitations are. The problem is, this capability is not documented very well and the GUI doesn’t really support it directly, which requires a little sidestepping. Both of these, of course, are based on Slic3r, but the scripting languages are different and what I’m doing does require G-code scripting.
Prusa Slicer and its fork, SuperSlicer, have the capability already. I’ve long wanted to create a system that lets me have baseline profiles and then just use specific profiles that change a few items in the baseline. Part of the reason I want to manage multiple profiles has to do with this mystery object… For example, if you have profiles for different nozzles, you get to make a choice: keep one profile and edit the parts that change, or keep multiple profiles and any common changes have to be propagated to the other profiles. You have to keep changing profiles and modifying them. This does lead to a problem, though, when it comes to slicers. That doesn’t describe me and, I’m guessing, it doesn’t describe you either. They buy it, they print with it, and they don’t change much of anything. I know people who have 3D printers that are little more than appliances.
0 kommentar(er)
