Very confusing cross references between definitions and qualities #1496
Labels
Status: Won't Fix/Do
Not an issue, or an issue that we cannot fix or can live with.
Type: Question
Question about how something works with concrete answers.
Comments
|
The name of the file is used as the id (eg; fdmprinter.def.json gives it the id fdmprinter). When messing around with new profiles I can recommend using the god-mode plugin for Cura. It gives you a whole lot more debug information. Also take a good look at the log files. We know it's a bit annoying how all of this works now, but the system has grown a bit complex over the past few months. |
|
Indeed it is the filename of the definition file (5th point in your list). To fix this, we should remove some of the things in the list.
In the end, the only ones we want/can remove are 1 and maybe 2. |
|
@nallath as recommended on IRC, I used the god-mode plugin (with a suggested patch to make it work with git/master). I was able to fix the various traceback thanks to it but it didn't help with the issue. Issue being: the material and profile are still decorrelated in Cura (I'm supposed to only have a limited number of profile for a given material). More worrying, picking the material has no impact on the material diameter (displayed in the Print Setup), even though going in the Material Manager window displays the correct diameter. So I'm assuming there is still some kind of reference(s) broken somewhere. @Ghostkeeper so if I understand correctly, the file names matter. So this tree is supposed to work: What else should I check? Cura logger only raises tracebacks about |
|
The material diameter thing is a different problem (reported more often). There's basically two material diameter settings and we should unite them. That file tree looks like it's supposed to work all right. Note that most of the file names there don't matter to Cura (as long as they are linked correctly in other files), but are only to organise the files for better maintainability. Is it not working? Does your log say anything about these profiles? |
|
How am I supposed to check which diameter is going to be used then? It doesn't seem to be working because picking a normal PLA such as Chromatik PLA gives me the possibility to pick any profile such as Wood and Flexible. And similarly, picking a flexible-only material (for instance: Polyflex) allows me to pick any profile. Here is my current log: |
So that was the problem! I thought it was crashing for you or not adding the definition or something. It seems to be an issue of documentation then, because all your material profiles have the PLA material type (if they are named accurately). Profiles are filtered on the material type, not on the individual material. If something like woodfill or flexible material needs different quality profiles, then it should have a different material type. If profiles were linked to materials directly rather than material types, then every time a user duplicates a material they'd have to create wholly new profiles for it, even if they just want to adjust the temperature or something. |
|
So wait, currently I have 3 cases of profiles:
What happens if I pick, let's say, the not supposed to be available "fast" profile in the menu when I have the polyflex material? Which settings is it going to use? |
|
If polyflex has its own material type and Note that Polyflex is not PLA, by the way. Its major component is TPU. |
|
I'm seeing the 5 profiles for every material I'm picking: fast, high, normal, wood and flexible, be it PLA, flexible or wood. That's what I'm trying to fix. About Polyflex not being PLA, I'm only porting data from a fork of Cura Legacy, and it says "PLA". Not saying it's correct :) I'll change PLA to TPU when this is actually working. |
|
(Apparently Github dropped my post or I'm going crazy, so I'm reposting again). But instead of a long text, here is a gif to clarify the behavior: Whatever the material I always get all the profiles/quality. But if I manually put garbage into the Still, I'm not supposed to get wood and flexible with the random PLA, and should not get anything else than wood and flexible with the respective polywood and polyflex: |
|
It is indeed confusing. What happens when you change this line? That is the "material type" I was talking about. |
|
This seems to work: the "wood" profile disappears when picking PLA materials, and is only present with PolyWood material. I understand we may want to change that key, but even if we do that, I can't be sure that picking fast/high/normal in the other PLA will actually apply the expected profile... Note: current repository reference is located at https://github.com/ubitux/cura-dagoma/tree/master/output |
Cura makes sure that when a user selects a quality profile on one extruder, all other extruders always have a quality profile with the same quality type at the other extruder. The quality types we have are normal, high, fast and draft. So if you'd select Normal quality for the extruder doing Filo3D PLA while the other extruder has Octofiber, it would select your Also, when a user makes a custom quality profile (called "quality-changes" internally), they get the same quality type as the profile it was derived from. |
|
OK. So in the end, do we agree that there is one bug when only 1 quality is supposed to be available but many of them ends up being available as well? Like, in the current case of PolyWood: what happens when I pick |
|
If you've got Polywood selected as material and it has its own material type, then "standard" should not be in the list to select. Only "Wood filaments" (i.e. |
|
Why "and has its own material type"? We are defining specific configurations for specific materials, not material types! Are you saying that quality profiles can not be specific to a material if they are of the same type? I'm sorry, it looks like we have a huge misunderstanding somewhere, but I'm starting to believe it's not just a bug but a design issue... |
|
It is a design issue. The code that handles the selecting of materials and quality profiles is extremely involved: https://github.com/Ultimaker/Cura/blob/master/cura/Settings/MachineManager.py It might be a good idea at this point to use the God Mode plug-in https://github.com/sedwards2009/cura-god-mode-plugin |
|
So the proper workaround is to change the material type of PolyWood and PolyFlex to something arbitrary different than all the other materials available for a given printer, otherwise I end up with undefined behaviour (because unavailable profiles becomes visible and we don't know which one applies)? Is there a plan or issue opened about that design problem? |
|
It's not undefined behaviour, it's just very complex. That is a design issue. We have a refactor planned for the way that resolve functions work in 2.6, but that is only indirectly related. We also want to change the way that material profiles work one day, which is related, but that is not planned for any specific release yet. |
|
@Ghostkeeper Is this still and issue? I'm also not super experienced at making definitions or qualities. |
ChrisTerBeke
added
Status: Won't Fix/Do
|
As far as I'm understanding, the real problem is that our setting system is complex. It's true, but I don't think there is a solution for this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm trying to add a new printer, but the I'm unable to get the
qualityfiles correctly linked to their printer definition: apparently, a match betweendefinitionin the quality cfg file andidin the definition json file is not enough to make the link.I need to understand how what values are used, because currently I have no idea which elements in this list influence the link:
idvalue in the definition filenamevalue in the definition file (.lower().replace(' ','_')?)overrides.machine_name.default_valuevalue in the definition file (yet another name?)metadata.manufacturervalue in the definition filegeneral.definitionvalue in the quality filesmetadata.materialvalue in the quality file (maybe it needs the name in it somehow?)I've tried many combination, but I'm yet to see any profile show up when I set
has_machine_qualityin the definition file. Maybe there is no bug, but at least there is an issue wrt documentation.The text was updated successfully, but these errors were encountered: