saving slicing profiles

[chronoglass]

feature request
I have spent a good amount of time tweaking around with my slicing profiles for various materials, but always find myself in a situation where I have the same filament from two vendors that require some slight tweaking (or like taulman clear PLA compared to others, MASSIVE changes) being able to save all of the tweaks I make into a new profile from the slicer plugin would save a number of steps for me.

[John-Mc]

I also like this suggestion. It's not a top priority for me, since I can always go back to Cura on my laptop and make the new profile, but it would be more convenient to just save what I've done in the plug-in.

If OctoPrint sticks with the older version of Cura for an extended time (rather than switching to Cura 2.x), this suggestion might be even more handy, since I would not have to dig up my old copy of Cura (15.x?) to make a new profile.

[kennethjiang]

This is definitely a highly desired feature. Quite a few users have asked for that.

The tricky part is that currently slicing profiles are managed by OctoPrint, not my plugin. Since OctoPrint doesn't provide a way to update a slicing profile, implementing saving slicing profiles in Slicer plugin means re-implementing the whole profile management. Not only would that amount to a lot of work, but it will also be very confusing to users since now there are 2 places where you can manage slicing profiles.

I'm open to suggestions on how this can be done in a simple and elegant way.

[donovan6000]

You could implement it in the same way that M33 Fio does.

It uses this blueprint API to overwrite an existing slicer profile or create a new slicer profile when provided with this data. It accomplishes this by using the slicer plugin's save_slicer_profile function that will overwrite any existing profile with the same path or create a new profile if its path is unique.

[kennethjiang]

Thank you so much @donovan6000 for these pointers! Now I know that this is doable!

Did you use OctoPrint's /api/slicing/xxx/profiles/yyy to fetch slicing profiles? Or you created your own APIs to fetch/manage them? OctoPrint API returns profiles in JSON format, whereas original Cura profiles are in (sorta) YAML format and Slic3r profiles seems to be in some kind of Windows .ini format. However your plugin seems to be able to load these profiles in their original formats.

Also did you have to wrap an API around OctoPrint's save_slicer_profile? If so, I believe your API would handle profiles in their original format correct? If so, did you have to build some kind of parser so that you can take user's input on, e.g., layer height, and insert the value to the profile at the right place, in its original format? I found traces of such code in your plugin here. However I'll appreciate it if you can further explain to me how you handled it as I couldn't piece them together myself.

Thank you so much!

[donovan6000]

I created my own API for fetching the slicer profiles that's used to convert the slicing profiles stored in OctoPrint back into their original formats before sending them to the user to edit them. I did this purely because I felt like the user would be more familiar with editing the slicing settings in their original format.

Because of that I also had to convert the edited slicing profiles that are currently in their original formats back into their OctoPrint formats when the user was done editing them so that I could use them with save_slicer_profile. I didn't have to create my own parser for this since that capability is already built into the slicing plugins since that's what happens normally when slicing profiles are imported into OctoPrint by the user, and it can be utilized by doing something like this. Unfortunately that's not something that OctoPrint's API defines, so it might not work in the future and might slightly differ between slicer plugin implementations.

However none of that is necessary if you don't need to access a slicing profile's original format. In which case a slicing profile fetched with /api/slicing/xxx/profiles/yyy could be directly used with save_slicer_profile in the following way since the slicing profile is always in OctoPrint's stored format.

profileDict = ... # Dict that contains values obtained from /api/slicing/xxx/profiles/yyy

profileDestination = self._slicing_manager.get_slicer_profile_path(values["Slicer Name"]).replace("\\", "/") + "/"

profile = octoprint.slicing.SlicingProfile(values["Slicer Name"], values["Slicer Profile Identifier"], profileDict, values["Slicer Profile Name"], values["Slicer Profile Description"])

self._slicing_manager.get_slicer(values["Slicer Name"]).save_slicer_profile(profileDestination + values["Slicer Profile Identifier"], profile)

[kennethjiang]

Thank you so much @donovan6000 for the details. It looks like this feature is more achievable than I thought!

[chronoglass]

I don't know if i'm alone in this, but it seems to me that the holy grail for a system like octoprint is to decouple material from machine profiles. in the slicer I'd like to basically have a list of the materials I have narrowed the properties down on to select from to auto set the temps/speeds/distances and have that go into the slice

[thjansen72]

Hm. Just a idea.. If the sclicer "overwrites" the values of the cura.ini, octoprint is using, it might be posible to save a bunch of values (aka cura.ini) -representing the different user-made-data- sets for multiple material-setups.
Like a kind of profile-presets with the slicer editable values...

[John-Mc]

@chronoglass - isn't what you are describing more-or-less what a slicing profile is for? You put in all the little tweaks to make a specific filament run on your machine at specified quality levels. I suppose you could try to separate out machine-specific variables from filament specific, but I'd bet there are a lot of variables that are dependent on both, or are inter-dependent. (For example, you might be able to run a bit faster - which requires adjusting machine settings, but doing so also requires you to adjust the temperature - which is commonly thought of as a filament-dependent setting.)

[John-Mc]

@thjansen72 - I'm not following how this is different from just having a number of customized slicer profiles available - which we can do now. The only difference is that presently, you have to make them on Cura on a desktop/laptop computer and import them (but you can have multiple profiles imported to choose from). Am I misunderstanding what you are describing?

[chronoglass]

i suppose in context of the interdependent settings it makes it quite a bit more complex to hit those magic numbers when talking about speeds and feeds vs quality and time, and the totality of what I really hope to get to is outside the scope of this one feature request.. probably a plugin to this plugin all it's own! haha. but a good starting point I still think would be the ability to save the adjustments made at slicing time (considering at present I'm basically just keeping it all on a giant sheet of graph paper)

[John-Mc]

but a good starting point I still think would be the ability to save the adjustments made at slicing time

Agreed. It would be nice not to have to go back to a desktop version of a slicer, recreate and save changes then re-import into OctoPrint.

[thjansen72]

@John-Mc Just a bunch of ideas for this topic. Maybe i should think about it some more.
But saving the changes made before slicing in a new slicer-profile would be a good way!

[kennethjiang]

Thank you so much everyone for contributing to making Slicer plugin better. I've been very tied up lately but will take a swing at this feature whenever I have free cycles.

[kennethjiang]

@John-Mc I remember we exchanged quite a few emails but somehow I can't find your email address anymore. Can you send email again to me at kenneth dot jiang at gmail dot com ?

[kennethjiang]

@thjansen72 @chronoglass I have been thinking about building something that may be close to what you talked about. I talked to a few 3D printer users and some of them proposed similar idea.

I'd like to get your detailed input as well. Can you email me at kenneth dot jiang at gmail dot com so that we can set up a time to call/skype chat?

[leobel96]

@kennethjiang I opened an issue some time ago... OctoPrint/OctoPrint#2054

[kennethjiang]

@leobel96 Glad to know that you want a way to separate filament from the general slicing profile too. I'm currently in the phase of collecting people's opinion on slicing profiles should be better managed, including if it makes sense to take out settings related to filaments.
Can you email me at kenneth dot jiang at gmail dot com so that we can set up a time to call/skype chat?

[leobel96]

@kennethjiang Unfortunately I'm not a developer but only a very curious user ahahah so I don't know how I could help you :(

[kennethjiang]

@leobel96 I'm not actually looking to talk to developers. What I'm trying to learn is what to build rather than how to build it. And I believe the best way to know what to build is to talk to users like you. In the past I have made the mistakes to assume that other users would want what I want. I'm not making the same mistake this time hehe :)

[leobel96]

@kennethjiang in my opinion adding filament saving support as suggested will make the plugin perfect, In this moment I don't know how you could improve it

[clee]

👍 for this feature. I also would love the ability to have filament profiles - specifically containing filament diameter, extruder and bed temperature, and retraction settings (which I find vary from filament to filament).

[ismangil]

Playing around with Slic3r Prusa Edition, it seemed to got settings relatively correct: print quality, filament, and machine.

[John-Mc]

Is separating filament from the general slicing profile what the newer versions of Cura are doing now?

[kennethjiang]

Hi @John-Mc - finally I'm wrapping up on my job search (btw I'm joining https://www.fictiv.com/ !). should be able to spend a bit more time on this plugin.

Which version do you mean by "newer version"?

[John-Mc]

@kennethjiang - Congrats on the new job!

I'm mainly using a Lulzbot Mini printer at present. Lulzbot uses a customized version of Cura, which is currently "Cura Lulzbot Edition 2.6.66". I'm not very familiar with it, since it requires flashing new firmware on the Mini, and once I do that, the print profiles I import into OctoPrint from Cura 15.4 will not work (it should be fixable, once I modify the start gcode in my copy of Cura 15.4 and maybe make some other changes). I printed a single print with Cure LE 2.6.52 (which was Lulzbots first release of Cura 2.x, and still used firmware compatible with earlier versions). They have nothing out yet in 3.x. Their Cura releases lag Ultimaker's by a good bit, but the upside is that they come packaged with a lot of finely tuned profiles for a wide range of filaments that work right out of the box with Lulzbot printers.

My limited understanding of the profile set up in Cura 2.x and 3.x (I'm not sure exactly when this started) is that they have separated out machine specific and filament specific settings into two different files. I may be all wet on that, however. Just something I think I remember reading.

[kennethjiang]

Thanks @John-Mc .

Took a look at the Cura 2.7 and 3.2. Yes you are right that both versions now separate filament settings from slicing profile. I think it's a step toward the direction of making it easy for users.