PrusaSlicer 2.2.0-beta  

RE: PrusaSlicer 2.2.0-beta

Does 2.2.0 solve the problem with the Intel HD3000 graphics card? See github: https://github.com/prusa3d/PrusaSlicer/issues/3008

Thanks!

RE: PrusaSlicer 2.2.0-beta

I tried out this beta (didn't use any of the 2.2.0 alphas), and am having troubles importing my config bundle from 2.1.0. On 2.1.0 all my custom filaments show with all my custom print profiles (modified from the Prusa 2.1.0 profiles). After importing my config bundle into 2.2.0-beta none of the filament profiles are determined to be green-flag with my custom print profiles. If I create a new print profile copying my customizations from the old custom profile to the new copy my filament profiles are now green-flag. The dependencies in the filament profiles only pings the printer profile keywords (the print profile keyword filter is empty) so I don't know why the print profile makes a difference.

Am I stumbling across a bug? Here is my config bundle (after stripping out my octoprint address/key with a text editor) as saved out of PrusaSlicer-2.1.1+win64-201912101512:

PrusaSlicer_config_bundle - Copy

RE: PrusaSlicer 2.2.0-beta

Posted by: @sembazuru

I tried out this beta (didn't use any of the 2.2.0 alphas), and am having troubles importing my config bundle from 2.1.0. On 2.1.0 all my custom filaments show with all my custom print profiles (modified from the Prusa 2.1.0 profiles). After importing my config bundle into 2.2.0-beta none of the filament profiles are determined to be green-flag with my custom print profiles.

I never had issues selecting the system profiles with my various printer and print settings profiles. With the recent releases, I can't get them to show, even with manipulating the dependencies. Like yours, filament profiles based off the system profiles seem to be problematic. I finally hand-edited a copy of the prusaresearch.ini file to remove all dependencies from the system profiles, renamed and copied them over to another file for import as a config bundle.

Another frustrating recent change is that the system filament profiles now have nozzle sizes hard coded as exact matches. Rather than specifying a nozzle size greater than or equal to a size, they use exact matches against 0.25, 0.40 and 0.60mm nozzle sizes. Very frustrating when working with different nozzle sizes.

I think Team Prusa have taken the regexp matching in dependencies about as far as is reasonable. It would be great if they'd make the dependencies more flexible and granular. Check this one out:

compatible_printers_condition = nozzle_diameter[0]>0.35 and printer_model!="MK2SMM" and printer_model!="MINI" and num_extruders==1 && ! (printer_notes=~/.*PRINTER_VENDOR_PRUSA3D.*/ and printer_notes=~/.*PRINTER_MODEL_MK3.*/ and single_extruder_multi_material)

If you'd care to zip & upload your config bundle, I'd be happy to take a look.

RE: PrusaSlicer 2.2.0-beta

My config bundle was attached to my previous message. (Surprised you missed it.) 😜 

Further investigation on my part seems to indicate a blank "inherits =" of the print profile is causing problems. For example, my "0.20mm QUALITY MK3 (CDE)" profile in Plicer 2.1.0 had an inherits of "0.20mm QUALITY MK3" which no longer exists in Plicer 2.2.0. When imported the "inherits =" gets blanked out because the importer can't find the profile name without the @ symbol. If I go in by hand and edit the custom profile .ini file (in the beta config folder, obviously) with a text editor and make the inherits line read "inherits = 0.20mm QUALITY @MK3" and then start up Plicer 2.2.0 then that profile can now see all my filament profiles that I'm used to seeing.

Seems that if a print profile is inheriting nothing (thus -default-) then it breaks being compatible with any filament profile other than ones that also inherit from -default-. And, the only way that I know of changing that "inherits =" attribute is by hand in a text editor.

RE: PrusaSlicer 2.2.0-beta

I've noticed something with profile names. In 2.2.0-beta (I believed first announced for the first alpha, but I didn't start playing with 2.2.0 until the first beta) there is an @ symbol added to help cut down on name clutter in the profile pull-downs on the platter view. In the print profile I think I formatted my custom profile names similar to the system defaults. See this screen-shot of the pull-down in the print profile tab:

But on the platter tab, when I look at the print profile choice pull-down, only the system profiles have the @symbol and everything after trimmed from view. See this screen-shot of the pull-down in the platter tab:

Is this an unknown bug, or has implementation of this feature not been finalized?

RE: PrusaSlicer 2.2.0-beta

@sembazuru

I (and several others) have opened/reported this issue, it was introduced at alpha4 when they reorganised the profile dependencies.  I cant remember the off hand without looking it up but you have to do some editing to get them to show up.  I think I edited the name to have the @MK3 bit in but someone else said if you edit the inherits line that you can get it to work.  That's ok if you only have a few but if you have lots its not worth it.

The preference option to show incompatible options doesn't effect the shown profiles either which is a definite bug as that should be an over ride

RE: PrusaSlicer 2.2.0-beta

@neophyl

Please see the following explanation.

https://github.com/prusa3d/PrusaSlicer/issues/3658#issuecomment-587521783

TLDR; 
If your print or filament profiles are to be compatible with your custom printer profile (printer profile not derived from Prusa3D system profile), you have to remove the "inherits" keys from your print and filament profiles.

RE: PrusaSlicer 2.2.0-beta

@bubnikv

My particular issue is that I have some custom printer profiles that were derived originally from the basic MK3.  They have customised start gcode and tweaked extruder settings etc.  Previously these would show the standard filament and print profiles for quality, draft etc for the MK3 printer.

Since the change selecting one of these customised printer profiles, these no longer show the prusa print and basic filament profiles anymore, only those that were saved as user ones.  However as the printer profile WAS based on the standard MK3 they should show these.  Especially if the preference option to show non compatible profiles is enabled (which it is).

RE: PrusaSlicer 2.2.0-beta

@neophyl

Profile derived from a vendor system profile is considered to be part of that family. So if you derive your custom printer profile from a Prusa3D system printer profile, and you derive your print and filament profiles from the Prusa3D system profile as well, then they will all be accessible if a Prua3D system Printer profile is active, or a custom profile derived from Prusa3D system profile is active.

If you remove the "inherits" field from your custom print, filament and printer profiles, then these profiles will be show only if a Printer profile that has no system profile parent is active.

(BTW there is a bug in 2.2.0-beta that I just discovered and fixed in master that causes a crash on start of slicer if you do that. That crash should be fixed with https://github.com/prusa3d/PrusaSlicer/commit/d5bffd28167eefcbb9a71ab14d2a64130c368128 )

RE: PrusaSlicer 2.2.0-beta

@bubnikv

The problem is all my custom printer profiles were created using the previous versions of prusa slicer so in effect they get broken in the new versions.  I'm sure if I loaded in a 'new' default mk3 profile and made all the same changes then saved it as a custom one that would show the prusa default filaments and print profiles BUT that's a lot of work recreating profiles that work fine in earlier versions.  I think you described it on github as a breaking change.

RE: PrusaSlicer 2.2.0-beta

Just checked and if I add "Original Prusa i3 MK3" to the inherits line of all my profiles that were originally based on the Mk3 and re-import them, everything works as before, all the print and filament profiles show up. 

Of course that's editing profiles manually which is probably not what you want people doing in the long term.

RE: PrusaSlicer 2.2.0-beta

Posted by: @neophyl

Just checked and if I add "Original Prusa i3 MK3" to the inherits line of all my profiles that were originally based on the Mk3 and re-import them, everything works as before, all the print and filament profiles show up. 

I've been creating custom profiles for a long time, mostly to cover the various nozzle sizes that Prusa doesn't support directly. That has worked well with previous versions of PrusaSlicer/Slic3rPE until recently.

I am using multiple levels of inherits = in my configs. I have a single baseline config that does include inherits = Original Prusa i3 MK3. My custom profiles in turn use inherits = *mybaseline* which has worked so far. IIRC, I had to create the baseline as a copy of the actual Original Prusa i3 MK3 profile to get the bed graphic to show up properly. 

The problem I'm having now is that the system filament profiles are now weirdly linked to the Print Settings profiles. If I select my printer (nozzle) profile, I can select between system and custom print settings profiles. However, if I use a custom print profile, the system filament options disappear.

One of the most powerful features of PrusaSlicer (IMO) is the unlinking between printer, print and filament settings, allowing us to make changes to one without having to update dozens of otherwise-ideal profiles. This is a real weakness in every other slicer I've tried. I'm concerned that Prusa is introducing changes that break that independence and not documenting what is going on for external users. (PrusaSlicer would be even better if separate nozzle profiles were introduced which allowed using a common base printer profile with a range of nozzles, including temp tweaks for each nozzle, but that's another discussion.)

RE: PrusaSlicer 2.2.0-beta

> I've been creating custom profiles for a long time, mostly to cover the various nozzle sizes that Prusa doesn't support directly. That has worked well with previous versions of PrusaSlicer/Slic3rPE until recently.

We made a breaking change to make sense of multiple vendor profiles, to avoid mixing custom profiles derived from different vendor profiles. We may adjust the behavior based on your feedback, or you may update your workflow to fit the new behavior. Let's find out what will be easier and / or cleaner in the long term. First of all, we need to find out how people were using the custom profiles together with the system profiles before, so we can extract some common denominator from there.

> I am using multiple levels of inherits = in my configs. I have a single baseline config that does include inherits = Original Prusa i3 MK3. My custom profiles in turn use inherits = *mybaseline* which has worked so far.

Multiple levels of "inherits" were not really tested for the custom profiles (profiles stored as separate files per profile in the Print/Filament/Printer folders). I am a bit confused. How did you get  inherits = *mybaseline* key into your custom profile? Because the profile names with "*stars*" are reserved for custom profiles in the system config bundles. Did you modify the Prusa3D.ini system config bundle?

> IIRC, I had to create the baseline as a copy of the actual Original Prusa i3 MK3 profile to get the bed graphic to show up properly. 

Showing the Prusa3D print beds is a bit more versatile starting with PrusaSlicer 2.2.0-alpah4, where the print bed texture and model are assigned to a printer model configuration (printer model configuration is only available in the system vendor config bundle). This is again a breaking change due to the support of 3rd party vendor profiles.

It is true, that if your custom Printer profile does not derive from the Prusa3D system printer profile, you will not have the Prusa3D print bed displayed by default, but you can now point your custom Printer profile to the Prusa3D print bed texture and model of the PrusaSlicer installation using the bed shape definition dialog at the Printer profile preset configuration page, but it is most likely better to derive your Printer profile from the Prusa3D system profile.

> The problem I'm having now is that the system filament profiles are now weirdly linked to the Print Settings profiles. If I select my printer (nozzle) profile, I can select between system and custom print settings profiles. However, if I use a custom print profile, the system filament options disappear.

Currently the custom profiles (the profiles stored as separate files in Print/Filament/Printer folders) are either considered to be part of the Vendor profile space by deriving them from some Vendor profile, or they are all considered to be standalone, if the first profile in the inherits chain is empty, thus it derives from the "-- defaults --" profile. Is it a problem for you?

Could you maybe share the content of your configuration folder, so we can discuss concrete data and configuration scenarios? I am a bit confused as of what you are trying to achieve and what is not working. I hope that we can fix your configuration for you without changing the current PrusaSlicer logic.

I did some tests. I made two copies of a single Print profile, Filament profile and Printer profile, and then I have cleared the "inherits" field of every second copy thus detaching them from their respective Prusa3D system profiles. Now I can try various combinations.

When the Printer profile derived from the Prusa3D system profile is active, everything works as if the system profile is active.

When the Printer profile with the removed "inherits" field is active, then only the Print and Filament profiles with the removed "inherits" fields are visible. This design choice separates the custom profile space from the vendor profile space.

When the Printer profile derived from the Prusa3D system profile is active or a Prusa3D system profile is active, both the Print profile derived from the Prusa3D system profile and the Print profile with the removed "inherits" field are visible.

When the Printer profile derived from the Prusa3D system profile is active or a Prusa3D system profile is active, and when the Print profile derived from the Prusa3D profile is active or when the Prusa3D system Print profile is active, then the filament selector offers all the Prusa3D filament profiles plus all the profiles with the removed "inherits" filed (or any other profile derived from the "-- default--") profile.

I suppose the last combination is the point of contention. When the Printer profile derived from the Prusa3D system profile is active or a system Prusa3D profile is active, and when the Print profile with the removed "inherits" field is active (or any other profile derived from the "-- default --" profile is active), then the filament selector offers just the profiles with the removed "inherits" filed (or any other profile derived from the "-- default--") profile.

Now is it a problem? Couldn't you just derive your Print profiles from the Prusa3D print profiles? Or should we change the software logic, that the system Filament profiles of the Printer vendor are shown even for non-system Print profile? Is it really necessary?

RE: PrusaSlicer 2.2.0-beta

Bob is a lot more knowledgeable than myself when it comes to profiles, all I can do is detail the way I use them and what I have seen.

I have 2 printers, a mk3 and a heavily modified cr10.  My profiles for both are originally created from the Mk3 but created back before it was even Prusa Slicer, when it was Slicer PE.  Those profiles have been gradually tweaked over time as I modified start gcode etc, largely from following some of Bob's notes.  I have a few specific filament profiles saved and a few print profiles but mainly I load in one of the prusa print profiles and make small changes on the fly for each particular project.  Then I save the project.  

Each time there is a new alpha or beta I download and run from the download folder to use it for my day to day slicing.  I usually run it once to get any updated profiles and then import the config bundle to get my profiles in.

Previously no matter what printer profile I selected I always had access to the filament profiles, like Generic PLA etc and the default mk3 print profiles.

Since the breaking change I have not had ANY filaments except my few saved ones or print profiles except my custom ones.  Even though my print profiles were originally created from a mk3 profile. Keep in kind that the preference selection for show incompatible profiles has been enabled the entire time, now they do not even show in the list never mind have a red flag next to them.

Since the discussion a few posts up I have now manually added the inherits for a mk3 to all my printer profiles which has allowed me to see the filament and print profiles again but I dont think asking users to edit .ini files is the way forward.

I have attached an earlier non edited config bundle in case its of use.

Personally I think filament profiles should not be limited to a particular vendor.  Its filament, its supposed to be printer agnostic, unless of course you think Prusament should only be used on prusa printers ?

RE: PrusaSlicer 2.2.0-beta

> Personally I think filament profiles should not be limited to a particular vendor.  Its filament, its supposed to be printer agnostic, unless of course you think Prusament should only be used on prusa printers ?

We have had this discussion internally. At the end we decided that it is each vendor's responsibility to define his own Filament profiles as they will likely be different from Prusa3D filament profiles to achieve the best results.

RE: PrusaSlicer 2.2.0-beta

As its been awhile since I did a new printer install I decided to try the process using the 2.2.0 beta.

I approached it as a user who doesnt have a prusa but some other brand basic printer.  As such I selected none for the default printers and went to a custom one.  After going through the wizard and setting the bed size and printing temps etc. I selected expert mode, I then completed the wizard and it exited into Prusa Slicer proper.  With just a custom printer there are NO filaments to choose from, not even generic ones.

Printer profile is the one I just created naturally with some very basic start and end gcode which is as expected.

Then we get to the filament settings.  Here the ONLY filament listed is "Test Printer".  So all those basic filament profiles, ie Generic PLA, Prusament, Amazon basics etc are NOT available to the new printer I just added.  Don't you think that's a little limiting ?  Its not exactly useful for those that do not have a Prusa printer and are just starting out.  While I'm sure the filament profiles could be tweaked for the non prusa printers, having them there as a starting point makes a HUGE difference for those that are new and even those that have experience but are trying a new filament type for the first time.  

With the process you have now they cant even see them to copy them.  Remember the average user isn't a Vendor and knows nothing about that, they just want to install the software and get going.  

If you are going to have filaments that are limited to a vendor which I think is a bad decision at least have access to the generic ones for common filaments types for non prusa non vendor printers as part of the wizard and selection process.

RE: PrusaSlicer 2.2.0-beta

@neophyl

> So all those basic filament profiles, ie Generic PLA, Prusament, Amazon basics etc are NOT available to the new printer I just added.  Don't you think that's a little limiting ?

We can think of providing a "default" or a "mother" vendor config bundle providing profiles to inherit from. We discussed this internally as well, but at the end we decided to keep it simple and stupid (KISS). For the vendor it would likely be more confusing than a help if they derived their profiles from the "mother" vendor and then if something changed in the "mother" vendor they would be surprised. To some extent this applies to user or custom profiles as well, as they would be surprised if the "mother" profile changed.

> Its not exactly useful for those that do not have a Prusa printer and are just starting out.  While I'm sure the filament profiles could be tweaked for the non prusa printers, having them there as a starting point makes a HUGE difference for those that are new and even those that have experience but are trying a new filament type for the first time.

That may be true, but also if they are brave enough to create their profiles they should know what they are doing.

> With the process you have now they cant even see them to copy them.  Remember the average user isn't a Vendor and knows nothing about that, they just want to install the software and get going.

That is why we are now offering the option for the 3rd party vendors to fine tune their profiles for PrusaSlicer.

> If you are going to have filaments that are limited to a vendor which I think is a bad decision

why? It is our experience (and believe us we do a lot of fine tuning of slicer profiles), that the filament profiles need to be fine tuned for each printer model. That is why we require each vendor to define all filaments she/he supports from scratch. We decided to trade some redundancy and maintainability for print quality. This way the vendor may fine tune his profiles independently from other vendors, which will make the vendor profile distribution simpler to maintain.

> at least have access to the generic ones for common filaments types for non prusa non vendor printers as part of the wizard and selection process.

As described above, we may integrate a "mother" profile with the filament profiles if there is a high demand for it, but not for PrusaSlicer 2.2 release. For PrusaSlicer 2.2 release, we may think of lifting up the filament dependency requirement a bit that seem to block @bobstro 's workflow.

Believe or not, it is quite difficult to come up with a configuration concept that is versatile, easy to understand and reduces redundancy. We decided to keep it simple and possibly to make the concept more complex later based on the needs of us, the 3rd party vendors and of the community. We were motivated by the complexity (sic!) of the Cura configuration to keep it simple. I believe our rules are relatively easy to understand, but possibly somehow limiting.

It is easy to say that our configuration structure and rules are poor. It is more difficult to come up with a coherent design. We are open to suggestions.

RE: PrusaSlicer 2.2.0-beta

I'm not sure if i am in the right thread- however, i downloaded and tried prusa slicer over the last couple of days. I don't own a prusa printer, but i wanted to try your slicer. I must say, the new user interface is absolutely stunning! I like how things are organized, it is slick and has excellent performance. Coming from Cura, i was very much impressed. 

Comparing the prints with those from Cura, i experience some issues with stability, and i am missing some more functionality regarding support settings. Overall, the print quality could yet be improved. I am very much excited, and i would love to completely switch to prusa slicer some day soon-

RE: PrusaSlicer 2.2.0-beta

@bubnikv

Sorry it was not intended to come across as that much of a complaint.  I appreciate all the hard work that has already gone in Prusa Slicer.

I guess I'm slipping into work mindset, I test embedded software that integrates into a web based monitor and control system, and besides the embedded working to spec our biggest focus is on the user experience.  I do understand how difficult it is to design systems that work for a variety of people who all use the 'system' in quite different and often unexpectedly novel ways that were not envisaged when it was first released.

Streamlining the current system is a necessary process with most large projects but its very easy to under estimate the effect even small changes to the user facing parts can have until you make the change and feedback (ie complaints) start to come in, and for every complaint there are usually at least 10 more that don't bother complaining or don't know where to complain to.

As a user there are 3 main problems with the new process -

1) New users that don't have a Prusa or an Ender 3 are left out in the dark. They don't have any choice BUT to create their own profiles, regardless of if they do or do not know what they are doing. Its not a case of being brave. This is going to put off new users from what is one of the best slicers available.
2) The change has invalidated any older profiles that were based on Prusa profiles.
3) The show incompatible profiles preference option now has no effect. This is broken previous functionality so is definitely a defect.

You are right that just pointing out the issues is of only so much use. However its a necessary first step.

1) Your point about this is taken and the profile dependencies being changed with your 'mother' profile is a good point.
However with the wizard process it should be possible to create a vendor space taken from the custom printer name/definition and copy the filament settings into that vendor space without the dependency on the mother ones. In effect creating a starting point for a custom printer. So if after configuring my custom printer I was presented with a list of generic filament profiles and I selected a generic PLA and a generic PETG they would be copied to a Generic PLA @custom Printer and Generic PETG@custom printer. That way if the mother profiles were updated it would not effect those created for the custom printer.
Not for 2.2 but for a future update possibly.

2) When importing a config that contains the "PRINTER_VENDOR_PRUSA3D" & "PRINTER_MODEL_MK3" in the notes field (which should exist in all those older configurations based on the prusa profiles) add the appropriate inherits information so that it is compatible with the new way. This should stop older existing profiles being broken and not require users to manually edit their ini files.

3) Fix this. This really should bypass the whole thing and show every profile for everything.