Model, Filament, Slice settings organization

Feature Requests
#1

I was going thru my AstroPrint setup trying to clean things up a bit…

I noticed something in my workflow that might suggest some possible improvement in organizing things, at least if others work in a fashion similar to me. I haven’t thought this through but what I find is this…

My printer choice rarely changes…I mean how many do you have and each is on a separate Astro box anyway.
My choice of slicer changes but only after my goto slicer proves it just can’t cut it…okay slight pun intended.

My filament changes with the Model…however I find PETG is remarkably good for almost all my functional parts.
My slice settings change with the model…seldom do two models use the exact same settings.

I find I have two types of slicer configs and any given configuration is tied to a printer and to a filament as those
determine the many slicer settings that are not interchangeable (think speed and heat)…if you change the printer or the filament you almost always change the settings. The two types of settings are baseline settings that yield decent results on most models using a specific printer and filament and slicer. These settings are usually slower and more conservative…they yield a decent print in most cases. The second type of setting is based on the Printer, the Filament and the Model and of course the slicer. I seldom change slicers or printers so we can leave those out for the moment…

Seems like the natural way to group slice profiles would be with the Model first, then the filament.

In looking at my slice settings I find that once I choose the right material and a baseline setting for a model I then tweak that slice setting to be optimized for that model…maybe going faster or slower…using more or less infill or adjusting layers or perimeters from the baseline to accommodate issues created by the model’s structure or use.

Thus I end up with slicer profiles named for the Models (which currently includes filament info too)

Just wondering if maybe grouping Slice profiles by model instead of by printer/filament might be more natural.
If this were done it would still be nice to be able to choose any profile from any other model to start with or better
still just add a duplicate to the slice profile manager so a profile could be duplicated to other model.

Yes we will end up with lots of slice profiles this way, but I find I have many of them anyway some only subtly different from others just because the model demands it, and they are somewhat hard to keep track of in the current setup, and I figure profiles are tiny,

Oh well just my thought of the day…

2 Likes
#2

This makes total sense. We’ll look at how we can fit this in the UI.

What would happen when you delete the model? Would it be ok to wipe it’s associated settings or would want to keep them somewhere ?

#3

Maybe it is the database guy or the old guy in me but I have always been a fan of flat filesystems and keyword searches that are used to pull things up.

Maybe it is the packrat in me that says I hate to ever get rid of something I spent time to create as it might be useful later.

Thinking out loud…

I might suggest that the underlying organization be ‘virtual’ with keys to link things together. At the top level things might appear to be organized in a tree…maybe something like this:

Printer->Model->Filament->slicer->slice profile. Maybe I would swap Slicer and Filament or remove slicer and have that implied by the profile since in a way it really is limited to being used with one slicer, but since these are just key words it would not really matter.

As to deleting a model maybe a Slice Library … This would be a virtual thing too, it would list all existing slice profiles maybe organized by model name or filament.

One idea:
Deleting a model might ask “Delete Associated Slice Profiles?” If the user answers yes then the profiles would be removed from the system completely, if not then they remain in the Slice Library, possibly showing under a pseudo heading of “Archived Slice Profiles”…this would work similar to how documents and users are treated in some UNIX setups…in this case there usually are true copies of files in each user’s home directory and they are optionally retained in a new location when the user is removed and can later be reclaimed by other users.

What would happen we didn’t keep copies but only keys and if two models used the same profile (I know this kinda refutes my earlier idea, but sometimes it does happen like with a revA and revB part almost the same but I need to keep both and slice settings are identical)…suppose you deleted one and answered yes…well a minimum there should be a warning that it is in used by another model.

Or maybe better, I would make the delete, reference count system…zero references is true deletion…true deletion from the system only when the count to reaches zero, thus when deleting it appears the profile is deleted but it continues to exist for each model that uses it. Maybe it is never deleted completely until it is removed from the Library too (count = -1) This would mean an extra step to delete profiles…I kinda think this is fair as profiles are work to create, and are stored only in AstroPrint unlike models which take even more work to make but are also usually stored in some other location or in a source file format and could be recreated.

Then what happens if two models using the same slice profile and the user decided to modify the profile for one model…I guess it either asks if the user wishes to change this profile for all models that use it. If yes then the profile is simply changed if no then the profiles diverge and a fresh new copy of the profile is created just for this model which is then modified. Due to the fact that models must be sliced as a secondary time intensive action I would say that divergence is really the better option…otherwise you end up with models and slice profiles that do not match the actual Gcode…the only solution I see is Gcode had to be generated dynamically, or never stored both of which increases demands on the slicers.

This is really all a big revision control system problem…luckily the set of files is fairly small and certain restrictions limit how flexible the system has to be. Having thought more about it, I might avoid some of the work of multiply cross linked profiles and maybe truly duplicate things at some level and prevent multiple ownership…It would be less flexible require more but minor storage, however it could be easier to implement and maybe easier for users…

I’ll think more on it…during my next long print.

1 Like