Closed louis1lal closed 3 years ago
I'm not quite sure what you are doing here, but I assume that the Mega X and the Mega S have the same definition, right?
If that's the case, the behavior that you describe is intended; You told Cura to override the settings, which includes any definition changes. If you don't want this, you should let it add it as a new printer.
Everything is the same except the dimensions of the bed. I don't want cura to create an other printer (both are already created) I just want cura to open the project with the printer of the project. In clear, to switch to the right machine, not create a new one every time I open a project with a different printer.
In my opinion, opening a project should never replace any "global" profile or machine settings. it should only change all settings locally (in the scope of the project) to fit the project.
Anyway maybe I could also take a look at the code.
You can also select to override the other printer. It's an option in the dropdown.
I'll add a video to this issue also. as soon as I get time
thanks
Let me know if it is clear or not. I think it is a real problem, because I don't want to change settings back every time I open a project nor create a new profile each time.
here is the link for the video (its more than 10mb so): https://drive.google.com/file/d/1u0rwGdlnSV6qhLCx82nawXUB_GOlfuzQ/view?usp=sharing
Thanks,
But you can also select what printer you want to apply the settings to with this dropdown menu:
You'll want to have it create a new printer then, right? It'll be the same printer model, but a different one in the list of added printers. Then you can switch back to your original at any time when you feel like you're done with the project.
If you read above posts, you will notice it is something I want to avoid. I don't want to have a new printer each time I open a project with a different printer. For now, the work around I use is to set the right printer before opening the project. I still think this is a bug. Watch the video you'll understand
Thanks
Anyway I'll fix that myself or try an other slicer. I think this way it's working is bad.. Thanks
You mentioned that you don't want to create another printer, indeed, since "it's already added". From that I'd interpret that you want to re-use the existing printer that was already added. If you want to use the existing printer, and use the settings of the project file on that printer, it's going to need to change the settings on that printer. You can't use the settings of the project file without setting those settings in Cura. It's mathematically impossible. You either add a different printer, re-use the existing printer, or don't use the settings from the project file at all. Upon loading a project file, Cura will ask you which of those three you want. Sorry, I just don't see a way to improve here. Your expected behaviour is exactly the behaviour that is already implemented.
Did you watched the video at least before? There is definitively something very weird that happens. I think it's just a question of bad conception. The only way it's working like I want, is to change switch to the right printer before opening the project otherwise printer A will update printer B, but it's not what I want.
Thanks,
I'm agree with @louis1lal about anoying this is. Let me explain the lack for me in cura about opening old project. I start to use my machine 2 months ago. Create multiple project using printer, materials and profiles. During this 2 months I made adjustement on my printer start g-code, materials and profiles. I want to reprint something with the last configuration of material, profile and printer... and this is extremely painfull to do, and impossible when you have some unsaved settings that was overriding the profile 2 months ago. I almost find a workaround.
Cura should provide a third option for printer, material and profile in the open project window: Base on. Allowing to base all unsaved settings of the project to be "rebased" on the current ones.
From my developper(but don't knowning how cura is working) POV, I saw the final settings for the object like multiple git commits: 1) Printer 2) Material 3) Profile 4) Unsaved settings I just want to replace 1/2/3 by the current ones instead of the 3mf file ones.
Switch from old (but newly created) printer to the current one: Nothing is asked, the unsaved setting are discarded! Fail !
These settings are stored on that previous printer instance. They are not discarded.
So if I read between the lines, you're looking for a way to transfer unsaved changes from one printer to another? Without actually creating a profile from it?
For me the unsaved settings are specific settings for the current pieces not the current unsaved settings for the current printer. That what I expected. How I have to do for creating overriding settings for one print (due to parts mechanical properties) and easilly update the printer when I want to reopen it?
It's kind of assuming that if you switch to a different printer, the settings you were using on that previous printer don't apply, since you'd be using different nozzles, different materials, etc.
There are so many possible use cases that it becomes extremely complex to support them all. The project files are meant to reproduce the entire state of when the project file was saved. That's currently the scope of it. To transfer or re-use sets of settings that you tuned for a particular object, I think we need something more. The project files are powerful in that they can re-use the existing printers (to prevent getting huge lists of hundreds of printers if you use Cura for a while) but then restoring only select parts of the project is kind of out of scope. Because the underlying layers of profiles are different you'd get a different outcome in your print and your precisely-tuned settings are often just moot. Depends on which settings you tuned.
The custom profiles are intended to be used in multiple use cases:
For the use case of having a print farm set-up with many of the same printer model, Ultimaker printers have their own print cluster system that also automatically creates a shared print queue and divides up the prints among the printers and such, so that has been less of a use case for the profiles in our design so far.
I'd like to make improvements, but I'm very afraid of making the profile system too complex for a user to understand. Restoring only parts of a project file is one thing that I think will be hard to understand for a user.
Currently we can update or create, adding an other to replace by an existing seems not too complexe.
@diorcety I think what they don't understand or maybe they refuse to make the effort to understand, is that, you can have profiles for your printers or your print settings, but opening a project should not replace those profiles. The project should open with all parameters based at the level of the project file, not global profiles files. Everything should not be global. It's a basic notion in software development and to be honest I use tons of softwares and I never had problems of that kind in any other software... But when they say it's mathematically impossible, I think it gives very little hope.
For me this is like if in your Word document they embedded your Word preferences and only allow you to overwrite or to create a new profile when you open it. If you thing at a layered configuration properties you should be able to replace a layer by another one (an existing one for my needs). That can be tricky but when I saw there is already this behavior when changing material I don't understand why this can't be done for the printer. Anyway I will try to do the code modification myself when I will succeed to create the docker on the latest windows 10 version...
It's not that we don't try to understand. I know that you don't want it to override some things (custom profiles) and that you want other things to still override (settings not saved to a profile). And I can understand why: You want your Cura configuration to stay on the latest version of those profiles while still using one-off modifications from the project file. I was trying to explain that the project file was intended for a different use case: To exactly reproduce a workspace. And that it's used for a use case that we did not intend as well: as a way to share profiles.
Fixing it for your use case will ruin those other two use cases, including the main use case of exactly reproducing the workspace. You can't reproduce the workspace without restoring all settings to the same value. And you won't restore all settings to the same value if you want to keep one of the profiles unmodified.
So the only way to go about this is to make this an option. Like I said, I'm afraid that such options are difficult to understand for the user though, and so we have to consider e.g. that out of 100 project file users, maybe 20 will have your problem, and so perhaps 15 may read the open project file dialogue well enough to realise that one of the drop-downs has a solution to it. Counter to that, we'll also have 15 users not understanding it, changing that drop-down and then wondering why it doesn't restore their project exactly, and 5 users changing that drop-down and wondering why it doesn't load the custom profile that their friend shared through that project file. So in the end we'll have helped 15 users, but broken the workflow for 20. Of course you'll probably disagree with those numbers because anecdotally you think your experience happens with everyone. But considering that project files have been in use for years, I don't think it happens that often.
I can see us changing this in the future if we find through research that many people have this problem and would understand the solution for it, and if there is time for it in development (to create the feature as well as to maintain the extra complexity). But currently the scope is only to exactly reproduce a print.
It's not that we don't try to understand. I know that you don't want it to override some things (custom profiles) and that you want other things to still override (settings not saved to a profile). And I can understand why: You want your Cura configuration to stay on the latest version of those profiles while still using one-off modifications from the project file. I was trying to explain that the project file was intended for a different use case: To exactly reproduce a workspace. And that it's used for a use case that we did not intend as well: as a way to share profiles.
Fixing it for your use case will ruin those other two use cases, including the main use case of exactly reproducing the workspace. You can't reproduce the workspace without restoring all settings to the same value. And you won't restore all settings to the same value if you want to keep one of the profiles unmodified.
So the only way to go about this is to make this an option. Like I said, I'm afraid that such options are difficult to understand for the user though, and so we have to consider e.g. that out of 100 project file users, maybe 20 will have your problem, and so perhaps 15 may read the open project file dialogue well enough to realise that one of the drop-downs has a solution to it. Counter to that, we'll also have 15 users not understanding it, changing that drop-down and then wondering why it doesn't restore their project exactly, and 5 users changing that drop-down and wondering why it doesn't load the custom profile that their friend shared through that project file. So in the end we'll have helped 15 users, but broken the workflow for 20. Of course you'll probably disagree with those numbers because anecdotally you think your experience happens with everyone. But considering that project files have been in use for years, I don't think it happens that often.
I can see us changing this in the future if we find through research that many people have this problem and would understand the solution for it, and if there is time for it in development (to create the feature as well as to maintain the extra complexity). But currently the scope is only to exactly reproduce a print.
Ok thanks, I found my to work with Cura. I just never save any projects, I work only with profiles, this way it seems to be okay for my needs. Thanks for taking the time and I know this is a huge software so.
Application version 4.8.0
Platform OSX 10.13.6 (High Sierra)
Printer Anycubic Mega S
Reproduction steps
Expected results The printer should switch to the one used by the project, not overrided
Project file (For slicing bugs, provide a project which clearly shows the bug, by going to File->Save Project. For big files you may need to use WeTransfer or similar file sharing sites. G-code files are not project files!)
Log file (See https://github.com/Ultimaker/Cura#logging-issues to find the log file to upload, or copy a relevant snippet from it.)
Additional information (Extra information relevant to the issue.)