Cura: Machine Settings, Variants, etc, unclear

[cederom]

Please make some WiKi on the configuration structure and possible options reference. Now it is unclear why and what does what. I have created a configuration for my printer, but still, some options are not taken from the configuration. I am not sure what else should I change to create valid and coherent machine profile..

[Ghostkeeper]

We have this file: https://github.com/Ultimaker/Cura/blob/master/docs/Cura_Data_Model.odg

Is that more or less what you were looking for?

[cederom]

Hey @Ghostkeeper thank you for quick answer :-) This document is nice but too general, still missing some important information in possible field names and values for a person that want to create a standalone configuration from scratch. I am this kind of person so its good to test on me. How about we create adedicated markdown reference document either in a source code or as project wiki..? :-)

[cederom]

For instance:

• some values are referenced by variables some by filenames.
• my device definition needs to contain inherits field. why? how to skip?
• my device definition contains some values that are somehow overriden by some other parameters (quality? variant? child? root?)
• etc etc

I am willing to write this kind of reference if you have enough patience and knowledge to help me out? That would greatly increase userbase for Cura :-)

[nickthetait]

@cederom, for starters take a look at https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json

I agree that there is plenty of room for improving the documentation in this area, I'm willing to proofread anything you come up with.

[sedwards2009]

We've got an internal JIRA issue or two about improving the docs and documenting the meaning of all of the different fields.

If someone wants to get started before us, feel free. Markdown format in /docs is probably the best way to go.

[fieldOfView]

It would be good if the documentation about settings is created from fdmprinter.def.json and fdmextruder.def.json programmatically, so it is easy to keep it up to date when (not "if") the file is updated again.

[Ghostkeeper]

In addition to sedwards2009's comment (which is the gist of the problem), I'll answer cederom's initial questions directly:

• All references to profiles and definitions are by "ID", which is derived from the filename. The only exception here is the references to the material profiles, because a material profile can be different per machine and variant, so a material profile is referenced with a combination of the material profile's ID and a variant ID. The settings names in inheritance functions are referenced as a variable (e.g. material_bed_temperature = =material_print_temperature / 4 if that would be something you want to do).
• All definition files are intended to inherit from fdmprinter.def.json. In FDMPrinter, all settings are defined and have default values. This way a setting can always fall back to its default.
• As shown in the .ods file in our documentation, there are lots of profiles that will override the definition's values, since the definition is all the way at the bottom. If any of those profiles specify a different value for a setting, the value of your definition will get overridden. Also note that the "value" property always overrides the "default_value" property.

[filipgoc]

I'm also interested in a place where we can start some docs-in-progress for us novice cura participants (not users; but power users/ wannabe contributors/ devs)

maybe the github wiki is a painless starting place? or some folder into which we'll start piling up markdown files so we have a better versioning?

---

@cederom i have random pieces of info on these things from trying to make printer variants work myself (work in progress, now off-loaded to a collaborator temporarily)

once I have it working (and even before it's working) I'm happy to write it up.

[cederom]

Cool, maybe we should use Wiki as scratch pad, and when document is good enough we put it into a source code repository as reference?

[cederom]

Here is my proposition that we can already work on: https://github.com/Ultimaker/Cura/wiki/Cura-Configuration-Reference-Manual

[nallath]

@filipgoc, We've been toying with the idea of a mailing list of sorts to faciliate better contribution for people who want to participate in cura development. I'm not sure if its the best way of doing it though. So if you guys feel something else is required, we will try and faciliate it.

[filipgoc]

@nallath Electing new structures always has it's downsides...

• For now I think 'issues' here actually work as a good forum - as long as the community remains responsive :-) Newcomers need to learn to navigate and search well, but it's not bad.
• If you want more engagement, one thing that would probably help would be to update README with info on how to get involved for people that 1, haven't done this 2, may not even know github yet. Even things like "issues = forum" may not be self evident.
  
  
  
  • even just to say that people are welcome and what kind of engagement you're looking for (feedback, bugs, feature requests, beta testing, profile development...)
  
  
• another thing that could help is to publicize roadmap/ time frame. (maybe I just don't know where it is?) one could even use 'milestones' for it.
• but all of these are more work over time so, ... think twice ;)

---

• One thing that does seem to be missing is a bit more deliberate attempts at preserving institutional memory - but that's only natural while Cura is moving so fast!
• In the end, I think it's unrealistic to think that suddenly devs will pour time into making documentation while all is still shifting.
• However, it'd be nice to have some place where people can add little impromptu docs/ tips/ solutions to things that have less to do with implementing new functions and fixing bugs, and more to do with being able to use the current file structures.
• (For example, for me this means setting up a custom machine with custom profiles and variants. The only printers that have it working so far are Ultimaker 2+ an Ultimaker 3. So once I have it working, I'd be nice to share. Currently, the info one needs is spread over 5 incongruous 'issues')
• MAYBE we should leave it all in issues - the trouble with Wiki is that it can seem unmovable, and it's unlikely someone will keep it updated going forward. For now though, why not see what happens with it. Let's follow the content.

ok. this got out of hand. long text. gotta go no.

[Ghostkeeper]

The wiki here is currently open for modification. Any Github user may edit it. But perhaps it would help if we get some structure going so that details may be filled in.

We have planning and road-map-ish things internal with Ultimaker (Jira to track issues and whatever our managers' flavour of the month is for more large-scale planning), as well as a wiki-like application (Confluence). There are two problems with those though:

• It may contain secret planning for Ultimaker's future commercial interests. We have no secrets for Cura development at the moment, as far as I know, but for instance the Ultimaker 3 support was going on for 10 months in secret.
• Expectation management. If we're publishing plans for future features, the marketing team will want to do all that. But I bet they'd rather not, in case we don't get it done in time.

I think we can update the readme quite painlessly to give a pointer of where to look for help in creating profiles, machines, plug-ins, new features, etc. But then we first need to decide on a place.

[filipgoc]

Update:
I came back to this after a while, I have figured it almost all out. I have it all working (variants, custom materials, custom quality profiles), just a few understanding points I'm getting cleared out (issues in the making). Then I'll write it up and we shall be merry!

[cederom]

awsome! =) i have already created a wiki templates you can just fill out :-)

[ianpaschal]

Since this hasn't been touched in more than a year, I'm closing it.