PrusaSlicer
PrusaSlicer copied to clipboard
prusa3d
Profile inheritance should check "conditions" on computed profile only
Version
master @ 03f17a13e756038603d471c80d22d45012f1059a
Operating system type + version
Debian Unstable
3D printer brand / version + firmware version (if known)
N/A
Behavior
There's an issue with both filament and print profile inheritance that prevents a profile which inherits from another to change/remove compatibility checks.
Reproduce with:
- start from a fresh config & the wizard
- unselect all printers
- select custom printer (create a "test" printer)
- hit finish
- prefs -> enable incompatible printer profiles
- filament settings -> hit the red flag
- select generic PLA
- expert mode
- dependencies
- clear "compatible printers condition"
- save
The filament profile is still not compatible, since (I assume - I didn't check the code), the base profile/s are still checked for compatibility when computing the final profile.
This is also true if you explicitly use "true" as the condition in the profile copy and/or if you select explicitly "test" as the compatible printer.
The exact same logic applies to print setting profiles.
The filament profile is still not compatible, since (I assume - I didn't check the code), the base profile/s are still checked for compatibility when computing the final profile.
The compatibility condition is calculated first when the profile is saved, as it is an expensive operation.
The compatibility condition is calculated first when the profile is saved, as it is an expensive operation.
Mhh I'm not sure I follow. The profile on disk just contains the condition...
Mhh I'm not sure I follow. The profile on disk just contains the condition...
The way I understand you is that you have a profile that you edit, but do not save yet. In that case the modification of the condition is not taken into account,.
pá 28. 2. 2020 v 9:23 odesílatel wavexx [email protected] napsal:
The compatibility condition is calculated first when the profile is saved, as it is an expensive operation.
Mhh I'm not sure I follow. The profile on disk just contains the condition...
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/3729?email_source=notifications&email_token=ABMPSI57S5QFC4PADCBFTT3RFDCXRA5CNFSM4K5CCKMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENHV4HY#issuecomment-592403999, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI5IHEG3YLPIE4S2LM3RFDCXRANCNFSM4K5CCKMA .
On Fri, Feb 28 2020, Vojtěch Bubník wrote:
The way I understand you is that you have a profile that you edit, but do not save yet. In that case the modification of the condition is not taken into account,.
Of course I explicitly save (see the repro instructions).
The profiles you derived from Prusa3D system profiles are considered to be part of the space of the Prusa3D vendor, therefore they are not compatible with non-Prusa3D printer profile. You would need to detach your profile from the system Prusa3D profile by removing or clearing the "inhertis" field.
On Fri, Feb 28 2020, Vojtěch Bubník wrote:
The profiles you derived from Prusa3D system profiles are considered to be part of the space of the Prusa3D vendor, therefore they are not compatible with non-Prusa3D printer profile. You would need to detach your profile from the system Prusa3D profile by removing or clearing the "inhertis" field.
This forces me to make copies of material and print profiles which are identical in their nature. It's very annoying, and feels quite arbitrary given that condition expressions do test for this already.
This forces me to make copies of material and print profiles which are identical in their nature.
We believe that there will be slight adjustments for the material profiles required when applied to different printers.
It's very annoying, and feels quite arbitrary given that condition expressions do test for this already.
Let's wait for the response of the community. We will never make everybody happy. While the condition may be used to check for dependencies across vendor profiles, we made a decision to separate the vendor profile spaces to not require each vendor to add a condition testing for "inside vendor space" condition.
pá 28. 2. 2020 v 10:41 odesílatel wavexx [email protected] napsal:
On Fri, Feb 28 2020, Vojtěch Bubník wrote:
The profiles you derived from Prusa3D system profiles are considered to be part of the space of the Prusa3D vendor, therefore they are not compatible with non-Prusa3D printer profile. You would need to detach your profile from the system Prusa3D profile by removing or clearing the "inhertis" field.
This forces me to make copies of material and print profiles which are identical in their nature. It's very annoying, and feels quite arbitrary given that condition expressions do test for this already.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/3729?email_source=notifications&email_token=ABMPSI5TEBLSQFCBXRCAALLRFDL2VA5CNFSM4K5CCKMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENH44WQ#issuecomment-592432730, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSIZS35TUPYK3CBC6IR3RFDL2VANCNFSM4K5CCKMA .
On Fri, Feb 28 2020, Vojtěch Bubník wrote:
While the condition may be used to check for dependencies across vendor profiles, we made a decision to separate the vendor profile spaces to not require each vendor to add a condition testing for "inside vendor space" condition.
Can I ask where the check is performed? I'd like to tweak my current build to avoid this.
I'd argue it doesn't work as expected from an user's point of view. If I have two printers defined, and I tweak a filament profile, I kept wondering for a long time why I couldn't use that profile on the second printer despite trying to change the check conditions.
Making tweaks to an existing profile and saving it is also what most users do (I bet nobody is starting a print profile from scratch), which compounds to the problem.
As a work-around, I've simply copied/inherited the printer itself from an existing profile because I was tired of checking the flag button just to use a generic profile as a base.
Users might also not be aware how to remove inheritance.
Making tweaks to an existing profile and saving it is also what most users do (I bet nobody is starting a print profile from scratch), which compounds to the problem.
I am considering adding a UI element to support changing the parent profile or at least detaching from the parent profile.
May I ask you what is your workflow? How many printers are you using in the same slicer instance? How many of them are defined in a vendor config bundle? Do you expect the print or filament profiles to be used across vendors?
pá 28. 2. 2020 v 12:29 odesílatel wavexx [email protected] napsal:
On Fri, Feb 28 2020, Vojtěch Bubník wrote:
While the condition may be used to check for dependencies across vendor profiles, we made a decision to separate the vendor profile spaces to not require each vendor to add a condition testing for "inside vendor space" condition.
Can I ask where the check is performed? I'd like to tweak my current build to avoid this.
I'd argue it doesn't work as expected from an user's point of view. If I have two printers defined, and I tweak a filament profile, I kept wondering for a long time why I couldn't use that profile on the second printer despite trying to change the check conditions.
Making tweaks to an existing profile and saving it is also what most users do (I bet nobody is starting a print profile from scratch), which compounds to the problem.
As a work-around, I've simply copied/inherited the printer itself from an existing profile because I was tired of checking the flag button just to use a generic profile as a base.
Users might also not be aware how to remove inheritance.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/3729?email_source=notifications&email_token=ABMPSI5TLNCTGLMW25MTVQ3RFDYSBA5CNFSM4K5CCKMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENIG3XI#issuecomment-592473565, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI5FMSBJ2T5QWUMVPJ3RFDYSBANCNFSM4K5CCKMA .
On Fri, Feb 28 2020, Vojtěch Bubník wrote:
May I ask you what is your workflow? How many printers are you using in the same slicer instance? How many of them are defined in a vendor config bundle? Do you expect the print or filament profiles to be used across vendors?
I have 2 prusa printers (mk3, mk3s) and 2 others (one delta, one i3 clone) defined on my current instance, but I use prusaslicer also on ultimakers (um2+ and 5s) on another system.
I definitely don't want to have multiple material definitions when possible, given most of the parameters are mostly independent of the printer and I can definitely already share all the print profiles across the i3 clone, mk3 and mk3s due to their similarities.
I'd love to make at least the filament presets more printer-agnostic, so that I can avoid to have redundant copies of the same material. One step in this direction that I'm already using is:
https://github.com/prusa3d/PrusaSlicer/pull/3180
I also use expressions in the filament gcode to avoid having two material definitions just to change the LA K factor. I currently do this using keyword matching, but if you remember this:
https://github.com/prusa3d/PrusaSlicer/issues/2562
the main driving reason was also to define variables in the printer definition to be used in print and filament presets so that I could have generic base materials.
The decision to make the print and filament profiles locked to the vendor space of the printer was made to separate the responsibilities of us (Prusa3D) from the 3rd party contributors.
The way Cura handles filaments is by defining the filaments in a single spot (one file per filament) and by defining override sections per vendor and per print settings. The benefit of this structure is the parameter sharing. The drawback is, that someone has to merge the various vendor changes into the common filament profiles. We certainly do not want to go this route as it would put a lot of strain on us, which would also lead to slow profile updates. I bet Cura authors are sorry for this decision now. If the vendor profiles are separated, then it is the vendor responsibility to maintain his configuration space and the vendor profiles may be updated independently and more frequently. We are considering to create a github organization for PrusaSlicer profiles, where each vendor would own and curate a github project for his configurations, and we would have a semi-automatic tool to update the online configs from there. You see, the decision was not arbitrary as it may seem.
We may introduce some kind of a "mother" generic config bundle with printer, filament and print profiles. I have discussed this topic with @rtyr who curates the Prusa3D profiles and his stance was that it would not help him much for the two vendors that he maintains (Prusa3D and Ender). I believe we will collect more data once other vendors and community members start to feed us with their vendor specific config bundles and we may draw some conclusion from there, whether a "mother" profile would be useful. A vendor profile would then be allowed to inherit from the "mother" profile and from its vendor specific profiles, and the vendor config bundle would then also possibly contain a list of "mother" print and filament profiles that it wants to allow to be propagated directly into his configuration space without overriding. This was roughly my initial concept, which we did not implement (yet) because lack of time and because we were not sure whether it is worth the complexity.
For the 2.2.0 release we will most likely add a "detach" button to clear the "inherits" flag when copying a system profile to a user profile. This would allow you to combine that profile with any other profile by adjusting the compatibility conditions. As state above, we may do more in further PrusaSlicer versions based on the feedback of a community. With all respect, we cannot base our decisions on opinions and wishes of a single person.
pá 28. 2. 2020 v 14:33 odesílatel wavexx [email protected] napsal:
On Fri, Feb 28 2020, Vojtěch Bubník wrote:
May I ask you what is your workflow? How many printers are you using in the same slicer instance? How many of them are defined in a vendor config bundle? Do you expect the print or filament profiles to be used across vendors?
I have 2 prusa printers (mk3, mk3s) and 2 others (one delta, one i3 clone) defined on my current instance, but I use prusaslicer also on ultimakers (um2+ and 5s) on another system.
I definitely don't want to have multiple material definitions when possible, given most of the parameters are mostly independent of the printer and I can definitely already share all the print profiles across the i3 clone, mk3 and mk3s due to their similarities.
I'd love to make at least the filament presets more printer-agnostic, so that I can avoid to have redundant copies of the same material. One step in this direction that I'm already using is:
https://github.com/prusa3d/PrusaSlicer/pull/3180
I also use expressions in the filament gcode to avoid having two material definitions just to change the LA K factor. I currently do this using keyword matching, but if you remember this:
https://github.com/prusa3d/PrusaSlicer/issues/2562
the main driving reason was also to define variables in the printer definition to be used in print and filament presets so that I could have generic base materials.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/3729?email_source=notifications&email_token=ABMPSI5JS6FJ56O6KA525UDRFEHDDA5CNFSM4K5CCKMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENIQ2FI#issuecomment-592514325, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI2MIPJW7NGVEEXPF6DRFEHDDANCNFSM4K5CCKMA .
On Sat, Feb 29 2020, Vojtěch Bubník wrote:
The decision to make the print and filament profiles locked to the vendor space of the printer was made to separate the responsibilities of us (Prusa3D) from the 3rd party contributors.
By that argument, this will also mean that you cannot have a "vendor" which is only providing filament profiles for your printers.
Let's say a brand like "Spectrum" wants to join and simply provide profiles of their materials to the MK3/s line, which feels like a win-win argument for both parties.
I guess they cannot do that unless they redefine all printer and print profiles too?
sharing. The drawback is, that someone has to merge the various vendor changes into the common filament profiles. We certainly do not want to go this route as it would put a lot of strain on us, which would also lead to slow profile updates. I bet Cura authors are sorry for this decision now.
There are pros and cons to both ways. I'm very glad we can do both in PS.
For the 2.2.0 release we will most likely add a "detach" button to clear the "inherits" flag when copying a system profile to a user profile. This would allow you to combine that profile with any other profile by adjusting the compatibility conditions. As state above, we may do more in further PrusaSlicer versions based on the feedback of a community. With all respect, we cannot base our decisions on opinions and wishes of a single person.
If you include a detach, for symmetry, copying any profile should populate the inherits flag and display it more prominently. It seems that inherits is currently populated when modifying a base material.
But if I need to detach the base material, well, inheritance is completely useless? If I could implement my own hierarchy (without editing the profile by hand), then I would care less about the vendor check: I would stop using the vendor profiles entirely.
That being said, I still think the vendor check is useless. All print profiles are checking for explicit printer models and features, while the filament profiles check for the vendor in the notes.
If you include a detach, for symmetry, copying any profile should populate the inherits flag and display it more prominently.
This information is shown at the "Dependencies" page of each profile. [image: image.png]
It seems that inherits is currently populated when modifying a base material.
Exactly.
The day has 24 hours and we are 6 developers to work on PrusaSlicer. Code contribution helps only to some extent, as we 6 developers and a single tester are responsible for the code quality, therefore we need to review code contributions line by line, which is sometimes as time consuming, sometimes more consuming than to write the code in house from scratch. There are currently 1280 issues open on PrusaSlicer github and some of the issues are quite critical IMHO. I suppose that because this thread is only yours, you seem to be the only person troubled so deeply by your configuration issue. I would therefore rather spend my time on fixing the thin lines / thin wall issues, FDM support issues, infill path planning issues etc, to make the PrusaSlicer print better.
I really think our discussion is no more fruitful. You have a very strong opinion. I have only 24 hours a day to spend on development and I personally don't think that your proposals are worth the added effort as of now. If we find out in the future that some of the proposals are necessary, we will implement them along the way. If you so strongly believe that you cannot live with that situation, you can fix your issues in your fork and you can offer us a pull request. But as I stressed above, we will not necessarily incorporate your pull request, as an unnecessary complexity in our software means more time and effort maintaining it, meaning either less time to do stuff that we consider important (making the prints better) or less time spent with our kids.
so 29. 2. 2020 v 15:30 odesílatel wavexx [email protected] napsal:
On Sat, Feb 29 2020, Vojtěch Bubník wrote:
The decision to make the print and filament profiles locked to the vendor space of the printer was made to separate the responsibilities of us (Prusa3D) from the 3rd party contributors.
By that argument, this will also mean that you cannot have a "vendor" which is only providing filament profiles for your printers.
Let's say a brand like "Spectrum" wants to join and simply provide profiles of their materials to the MK3/s line, which feels like a win-win argument for both parties.
I guess they cannot do that unless they redefine all printer and print profiles too?
sharing. The drawback is, that someone has to merge the various vendor changes into the common filament profiles. We certainly do not want to go this route as it would put a lot of strain on us, which would also lead to slow profile updates. I bet Cura authors are sorry for this decision now.
There are pros and cons to both ways. I'm very glad we can do both in PS.
For the 2.2.0 release we will most likely add a "detach" button to clear the "inherits" flag when copying a system profile to a user profile. This would allow you to combine that profile with any other profile by adjusting the compatibility conditions. As state above, we may do more in further PrusaSlicer versions based on the feedback of a community. With all respect, we cannot base our decisions on opinions and wishes of a single person.
If you include a detach, for symmetry, copying any profile should populate the inherits flag and display it more prominently. It seems that inherits is currently populated when modifying a base material.
But if I need to detach the base material, well, inheritance is completely useless? If I could implement my own hierarchy (without editing the profile by hand), then I would care less about the vendor check: I would stop using the vendor profiles entirely.
That being said, I still think the vendor check is useless. All print profiles are checking for explicit printer models and features, while the filament profiles check for the vendor in the notes.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/3729?email_source=notifications&email_token=ABMPSIZ66K7VZ2GEUXFMV4TRFENYDA5CNFSM4K5CCKMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENL3OYY#issuecomment-592951139, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI4Q5LBD2FCP6W64ZA3RFENYDANCNFSM4K5CCKMA .
Whoa, I didn't expect this. I'm sorry if this came out as a demand.
Since you expressed some interest, I was just trying to be more argumentative than usual in trying to get the point across. I perhaps went overboard.
For this and the other issues I've filed, keep in mind I'm always fine with a negative answer, let it be that it's not going to be implemented, that there's no time now/never, or simply that you don't like it. I consider issues as points for discussion (because otherwise, where would you discuss it?), and I never expect them to be dealt as demands, but suggestions at_best.
I also manage software projects, so I know how it is. Again, please accept my apology.
@bubnikv
EDIT: Ignore my below comment, I misread your reply on #3818. I'll look forward to the release. Thank you
My issue is that when I purchase filament, I make individual profiles for each filament and use it across all my printers, this takes into account filament diameter averages. While it's easy if you only have 1 printer, it compounds the more printers you have.
I almost never use "Vendor Profiles" except as a starting point. Most vendors, except for Prusament have an average diameter that isn't centered around 1.75mm (1.70-1.74 typically), I've found measuring and adjusting reduces under extrusions significantly.
I almost never use "Vendor Profiles" except as a starting point.
In that case the "Detach" button of PrusaSlicer-2.2.0-rc3 will fit your workflow to a large extent. [image: image.png]
čt 12. 3. 2020 v 2:09 odesílatel DRKMSTR [email protected] napsal:
@bubnikv https://github.com/bubnikv
My issue is that when I purchase filament, I make individual profiles for each filament and use it across all my printers, this takes into account filament diameter averages. While it's easy if you only have 1 printer, it compounds the more printers you have.
I almost never use "Vendor Profiles" except as a starting point. Most vendors, except for Prusament have an average diameter that isn't centered around 1.75mm (1.70-1.74 typically), I've found measuring and adjusting reduces under extrusions significantly.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/3729#issuecomment-597956303, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI3KNMEJO6S72UXJCPDRHAY5HANCNFSM4K5CCKMA .
Just to say @wavexx is not the only person that find it an issue. The more people have different printers, the more there will be demandings on that. Tooks me a while to realize that i have to detach profile to make it compatible. I still click the green flag to see the other profiles.
I gave our stance here: https://forum.prusaprinters.org/forum/prusaslicer/settings-have-all-disappeared/paged/2/#post-317776
If you check the latest PrusaSlicer 2.3.0-beta1 (and the upcoming beta2), you will find out, that the number of 3rd party printer profiles and filament profiles tested for these 3rd party printers is growing. The profiles are contributed to us, while we at Prusa Research are putting our money (the money that we receive for selling our printers) into polishing up these 3rd party printer profiles. I call this a service to the community.
https://github.com/prusa3d/PrusaSlicer/releases
You are most welcome to contribute printer and filament profiles for your favorite 3D printer and we will happily integrate them.
While we explained our stance of why printing with a generic filament profile not tested on a particular printer may not be a good idea, we understand why one would want to use such a generic filament profile as a base for her/his experiments or just try her/his luck with it. We will hopefully implement such a generic filament database into PrusaSlicer 2.4, which will be optionally available with any printer profile (3rd party or custom). A filament loaded from this "base" filament set will be marked to indicate that it is a "generic" profile, not specifically tested with the printer. We started to work on such a feature already, but we did not manage to squeeze it into PrusaSlicer 2.3.
@wavexx I did not investigate into all the details, but could you please check out the new 2.6.0-alpha2 and tell us whether "Template Filaments" solved any of the issues described here? Thanks.
Templates are a very welcomed feature. :-) Just few things:
- The way we activate templates is not so obvious. We have to got through the configuration wizard first.
- I edited manually all xxx_filament_xxx.ini files to set inherits = filament @Template . A reattach to a template would have been nice. You may assume every new derived files will exist with inherits property already set but imagine you have a new filament from a vendor and you want to derive your old filament settings from that new one.