Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Cura plugin profile update overwrite fails #1361
The slicing profiles should be reloaded (preferrably from disk) when user clicks slice and dialog pops up.
I found corner case which I ended up printing with some default settings. And I couldn't find any error messages. Reloading Octoprint page resolves this issue.
What were you doing?
I was copying known good better quality print settings to Cura from slic3r. I imported the profile to Cura plugin and printed a small object. Everything was good except I hadn't changed filament size. Quick fix in cura, export and import the profile hoping the profile would overwrite itself. From the file list I selected the object.stl and sliced it with that profile. and hit print.
What did you expect to happen?
Get the new settings to use.
What happened instead?
The print was started with bed zero, heater 220 and the print looked awful (underextrusion).
Branch & Commit or Version of OctoPrint
Version 1.2.11 (master branch)
Printer model & used firmware incl. version
Reprap P3Steel, Mega, Marlin RC6, RAMPS
Browser and Version of Browser, Operating System running Browser
Firefox 46.0.1, Linux
Link to octoprint.log
[On gist.github.com or pastebin.com. Always include and never truncate.]
From Octoprint.log failed slicing:
And slicing using good profile:
It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).
If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.
I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2016-06-18 20:00) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!
PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.
I cannot reproduce this. What I did:
So the updated profile was in fact used, and in fact importing a profile with the same name as an existing one will overwrite the profile data in the backend on disk. There is no caching in place here that might cause an old version of an updated profile to "linger". So whatever caused your slicing result to come out bad, it was not what you think it was.
Can you reproduce this behaviour reliably?
I started this again. It took me some tries to know how I made the silly mistake. One should not report bugs when they are tired but I think I found the mechanism how I got the default values.
I believe the problem is the slicing wand.
I took a profile and uploaded it as testprofile. I tried to slice with the wand already uploaded file. The profile wasn't there. Refresh populated it there and slicing worked. What I had done originally, was uploaded the fixed profile as different identifier but same name. If I upload with same identifier and name, profile is overwritten and new values are updated as it should be.
Now without refreshing I went and removed testprofile. The slicing wand had the removed testprofile available and it was good to slice. Except it had those default values. 220/ no bed.
So the slicing wand profiles aren't sync with profiles which are really available. I tested this to be true with Firefox on Linux and OS X and also with Chrome on Windows. So slicing wand should ask the profiles from server.