Cura settings explained

[GDRPrint 3]

Thank you very much for the effort and detail in the files, they are very helpful. Will be adding some ideas for updates to your link.

Much appreciated !

[Nick51 1]

Thank you for taking the time to provide all that information on settings.

I'm struggling with the relationship between initial bottom layer, bottom layer and layer heights.

In the standard quality profile 0.2mm layer height, both the initial bottom layer height and layer height are 0.2mm.

The bottom thickness is 0.8mm and there are 4 initial bottom layers and 4 bottom layers. This looks like 8 layers total for a 0.8mm thickness which would indicate a 0.1mm initial layer height and layer height.

If I change the initial bottom layer height to 0.4mm and leave layer height at 0.2mm the bottom thickness goes up to 1.0mm and both the initial bottom layers and bottom layers increase to 5. This looks like 10 layers total which again is 0.1mm layer height for a bottom thickness of 1.0mm. 

So basically I cannot make the math work out between the respective layers heights, number of layers and bottom thickness. I'm obviously missing something (probably something obvious) but that is where I'm at. (Using Cura 4.8.0) 

 

[gr5 1,557]

If you print an STL file that looks like a table and it's upright on 4 legs then the "initial bottom layers" are those at the bottom of the legs of the table that touch the bed.  However, the "bottom layers" are those that are on the underside of the flat portion of the table.  Normally these settings are set to the same value.

 

If you go to PREVIEW mode and use the scroll bar on the right side of the display you can see what you will be getting.

 

The "initial layer height" only affects the layer touching the print bed.  No other layers. The purpose is that your print bed may be out of flat by 0.1mm or so (thickness of typical paper).  So you want a thick bottom layer.  This reasoning is probably bad for other reasons but that was the idea.

 

So if initial layer height is 0.1 and layer height is 0.1 then all the layers you see in PREVIEW are 0.1mm.  If "initial bottom layers" is 4 then you are getting a bottom skin thickness of 0.4mm.  If initial layer height is 0.2 and layer height is 0.1 then 3 layers will give you a bottom skin thickness of 0.4mm.

 

Does all that help?

[Nick51 1]

gr5,

 

Thanks for the quick response and I think I get what you are saying but I am still not seeing it in the profile. If I leave the "Layer Height" at 0.2mm and change the "Initial Layer Height" to 0.4mm in "Quality", when I go to "Shell" I see that the "Top/Bottom Thickness", "Top Thickness" and "Bottom Thickness" have increased to 1.0mm and the "Top Layers", "Bottom Layers" and "Initial Bottom Layers" have all changed from 4 to 5.

Based on your response I would have expected to see only the "Initial Bottom Layers" and perhaps "Bottom Thickness" to change since only the one layer that is in direct contact with the bed has become thicker. I would not expect to see the top thickness or top layers change.

Sorry if I am making this difficult. I would not pursue this if I wasn't genuinely confused.

 

[gr5 1,557]

I don't think there are any bugs.

 

So you can see what *really* happens in preview.

 

The GUI is written in one language (mostly python I think?) and the slicer is a separate command line program written in C++.  They are completely independent executables that talk to each other.  When you hit the "slice" button it passes some of the settings to the slicer.  Clearly it is passing the "bottom layers, initial bottom layers, and top layers" and not the "thickness" values.

 

Okay - to your example now.  You enter layer height and layer thickness and "initial layer height" is ignored because it doesn't affect top layers.  And it doesn't affect bottom layers (the underside of the table top in my example).  So top layers and bottom layers is thickness divided by layer height.  So far so good.

 

The strange part is that "initial bottom layers" is just always set to the same value as "bottom layers".  By default.  So the initial layer thickness will indeed be thicker than the other top and bottom layers.  Maybe they should have done a special calculation and noticed the "initial layer height" setting.  Perhaps they decided to keep the functionality the same as the functionality was before this feature existed.

[Nick51 1]

Thanks again gr5.

I didn't think there was an actual problem with how the slicer creates the gcode because generally they work fine if the design doesn't have any problems.

I was just trying to understand why the numbers didn't add up in the area we have been discussing. It seems to me that by definition Initial layer should always default to 1 since it is the only one that touches the build plate.

Going with your table example (very good by the way) it seems like what is called initial layers is actually a combination of both the first layer that is on the build plate and some additional calculated layers on top of that. The numbers still don't add up because using my example where Cura sets the thickness at 1.0mm and 5 layers with initial layer height of 0.4 and layer height of 0.2 then you would get 1 layer at 0.4 and 4 layers at 0.2 for a total of 1.2mm. 

I think we have gone as far as we can with this and I will have to experiment from here. Maybe draw a flat plate that is 1.0mm thick and see what really gets printed and then adjust from there.

Thank you again for all your help. I really appreciate your time and rapid response.

Neal

[gr5 1,557]

yes, like you said, if initial is .4 and rest are 0.2 then if you ask for 1mm it will do 1/0.2 and decide "bottom layers" (again not the layer touching the glass) should be 5 passes (1/0.2=5).  But the true bottom layer touching the glass will actually be 1.2mm thick.  You asked for 1mm, it did 1/0.2=5 and so decided by default to do 5 layers and so you get 1.2mm.

 

If you ask for 1.01mm it will still do 5 layers by the way and they will NOT be 1.01 but they will be 1.0 (and 1.2 for initial bottom).

 

So the bottom thickness is a *request*.  A suggested or nominal thickness.  Sometimes you get a little thicker or thinner because this isn't considered critical to be absolutely perfect since then you hit the infill layers an no one can see it and the difference in strength is small (say 1.01 requested versus 1.2 actual).

[ahoeben 1,160]

13 hours ago, gr5 said:

Clearly it is passing the "bottom layers, initial bottom layers, and top layers" and not the "thickness" values.

 

Some settings in Cura are a child of another setting; in the settings view they are "indented". As a general rule, if a setting has a child, only that child gets used by CuraEngine.

 

The values for "Line Width" and "Wall Line Width" are not actually used by CuraEngine. Instead it only looks at "Outer Wall Line Width", "Inner Wall(s) Line Width", "Top/Bottom Line Width", "Infill Line Width" and "Skirt/Brim Line Width".

 

The Line Width setting is there as a convenience to setting/affecting all the line widths in one go; by default the children of the Line Width setting use a formula based on the Line Width value (most of them just copying the Line Width value). Unless ofcourse you or the profile you use has put a non-formula value in one of the child settings. Then what you put in the Line Width will no longer affect the value of that setting.

[noalt 0]

Hello,

 

I was looking in the Cura travel settings for a mode which seems logical to exist but I can't find it.

Can someone point me in the right direction?

 

I was printing a large object that has a couple of structures in the middle that are far apart.

I think it could save a lot of time to limit travel by printing 5 layers on one structure before moving to the next.

 

I feel like this should exist, although from a software development perspective it might be a challenge. 

Does it exist?

[GregValiant 206]

The short answer is no.  This has come up before usually regarding multiple parts on the bed.  It isn't just a software issue, but a hardware issue as well - as in "something might crash".  As an example, it wouldn't work with my printer because the part cooling duct is in the way.  I agree it could (in a small number of cases) speed things up and probably reduce stringing for filaments like PETG.  It's like non-planar slicing in that it is really dependent on the shape of the print head.

FDM is just not a fast process.

[noalt 0]

2 hours ago, GregValiant said:

The short answer is no.  This has come up before usually regarding multiple parts on the bed.  It isn't just a software issue, but a hardware issue as well - as in "something might crash".  As an example, it wouldn't work with my printer because the part cooling duct is in the way.  I agree it could (in a small number of cases) speed things up and probably reduce stringing for filaments like PETG.  It's like non-planar slicing in that it is really dependent on the shape of the print head.

FDM is just not a fast process.

Ah yes.
I only know my printer, and the nozzle is sticking out for a couple of millimeters. I figured it could work for a couple of layers.
Thanks for the info!

[GDRPrint 3]

Thank you for the excellent discussion and helpful posts

[ird_001 0]

I am wanting to understand the process of how the user modified settings are passed on from Cura UI to the CuraEngine. My understanding so far is that the calculated child settings for different category (only includes the user modified settings), get stored in json file, which is passed on to CuraEngine after -j via command line('/usr/src/cura/CuraEngine','slice','-v','-j', json_file....). Is my understanding correct? 

[ahoeben 1,160]

14 hours ago, ird_001 said:

Is my understanding correct? 

It is not.

 

Cura does not use the command line to send settings to CuraEngine. CuraEngine is launched alongside Cura, and the two communicate over a bespoke protocol named "Arcus" which is based on ProtoBuf. The calculated setting values are sent one-by-one to CuraEngine, there is no intermediate json file. CuraEngine does look at the fdmprinter.def.json file for default values for each setting.

[ird_001 0]

4 hours ago, ahoeben said:

It is not.

 

Cura does not use the command line to send settings to CuraEngine. CuraEngine is launched alongside Cura, and the two communicate over a bespoke protocol named "Arcus" which is based on ProtoBuf. The calculated setting values are sent one-by-one to CuraEngine, there is no intermediate json file. CuraEngine does look at the fdmprinter.def.json file for default values for each setting.

Okay. That does make sense. For couple of months I have been trying to use a modified settings by user from UI (not Cura UI) and trying to pass it as json file to override the default settings in fdmprinter.def.json and pulling my hair out as to why some settings were modified and why some were not. 
It seems like the connection was specifically made for Cura front end. So, if I am to use something else other than Cura front end and pass those settings to CuraEngine, I might have to find other way to pass the user modified setting to CuraEngine. 

 

Thanks for clearing up my confusion.

[ahoeben 1,160]

CuraEngine still has a commandline interface. You can override the defaults specified in fdmprinter.def.json by passing them with the -s argument (eg -s layer_height=0.2 -s line_width=0.25).

[ird_001 0]

Yeah, that is an option but if user has lot of modifications, that might end up being really long and it is my understanding that it does not take file i.e, all the settings have to be listed on the command line. The approach that I am thinking right now is to create a clone fdmprinter.def.json and update all the default values of children of all categories with user defined values in the clone and pass it after -j  in the command line.