Cura: Profiles are not saving configuration

[rodrigosclosa]

Application Version
3.4.1

Platform
Windows 10 Pro

Printer
Custom

Steps to Reproduce
Any settings that I change from my current profile are lost when I close and re-open Cura. Even if if do an "Update profile with current settings"...

Actual Results
I need to reconfigure all settings.

Expected results
It should save the options.

Additional Information
Nothing

[diegopradogesto]

Can you please provide the logs? I'm wondering if it's a permission error when trying to write to the files.

[rodrigosclosa]

How can i get the logs on Windows?

[fieldOfView]

Help -> Show Configuration folder
The file you are looking for is cura.log

[rodrigosclosa]

Nothing happens when i click Help > Configuration Folder..

[fieldOfView]

Then you will have to open it manually

Press winkey, and type %APPDATA%\cura\3.4

[foulkn]

I am having the same problem.
Same setup as OP but using ubuntu 18.04 LTS.

Removed configuration files for Cura 3.2 thinking it may be loading those every time.
did not help.

Edit:
Duplicated the profile from 3.2 and seems to save the new profile correctly.

[diegopradogesto]

We are still waiting for some log files or configuration folder to further investigate on this. Otherwise we can't guess anything.

[JPFrancoia]

Hi, I have the same problem on Archlinux. Running Cura 3.4.1 from the Appimage.

Log:
cura.log.txt

The log corresponds to the following actions:

• starting Cura
• changing the adhesion method in my current profile: from raft to skirt
• closing Cura
• Starting Cura (adhesion method is set to raft, while it should be skirt)

I hope this helps, even if I'm not in the same conditions as OP.

[diegopradogesto]

Can you also zip your 3.4 configuration folder and send it to us? I can't find anything weird in the logs.

[JPFrancoia]

As I didn't know what folder you were talking about, here are .local/share/cura/3.4 and .config/cura/3.4:

config-cura.zip

local-share-cura.zip

[BBQFromIowa]

Similar issue as OP.
If I open Cura 3.4.1 from Windows Start menu . I get one profile setting values.
If I open from \program files... cura.exe I get another
it acts like it is picking up an older profile from somewhere. I've add earlier versions installed and uninstalled.

logs attached . open from menu vs open from exe

open_from_exe.zip
open_from_menu.zip

[compatibilizer]

Same issue. I am using 3.4.1 with the profiles I created on 3.3.1, profiles were imported automatically to 3.4.1.

Issue is that, I can not modify the profile when selecting "Update profile with current overrides". If I make some changes and exit without saving, Cura will properly remember the changes, but still show the star sign, to remind me to save the changes. But when I save with selecting "update with current overrides" it will revert back to the settings it imported from 3.3.1

[compatibilizer]

Just found a temporary solution. When new changes are made to your profile, exit Cura without saving the changes. Then restart Cura and it will "remember" your changes. Now save the profile without making any additional changes. It will properly overwrite your profile if done like this.

[compatibilizer]

Nope, does not work. It looks like working as described above, but as soon as you change to another saved profile, it does return to the settings it imported from 3.3.1

Is it only me that thinks this issue is an urgent one? I'll be downgrading to 3.3.1 for now, as this issue makes the current version unusable to me.

[revvexd]

Had the same problem but got it to work:
The profile that was "unsavable" was an imported one so this might be the culprit.
I changed the settings, saved the overrides as new profile and the new one actually kept its changes, even after a restart.
Ultimaker pls fix.

[nallath]

I can't reproduce any of this. Even with the local files as provided (i actually replaced my local config with the one that you provided). So it's not so much that we don't want to fix it, it's that we don't really know what the issue is.

[Hotwire-]

This issue is driving me mad. The outcome after saving a profile is almost random.
Once you change a parameter from the default it should stay changed unless you request a return to default value. This isn't whats happening.
Please look at this issue soon. I have to check custom parameters every time I use Cura, which is every day.

[JPFrancoia]

@Hotwire- same here, I use it for work. For now I'm staying on 3.3.1 Appimage until I'm totally sure it's fixed.

However, now that @revvexd mentioned it, same for me: the profiles that can't be changed and saved are imported ones. Old ones, that I've been using through multiple versions for maybe a couple of years. Maybe that helps.

[fusentasticus]

The problem is intermittent but I have an idea of what's wrong. On my Linux box, the act of saving profiles appears to not work. But that's not the problem.

Rather, it seems to be the _reading_ or parsing of the quality_change file of the profile that doesn't work except in one reproducible scenario. I believe that a race condition is in play with some inverted logic somewhere. Could this be linked to asynchronous parsing of the INI files or Qt caching?

Version and variations

Cura version

3.5.1 (but problem in 3.4 as well afaik)

Printer configuration file

Custom for Trinus (shown at end of message)

Profile used in every run of Cura

Trinus funny_holder (which I gather is recorded as the default in extruders directory, I don't change extruder either during tests); so I don't change profile explicitly, Cura remembers the last one used

Variations tried:

1. with USB enabled & octoprint disabled
2. with USB disabled and octoprint enabled
3. rm-rd ~/.cache/cura before starting Cura

Method

I start Cura (with changed profile directory, shouldn't matter) with:
```.sh-session
$ XDG_DATA_HOME="/home/user/mycura" ~/Software/Cura-3.5.1.AppImage &

I make sure at most one instance of Cura is running. Then I monitor my profile named "funny holder". That's to fish for the lines where the value of `flow` is kept (I keep it abnormal because of hardware customization) as in:
```.sh-session
$ find  ~/mycura/cura/3.5 -name '*trinus*holder*.cfg'  -exec grep -H 'material_flow.*' {} \;
/home/user/mycura/cura/3.5/quality_changes/trinus_trinus_funny_holder.inst.cfg:material_flow = 500
/home/user/mycura/cura/3.5/quality_changes/fdmextruder_%232_trinus_funny_holder.inst.cfg:material_flow = 483
/home/user/mycura/cura/3.5/quality/trinus_trinus_funny_holder.inst.cfg:material_flow = 500
/home/user/mycura/cura/3.5/quality/fdmextruder_%232_trinus_funny_holder.inst.cfg:material_flow = 505

Expected

In this situation, where I use extruder #2 I expect Cura to show a flow value of 483 when I start it. When I change the flow parameter within Cura to say 484, I'd expect 483 in the fdmextruder file under quality_changes to be changed to 484 immediately.

What happens

1. If Cura is restarted right after I've closed it down, the value 505 from quality is shown. That's wrong: the quality_changes is ignored. However, if I wait several minutes between shutting down Cura and restarting it, I always see 483 from quality_changes.
2. Even when Cura loads correctly, I've observed that when I change 483 to 484 in the flow parameter and then click on the expand menu icon in the name of the profile and issuing "Update profile with current settings/overrides", the file fdmextruder_%232_trinus_funny_holder.inst.cfg is not updated on disk. Only when I go to "Manage Profiles" or I shut down Cura is the file updated. (This may be a problem if Cura crashes, however, the problem is _not_ that changes are not written to disk afaik.)

What about changing profiles during a run of Cura?

If I change to a different profile in Cura, the quality_changes data is almost never loaded. But sometimes it is.

My definitions file

{
    "version": 2,
    "name": "Trinus",
    "inherits": "fdmprinter",
    "metadata": {
        "manufacturer": "Kodama",
        "visible": true,
        "author": "Dude McDude",
        "category": "Kodama",
        "file_formats": "text/x-gcode"
    },
    "overrides": {
        "machine_name": {
            "default_value": "My Trinus"
        },
        "machine_heated_bed": {
            "default_value": true
        },
        "machine_width": {
            "default_value": 120
        },
        "machine_height": {
            "default_value": 125
        },
        "machine_depth": {
            "default_value": 125
        },
        "machine_center_is_zero": {
            "default_value": false
        },
        "machine_nozzle_heat_up_speed": {
            "default_value": 2.0
        },
        "machine_nozzle_cool_down_speed": {
            "default_value": 2.0
        },
        "gantry_height": {
            "default_value": 12
        },
        "machine_gcode_flavor": {
            "default_value": "RepRap (RepRap)"
        },
        "machine_nozzle_size": {
            "default_value": 0.25
        },
        "material_diameter": {
            "default_value": 1.75
        },
        "machine_start_gcode": {
            "default_value": "M106 S0 ; Turn off material fan\nG28 ; home all axes\nG92 E0 ; reset extruder position\nG1 X0 Y0 Z0.3 F3600 ; go to prime start point\nG1 E5.0 F200 ; unretract (E5)\nG1 Y10 E12.0 F200 ; slow prime extruder (E12)\nG1 Y35 E20.0 F600 ; finish priming extruder (E20)\nG1 Y80 Z0.1 F3600 ; wipe extruder\nG92 E0\n"
        },
        "machine_end_gcode": {
            "default_value": "M106 S0 ; turn off material fan\nG0 Z120.000 Y115.000 X0.000 ; move head away from print\nM84 ; disable motors\nM140 S0 ; turn off heated bed\nM104 S0 ; turn off extruder\nM53 ; full stop: prevent double prints\nM84 E; disable extruder motor\nM84 Z; release Z motor\n"
        }
    }

[Hotwire-]

Don't update profiles just save as a new profile and delete the old.
Cheers

On Thu, 25 Oct. 2018, 8:40 am fusentasticus, [e-mail]
wrote:

The problem is intermittent but I have an idea of what's wrong. On my
Linux box, the act of saving profiles appears to not work. But that's not
the problem.

Rather, it seems to be the reading or parsing of the quality_change
file of the profile that doesn't work except in one reproducible scenario.
I believe that a race condition is in play with some inverted logic
somewhere. Could this be linked to asynchronous parsing of the INI files or
Qt caching?
Version and variations Cura version

3.5.1 (but problem in 3.4 as well afaik)
Printer configuration file

Custom for Trinus (shown at end of message)
Profile used in every run of Cura

Trinus funny_holder (which I gather is recorded as the default in
extruders directory, I don't change extruder either during tests); so I
don't change profile explicitly, Cura remembers the last one used
Variations tried:

1. with USB enabled & octoprint disabled
2. with USB disabled and octoprint enabled
3. rm-rd ~/.cache/cura before starting Cura

Method

I start Cura (with changed profile directory, shouldn't matter) with:

$ XDG_DATA_HOME="/home/user/mycura" ~/Software/Cura-3.5.1.AppImage &

I make sure at most one instance of Cura is running. Then I monitor my
profile named "funny holder". That's to fish for the lines where the value
of flow is kept (I keep it abnormal because of hardware customization) as
in:

$ find ~/mycura/cura/3.5 -name 'trinusholder.cfg' -exec grep -H 'material_flow.' {} \;/home/user/mycura/cura/3.5/quality_changes/trinus_trinus_funny_holder.inst.cfg:material_flow = 500/home/user/mycura/cura/3.5/quality_changes/fdmextruder_%232_trinus_funny_holder.inst.cfg:material_flow = 483/home/user/mycura/cura/3.5/quality/trinus_trinus_funny_holder.inst.cfg:material_flow = 500/home/user/mycura/cura/3.5/quality/fdmextruder_%232_trinus_funny_holder.inst.cfg:material_flow = 505

Expected

In this situation, where I use extruder #2
https://github.com/Ultimaker/Cura/issues/2 I expect Cura to show a flow
value of 483 when I start it. When I change the flow parameter within Cura
to say 484, I'd expect 483 in the fdmextruder file under quality_changes
to be changed to 484 immediately.
What happens

1. If Cura is restarted right after I've closed it down, the value 505
   from quality is shown. That's wrong: the quality_changes is ignored.
   However, if I wait several minutes between shutting down Cura and
   restarting it, I always see 483 from quality_changes.
2. Even when Cura loads correctly, I've observed that when I change
   483 to 484 in the flow parameter and then click on the expand menu icon in
   the name of the profile and issuing "Update profile with current
   settings/overrides", the file
   fdmextruder_%232_trinus_funny_holder.inst.cfg is not updated on disk.
   Only when I go to "Manage Profiles" or I shut down Cura is the file
   updated. (This may be a problem if Cura crashes, however, the problem is
   not that changes are not written to disk afaik.)

What about changing profiles during a run of Cura?

If I change to a different profile in Cura, the quality_changes data is
almost never loaded. But sometimes it is.
My definitions file

{
"version": 2,
"name": "Trinus",
"inherits": "fdmprinter",
"metadata": {
"manufacturer": "Kodama",
"visible": true,
"author": "Dude McDude",
"category": "Kodama",
"file_formats": "text/x-gcode"
},
"overrides": {
"machine_name": {
"default_value": "My Trinus"
},
"machine_heated_bed": {
"default_value": true
},
"machine_width": {
"default_value": 120
},
"machine_height": {
"default_value": 125
},
"machine_depth": {
"default_value": 125
},
"machine_center_is_zero": {
"default_value": false
},
"machine_nozzle_heat_up_speed": {
"default_value": 2.0
},
"machine_nozzle_cool_down_speed": {
"default_value": 2.0
},
"gantry_height": {
"default_value": 12
},
"machine_gcode_flavor": {
"default_value": "RepRap (RepRap)"
},
"machine_nozzle_size": {
"default_value": 0.25
},
"material_diameter": {
"default_value": 1.75
},
"machine_start_gcode": {
"default_value": "M106 S0 ; Turn off material fan\nG28 ; home all axes\nG92 E0 ; reset extruder position\nG1 X0 Y0 Z0.3 F3600 ; go to prime start point\nG1 E5.0 F200 ; unretract (E5)\nG1 Y10 E12.0 F200 ; slow prime extruder (E12)\nG1 Y35 E20.0 F600 ; finish priming extruder (E20)\nG1 Y80 Z0.1 F3600 ; wipe extruder\nG92 E0\n"
},
"machine_end_gcode": {
"default_value": "M106 S0 ; turn off material fan\nG0 Z120.000 Y115.000 X0.000 ; move head away from print\nM84 ; disable motors\nM140 S0 ; turn off heated bed\nM104 S0 ; turn off extruder\nM53 ; full stop: prevent double prints\nM84 E; disable extruder motor\nM84 Z; release Z motor\n"
}
}

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/4162#issuecomment-432837939,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIatsE1Pkap_jIhJogzSRHhQe9AZ6u9eks5uoN48gaJpZM4VnWmT
.

[fusentasticus]

Thanks so much -- so I tested 10 times and it worked every time!!! The new profile has '_#4' appended to the file name before ".cfg" in the quality_changes folder. Apparently, this file is then parsed every time I shift to the profile '#4' or re-start Cura. So the trick is needed only once I think.

But of course to rescue an existing profile this way, it has to be read correctly in the first place, and that apparently is possibly on my box by selecting it in Cura, shut down Cura, wait 10 minutes, and then restart Cura.

ps: I understand how the printer profile system grew to be so complicated over time. It could be enormously simplified and generalized at the same time if an off-the-shelf data templating language like jsonnet was used and user changes were simply stored in the project, along with the ability to point to predefined and user defined templates. These templates would define how blue PLA is printed or how a dozen speed settings are calculated from the general speed setting or whatever and all these little calculations and settings can customized by users and deployed in an enterprise by pointing to them.

[JPFrancoia]

Hi @fusentasticus , could you explain how you solved the issue please?

Was it:

Don't update profiles just save as a new profile and delete the old.

If yes, maybe Cura could check the profile version each time it tries to save, and then override the old profile with the new format?

[fusentasticus]

To summarize what I did in part following @Hotwire

• start Cura and load the old profile
• check that it actually loaded correctly
• if it didn't, then shut down Cura, wait ten minutes and start it again, the profile will load, perhaps correctly
• when loaded correctly, use "Create profile with current..." to make a new profile (perhaps change a parameter a tiny bit to un-grey the option)
• this new profile then seems to work as expected

[diegopradogesto]

Hi all. I would like you to know that we look at all issues, some are more urgent than others and I consider this as a "quite" urgent, but first we need to be able to reproduce it in order to determinate what is going wrong.

From the moment we got the configuration files from @JPFrancoia we tried to reproduce this issue. @nallath and me were trying without success. We don't have any problems imported profiles. We have automated tests for those kind of scenarios and we still don't see anything wrong.

Now is good to see a complete report from @fusentasticus . However I couldn't reproduce it following this steps (please correct me if I'm not doing it right):

1. User your definition file (that is not included in Cura)
2. Add a "Trinus" printer
3. Modify material_flow (for instance). By default is 100, I set it to 125.
4. Create a new profile: "my awesome profile".
5. Check that the flow value is correct (=125)
6. Restart Cura.
7. When running again, check the flow value is still 125 -> OK

After this I also tried:

1. Modify the material_flow value to 250.
2. Click on "Update profile with current settings"
3. Restart Cura.
4. When running again, check the flow value is still 250 -> OK

After this I also tried:

1. Modify the material_flow value to 500.
2. Don't save the value, just leave it as a user_changes value.
3. Restart Cura.
4. When running again, check the flow value is still 500 -> OK

Manually checking the configuration files, all of them look correct.

Sooooo, we can keep trying to reproduce it but we can't do anything unless we find an easy scenario to reproduce the issue.

[Hotwire-]

The issue is Cura 3.4.1 and 3.5.1 will not save profiles that are imported
from previous versions. Once you create a new profile, e is reproven from
an old profile, that profile will update correctly.
It's only a big deal if you are unaware of the need to create a new profile
in order to change and update values permanently. It is certainly
reproducible.

On Fri, 26 Oct. 2018, 11:45 pm Diego Prado Gesto, [e-mail]
wrote:

Hi all. I would like you to know that we look at all issues, some are more
urgent than others and I consider this as a "quite" urgent, but first we
need to be able to reproduce it in order to determinate what is going wrong.

From the moment we got the configuration files from @JPFrancoia
https://github.com/JPFrancoia we tried to reproduce this issue. @nallath
https://github.com/nallath and me were trying without success. We don't
have any problems imported profiles. We have automated tests for those kind
of scenarios and we still don't see anything wrong.

Now is good to see a complete report from @fusentasticus
https://github.com/fusentasticus . However I couldn't reproduce it
following this steps (please correct me if I'm not doing it right):

1. User your definition file (that is not included in Cura)
2. Add a "Trinus" printer
3. Modify material_flow (for instance). By default is 100, I set it to
   125.
4. Create a new profile: "my awesome profile".
5. Check that the flow value is correct (=125)
6. Restart Cura.
7. When running again, check the flow value is still 125 -> OK

After this I also tried:

1. Modify the material_flow value to 250.
2. Click on "Update profile with current settings"
3. Restart Cura.
4. When running again, check the flow value is still 250 -> OK

After this I also tried:

1. Modify the material_flow value to 500.
2. Don't save the value, just leave it as a user_changes value.
3. Restart Cura.
4. When running again, check the flow value is still 500 -> OK

Manually checking the configuration files, all of them look correct.

Sooooo, we can keep trying to reproduce it but we can't do anything unless
we find an easy scenario to reproduce the issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/4162#issuecomment-433395245,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIatsH86Zxhf9OXyTlYVYbr6GdGetTQLks5uowP1gaJpZM4VnWmT
.

[fusentasticus]

@diegopradogesto Thanks so much for trying to reproduce this.

However, I don't think you'll be able to! (Unless you invest in testing infrastructure as if you were designing rocket software!)

The user reports already point to a race condition or cache issue in what should be a strictly sequential and deterministic algorithm for parsing all the configuration files. Formally, it's not - as I found out in https://github.com/Ultimaker/Cura/issues/4659. That particular issue relates to a magic value of 300 milliseconds and an unorthodox asynchronous recursion. This may not be the problem that trips up users at random (I didn't read any code carefully) but I'd recommend starting with the low-hanging fruit like this.

In my opinion, you have a situation that calls for a careful code re-review to get rid of all possible multi-threading via call-backs, timers, etc. in your initialization code that constructs the property or dependency graphs. Meanwhile, users will keep getting random, often rare, errors while a few select ones (like me on my old clunker of a Linux box) will see them very often.

My opinion is you can likely solve the problem with no further input from users. I'll be happy to test out a new version as a Linux app.

@Hotwire- are you sure that the profiles are not actually saved to disk? Did you verify that your changes were not written to the quality_changes folder? I ask because I think they are saved to disk but just not read correctly. That's what I saw when monitoring my system. The user experience (like believing you're going dotty) will be the same 😃

[Robyrob]

I have the same problem in v. 3.6.0. I have windows 10
I discovered that changes are saved in folder \AppData\Roaming\cura\3.6quality_changes\custom_extruder_1_roby++avarage+0.2+mm.inst.cfg
and open from folder \AppData\Roaming\cura\3.6quality\custom_extruder_1_roby++avarage+0.2+mm.inst.cfg

I think that this is the problem: save in a folder and open in enother.

Some time, randomly, it open the right settings, from quality folder !!

[diegopradogesto]

Hi @Robyrob , can you provide the 3.6 folder (and maybe the previous folders, such as 3.4 and 3.5)? You can zip it and attach it to this ticket.

[Robyrob]

OK. Here are my folder 3.6 and the two files *.log.
I changed the value of "Initial Layer Flow" from 130 to 140 and then "Update profile with current settings".
The file in the folder quality_changes was update.
I tried to close and reopen the Cura. The first tree times the value was 140 and the fourth was 130 !!! I tried some more close/reopen and value changes 130 or 140 randomly

3.6.zip
stdout.zip

I don't think they are important, as I don't remember my action in that version, but I include also include
3.4 3.5 3.2 3.3
3.2.zip
3.3.zip
3.4.zip
3.5.zip

[fusentasticus]

@Robyrob I'm curious: are you also running on a machine with an magnetic hard drive (not SSD)? The trick about saving the configuration as a new one (once you're lucky to read it in correctly) has worked flawlessly on my five year old Linux PC since I whined about the problem earlier. I think you're confirming too that the problem is not actually that of saving the configurations but that of loading them again. The potentially nasty thing is that all users may experience this occasionally dependent on how "warm" various caches on the Cura host are (which parts of files have been read into memory from disk). Thanks to Cura developers for keeping looking into it.

[Robyrob]

@fusentasticus Yes my PC has a magnetic hard disk. it is a HP Pavilion h8-1010it . 7 years old !
I am keeping old versions, just in case...
What should be the difference in a pc with ssd?
The configuration is saved correctly in \AppData\Roaming\cura\3.6quality_changes\
The problem is when you open the program Cura. Sometime read the right configuration file, some other doesn't. I can't find a relation to other task. I just close and reopen Cura!.

[fusentasticus]

@Robyrob The solid state drives will not let Cura wait over and over for all that mechanical stuff that has to happen before the files have been read the first time. That shouldn't actually matter but there's a timing bug in Cura somewhere that messes things up. The second time you start Cura the files are in RAM (they're cached or warmed up) and the bug won't be triggered. The developers won't see this problem because they have newer machines I guess.

[betavr]

Same here with cura 3.6, can't save profiles at all. Switching back to 3.2. Would have been nice to have built in repetier support, but it will have to wait I guess.

Btw this is with win10 on a relatively modern computer (i7 5820k). Cura is installed on a classic hdd, but its configuration folder is on a ssd.

[betavr]

Ok, so it looks like deleting everything from the folder c:\Users\beta\AppData\Roaming\cura\3.6\quality_changes\ solved the problem for me. I recreated my profiles from scratch and now they can be saved as usual.

[vstruk]

Same issue. Saving profiles imported from older versions (3.1 in my case) to 3.6 is broken. I press 'update profile with the current settings', everything seems OK but settings are rolled back after cura restart.

Brand new profiles created in 3.6 are saving successfully.

[Robyrob]

Same issue with Version 4.0.0-Beta
@fusentasticus I also changed my hard drive from magnetic hard drive to SSD (samsung ssd 860 EVO): any difference, same issue.

[Ghostkeeper]

So reading through this thread, it appears that this issue only occurs sometimes depending on the speed of your hard drive?

[Robyrob]

@Ghostkeeper I do not think the speed of the hard disk is the matter. Recently I changed my from Hard Disk to SSD and the problem is the same. Randomly!

[BlondieGayMan]

I don't know if this has been covered, but I'm on 3.6.0 and has the same problem. Not of the workaround that I saw worked.
I had made changes to what I wanted, i.e. old setting was Brim, I changed to raft. Old Print Speed was 50 I changed to 40.
I then exported to a new profile name then imported it.

This did not work as the new profile had the old numbers and options selected.

When I changed the numbers back to what I wanted, I noticed that on the "Profile" filed (near the top) there was a STAR there.

When I clicked on that star, Cura said that there have been changes that are now different than what the profile has and if I'd like to save to this profile.

I clicked to allow that. Then to test it, I loaded a different profile and things changed as they should, then changed back to this profile and WALAH! The settings changed to what they should be (speed 40, raft, etc).

Being new to Cura, I don't know if this is actually the same as what others are talking about. But it sure seems like it.

Hope this helps.

[emertonom]

I'm still having this issue in 4.0. I don't think it's related to disk caches, because after doing an "update profile" or indeed a "create profile from current settings," if I then look at the relevant profile in the "manage profiles" dialog, it shows the wrong settings. E.g., my line width is currently set to 0.6, the same as my nozzle size. I did "create profile from current settings," and the dialog says "your current settings match the selected profile," but it also shows the line width setting in the profile as 0.44, which is what it periodically reverts to, even though I haven't used that setting in months.

Interestingly, it does show the line width of 0.6 under "extruder 1" in the same dialog, suggesting that this is being treated as an override. The same seems to be true for my print speed settings: wrong setting under "global settings" for this profile, but the right setting under "extruder 1" for this profile. It's unclear to me what the significance of these two panels even are in this context. But it makes me suspicious that this has something to do with the random reversions.

[Ghostkeeper]

The table in the profiles page in the preferences has been a bit unreliable for a long time. In this case it may be showing something underneath that has to do with this bug.

[skeltoac]

This issue is affecting me in Cura 4.2.1 on Mac with my Ender3. I am going to have to start writing down all of my settings and re-entering them every time I use Cura because I can not rely on the profiles at all.

I noticed a detail in the naming of the cfg files: the printer and extruder parts of the file names have +%232 and +%233 etc. (i.e. #2 and #3) which reminds me that I have deleted and recreated these printers in the past. Please try this step when attempting to reproduce the issue.

I also noticed that the file names have extruder_0 while the GUI shows Extruder 1.

[Ghostkeeper]

The #2 occurs when the #1 version was correctly loaded. However maybe it doesn't show the original one? It could also still occur if the original was deleted after the new one was created.

The extruder_0 vs "Extruder 1" is weird yes, but unfortunate. It's because some guy called Alcuin of York decided that some letters should be written with an uppercase symbol simply because they are the first. And because everyone except programmers seem to think that "1" is the first number.

[skeltoac]

@Ghostkeeper I'm having trouble understanding how your comment helps. The settings that were active when I saved the profile were not active after I loaded it again, so "correctly loaded" is suspect. With your comments about the details I provided, you appear to have missed the point. Does condescension attract or repel good contributors in your experience?

[Ghostkeeper]

The first part of my comment was trying to help. The second part was trying to be funny (and maybe interesting). Sorry. The extruder_0 is more useful to programmers (so we show it to the programmers) while the Extruder 1 is more what non-programmers tend to expect (so we show it to the users). That's the real answer there. I didn't think you thought it was a real problem.

For the #2, it is expected that there is a "#2" there if there was already a profile. That's what I was trying to say. I didn't know that the original "#1" profile wasn't showing up.

Upon creating a new printer or profile, it looks through the printers/profiles that are currently loaded and finds the first number that is not occupied. So if it skips the actual name and directly goes to #2, that would mean that something is being loaded. But if the original one is not showing for you that would mean that something got corrupt somewhere. It's hard to say exactly what happened without a log or configuration folder from here. If I add a printer, delete it again and add a new one, the new one takes the name without any #.

[skeltoac]

Thanks for clearing that up. We are both programmers with long experience. I don't have a problem with displaying capitalized words and 1-indexed numeric series to end users. I do consider it a potential area for programming errors, although unlikely because the translation is usually one-way (from raw data to display, not the reverse) I haven't had time to dive into Cura's codebase yet.

As for the #2 and #3 that I mentioned, I was saying that they were encoded in the names of the cfg files in the positions where the printer and extruder names are used to generate the filenames. Not in the names of the profiles themselves. This might be a clue to help find the root cause of this issue.

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.