Successful imported profile not showing up

[ChrisBrinton]

Windows 10
Cura 2.6.2
WanHao i3

This looks like the same #1873 (closed) and possibly #2023. Im importing the following profile from WanHao Cura 16.01 and I get a "Profile Successfully Imported" message but the profile doesnt show in my list of profiles.

WHLQ.zip

[ChrisBrinton]

I notice these messages in my Cura.log file:

2017-07-14 18:37:16,178 - DEBUG - cura.Settings.CuraContainerRegistry.importProfile [175]: Attempting to import profile C:/Users/cbrinton/Documents/WHLQ.ini
2017-07-14 18:37:16,179 - INFO - LegacyProfileReader.LegacyProfileReader.read [78]: Importing legacy profile from file C:/Users/cbrinton/Documents/WHLQ.ini.
2017-07-14 18:37:16,201 - WARNING - cura.Settings.CuraContainerRegistry.addContainer [54]: Instance container WHLQ #2 is outdated. Its setting version is 0 but it should be 1.
2017-07-14 18:37:26,211 - DEBUG - AutoSave.AutoSave._onTimeout [48]: Autosaving preferences, instances and profiles

[BagelOrb]

We don't support importing from WanHao Cura.

That being said this looks like a bug on the Cura side which is unrelated to the fact that the profile comes from WanHao Cura.

Please attach the profile.

[ChrisBrinton]

It's the WHQL file on the OP

[Ghostkeeper]

Oh, it looks like we're not putting imported legacy profiles through the version upgrader.

[Z3RO11]

Is there any ETA on a fix or are there any known workarounds?
It still doesn't seem to be working on the 2.7 beta either.

[Z3RO11]

I ended up getting it onto to the latest versions by this workaround.

1. Import the legacy profile into Cura 2.5
2. Install and load Cura 2.6.2, open while 2.5 is still open (Profile will transfer over)
3. Export profile off 2.6.2
4. Install and load 2.7 and import the new Cura profile we just exported

[nickthetait]

I've also run into this issue with Cura 2.7.0 on Ubuntu 17.04.

[hovissimo]

Cura 2.6.1 and Ubuntu 17.04, not seeing my new profile (or an error message) when I try to load the profile at http://download.lulzbot.com/print-profiles/cura/TAZ6_single_extruder_v2.1/nGen_high-quality_TAZ6_single-extruder_0.5noz_cura.ini

From cura.log:

2017-08-15 19:22:58,793 - DEBUG - cura.Settings.CuraContainerRegistry.importProfile [175]: Attempting to import profile /home/hovis/hovissimo@gmail.com/Hobby/3d things/nGen_high-quality_TAZ6_single-extruder_0.5noz_cura.ini
2017-08-15 19:22:58,794 - INFO - LegacyProfileReader.LegacyProfileReader.read [78]: Importing legacy profile from file /home/hovis/hovissimo@gmail.com/Hobby/3d things/nGen_high-quality_TAZ6_single-extruder_0.5noz_cura.ini.
2017-08-15 19:22:58,847 - WARNING - cura.Settings.CuraContainerRegistry.addContainer [54]: Instance container nGen_high-quality_TAZ6_single-extruder_0.5noz_cura is outdated. Its setting version is 0 but it should be 1.

@BagelOrb It looks to me like it recognized a legacy config, but the UI reported that it imported successfully. I don't see the new profile in my profile list.

To clarify, I understand that importing Lulzbot profiles may not be supported - but at least an error message would be nice!

[hovissimo]

Is there a way to update legacy profiles without having to install various old versions of the software?

I found the LegacyProfileReader plugin, but it doesn't look easily extractable. I was hoping I'd be able to run the big read method in that class and pipe the resulting 'profile' (InstanceContainer from Uranium?) object to a profile writer. That might be possible, but the code's thick enough that I got lost.

Edit: Okay now I see the CuraProfileWriter class, and it does look like I could stick these together and maybe get what I want. It looks like I need to set up a dev env for Cura to get to it.

[Ghostkeeper]

The big read method in LegacyProfileReader is called LegacyProfileReader.read(file_name). It indeed should return an InstanceContainer object. I suspect that it hasn't been tested in a while though...

The big write method is located in CuraProfileWriter.

Yes these things require function calls from the rest of the application and expect a machine being present, etc. Especially the LegacyProfileReader, since it will not copy over a value from the profile if it is equal to the default.

[SemperFu]

I'm having this problem trying to import a Cura 15.04.6 profile to Cura 2.6.2

[nickthetait]

If a community member were to put in the hard work to fix this, how could this be comprehensively tested?

Fundamentally, the changes would need to be made to the dictionary of doom right? https://github.com/Ultimaker/Cura/blob/master/plugins/LegacyProfileReader/DictionaryOfDoom.json

How can I see a good overview of how settings have changed since 2.1? Diff between master and 2.1 branches, of what file(s)? Is it in Cura or CuraEngine I should be looking?

[nallath]

Well, you don't have to know what settings changed; The theory is that once we changed it from legacy to 2.1, the upgrader script should take care of it (eg; first upgrade it to 2.3, then to 2.4, etc).

[Ghostkeeper]

Ideally yes, but that's not happening right now. It just leaves the state as it was in 2.1 and then complains that the setting version number is not correct.

For details on the actual changes per version, look at the VersionUpgrade plug-ins in the Cura repository.

[nickthetait]

I am still confused about what is actually broken.

From the following VersionUpgrade plugins I find these seemingly relevant variables:

https://github.com/Ultimaker/Cura/blob/master/plugins/VersionUpgrade/VersionUpgrade21to22/VersionUpgrade21to22.py
_material_translations
_material_translations_profiles
_profile_translations
_removed_settings
_setting_name_translations

https://github.com/Ultimaker/Cura/blob/master/plugins/VersionUpgrade/VersionUpgrade22to24/VersionUpgrade.py
nothing needs changing?

https://github.com/Ultimaker/Cura/blob/master/plugins/VersionUpgrade/VersionUpgrade25to26/VersionUpgrade25to26.py
_removed_settings
_split_settings

2.6 to 2.7 and 2.7 to 3.0
no changes needed?

@Ghostkeeper could you help us better understand what needs fixing?

[Ghostkeeper]

The real reason why it's not loading the profile is because we now require the setting_version version number to be at version 3. The legacy importer imports profiles to be what they should be at Cura 2.1, which had no setting_version field (which is interpreted as version 1).

What has to happen is to have the legacy importer import profiles as a serialized string in the form that they were at 2.1**. Then upgrade that profile with the version upgrade system to the current version of Cura. The version upgrade system will then change the setting_version to 3 and at the same time translate all the setting names and metadata in the profile to whatever it must be for the current Cura version (which is the reason why we introduced the version numbers: to detect that the profile must be upgraded).

The version upgrades of 2.6 through 3.1 are relevant as well, as 2.6 introduced setting_version and all of them did make changes to the files (though not really relevant ones yet in 3.1).

**I said 2.1 just to explain it more logically. In actuality it makes more sense to directly translate it to version 3.1 while we're at it, so that fewer things can go wrong in the upgrade system.

[nickthetait]

This one has been fixed in 3.1 YAY! Noticed it in the release notes and tested it myself 😃