Page MenuHomeAleph Objects Inc

Cura 2 ini profiles export
Closed, WontfixPublic

Description

Wanted to get an export of all Cura 2 profiles. We are creating a new branch for easier editing of Cura 2 ini's that will be similar to our current Cura print profiles branch. Let me know if you have any questions thanks.

Event Timeline

@victor_larchenko See https://code.alephobjects.com/diffusion/P/
@patrickaleph , if I understand correctly, you want the profiles for the mini/taz/etc.. to be stored in the 'Print Profiles' repository in a cura2 directory, just like the Cura profiles were in a separate directory as well ? So the task would be to copy all the profiles from cura2 into the Profiles repo, and delete them from the Cura2 repo, and have the build system copy them over ? Or maybe just have a copy of the profiles in the print profiles repository but keep the ones in cura2, and just sync them manually whenever there's an update to profiles ?

This was before I realized cura 2 handles profiles differently from the original cura. We will have to brainstorm the best way to have people change cura 2 profiles. The plan is to have many people working simultaneously on profile changes so we will have to brainstorm the best way to do this.

@patrickaleph Bam and I are meeting at 9am, care to join us?

kakaroto added a comment.EditedFeb 22 2017, 10:26 AM

I'm assigning this to @cj. Having the profiles (materials and quality) inside of Cura2 is not practical since @karrad needs to be able to modify them with ease, and they really count more as cura-data rather than cura-code. Even upstream has separated their materials (not the qualities though) into a separate fdm_materials repository.
@cj, what we'd need you to do is to change the cmake script so that it copies the files from the print profiles repository (cura2 directory) into the cura2/resources directory when building it.
Basically clone this https://code.alephobjects.com/diffusion/P/ and add a step where it does a : "copy -r profiles/cura2/* ${EXTERNALPROJECT_INSTALL_PREFIX}/share/cura2/resources"

Edit: I've added profiles from cura2 to the Print profiles repository in the experimental branch. I've also left them for now in the Cura2 repo itself until the build system has been updated.

@kakaroto we are sending out printers to our filament vendors to generate their own profiles for filament. Once they have the settings to where they would like, they will be submitting .curaprofile changelog with their changes for our testing and incorporation. At the moment we plan to have them log those as tasks in the profile column here: https://code.alephobjects.com/project/board/10/

Will this cause any issues, or would you prefer these submissions in a separate location?

@karrad , There is a print profiles project which already has a 'cura2 profiles' workboard, I think that would be the best place to put them, this way it won't interfere with the other tasks for actual cura2 development : https://code.alephobjects.com/project/view/16/
After we make the move (profiles are already added in the print profiles repository, it's just not yet integrated in the build script), since you'd have commit access to the print profiles repository, you'd have more freedom to do the changes yourself instead of creating tasks and waiting for @victor_larchenko to do the changes you requested (like T735, T736, T737, T738, T739, etc..), which will be faster and easier for everyone involved, with a lot less overhead.

@kakaroto At the moment we are only able to export a .curaprofile when we select export. From what we can tell this only logs specific changes to built in profiles. Is there a way to export every setting?

At the moment, we are worried about changing built in profiles as the .curaprofile will not have any information about the base profile we changed. This can create problems for customers that have generated their own "tweaks" using the .curaprofile export function.

kakaroto added a comment.EditedFeb 22 2017, 2:11 PM

Ah I see, that's what you meant by "cura2 handles profiles differently from cura original". Well, I've grabbed a .curaprofile (the one in T746) and realized it's a zip file, so I renamed it into .zip, extracted the file (which had no permissions, so after chmod a+r), and I got this :

[general]
version = 2
name = HighSpeed_Bamboo_ColorFabb
definition = lulzbot_mini

[metadata]
quality_type = bambooFill_(colorFabb)_Standard_mini
type = quality_changes

[values]
layer_height = 0.4

This basically tells me that it's a modification to do to a quality profile ( type = quality_changes ) which is the file : resources/quality/lulzbot_mini/bambooFill_(colorFabb)_Standard_mini (combination of [general] definiton and [metadata] quality_type), and the change is the layer_height needs to be changed into 0.4.

I think this makes it relatively easy to know what needs to be changed in the profile, and would allow you to make the changes to the profiles using only the .curaprofile files.
I can later look at whether or not cura2 supports exporting a full profile.

EDIT: @karrad if you find a non-obvious .curaprofile content, or you have any difficulties, you could always ask us of course.

@kakaroto

Our concern with the .curaprofile usage for changing items is it references a built in profile. In your example, it states that only the layer height needs to be changed from the:

[metadata]
quality_type = bambooFill_(colorFabb)_Standard_mini
type = quality_changes

What would happen if we made changes to the bambooFill_(colorFabb)_Standard_mini profile or settings, rebuilt the program, and distributed under a new revision? If we changed any setting from the built in profile (acceleration, speed, jerk, etc) would a customer loading the .curaprofile (say from T746) revert those changes? We are concerned of people spending a lot of time tweaking settings to get them just right, us pushing an update, and making those changes not work.

If we could export a full profile I think that would prevent the issue. (As far as I can tell it won't revert our built in changes.)

That wouldn't be a problem because the profile only states the differences, if you modify the original built-in profile, then there won't be any differences anymore. If you're worried about changing something other than layer height, then it still wouldn't make a difference because once they open a newer version of cura2, it will bring the new profile with it, and cura2 will only think to modify the layer_height as it doesn't store the entire profile as a 'custom profile', instead, it only stores the modifications to the current profile.
Also, if the user tries to change the material, Cura2 will pop a notice saying that he has modifications and whether he wants to keep those custom changes to the new material/profile he's switching to, if they say no, then it will reset any local modifications they have.

@kakaroto

What if we update the built in profile in the future but keep the same name? This is not an issue for our printer vendor program, but what about customers in the future?

For example:

Example_Profile
A=1
B=2
C=3

the .curaprofile change a customer spent time making states:

[metadata]
Example_Profile

[values]
C=12

This would change the profile used to:

Example_Profile
A=1
B=2
C=12

Now we rebuild our Cura engine (at some point soon, or 2 years down the road) and include a change so Example_Profile is equal to:

Example_Profile
A=9
B=7
C=3

A customer downloads our new program, with the updated built in profile and loads in their custom made .curaprofile. This updates our built in profile to:

A=9
B=7
C=12

This profile will operate differently than what the customer expects of:

A=1
B=2
C=12

If we could export all settings, this would mean it does not matter what changes we make to the built in tomorrow or two years down the road. (Sorry if I am missing something hear, but I see this as a customer issue we may be able to prevent from ever happening.)

@karrad, you make a good point, and I didn't get it until now (I just wrote a long comment to explain why it's not an issue, before realizing you're total right).
However, the use case you present is a non-issue in the context of this task, because it's a different sort of issue, it's a internal cura profiles issue, rather than an export issue.
As I understand it, in order to export that .curaprofile, you have to select the "Create profile from current settings/overrides" in the profiles manager and export that new profile, right ?
This new profile would appear under "Custom profiles" in the profile manager window, while our own profiles are appearing under "Protected profiles". Our 'lulzbot-certified' profiles are set as "Protected profiles" which also means that the user can't select the "Update current profile with settings/overrides", so they can't update/change the cura profiles which could cause issues when we decide to update those profiles.

This task is about the export of profiles out of the Cura repository (as I understand it), which is already done so you should be able to change the profiles easily. The issue you mentioned above is an important one though and I've just tested that scenario and it is indeed a pretty big issue I think.

I've created a custom profile as described above, then I changed the base profile in the cura source, and the 'custom profile' was also modified. That should not happen because if the user creates a custom profile, that one should become immutable (other than by the user himself) and I will create a new task for this to get fixed (I think I'll also create a task upstream to see how they react to the behavior change request).
I think that this might also solve the issue of having a full profile exported, because if cura would store the entire profile for a 'custom profile' (to avoid the above-mentioned bug) instead of just the diff, then using the 'export' button on a custom profile should export the entire profile to the file.

@kakaroto Awesome, that sounds great! Whatever way you find to fix this, we will be sure to get the process clearly communicated.

Thanks again!

jebba claimed this task.Feb 28 2017, 9:55 AM
jebba added a subscriber: cj.

I'm not so sure we want to do a whole new profile import/export system for this one use case. We inherited this way from upstream.

Steven closed this task as Wontfix.Oct 19 2017, 2:20 PM