Help understanding layer_height config file options

[jlgtx 0]

I've created a custom printer config, and I need to tweak some of the settings. First thing is to constrain the available layer heights to those that are optimal for this printer. Looking at the Ultimaker 3 definition file (and chasing the "inherits") as an example, I see the layer_height configuration options (mostly in the fdmprinter.def.json file), but I don't see how to constrain them to specific numbers. For example, let's say I want to only allow layer_height in increments of 0.04. Is there a calculation for that, or do I just define a bunch of presets, or is there a "layer_height_increment" setting that I'm not seeing?

Edited November 8, 2017 by Guest

[gr5 2,225]

I haven't looked at this very carefully so I'm not knowledgeable but my impression was that the json file can contain javascript so you could use some javascript math functions such as "int()". For example:

Math.floor(x/0.04 + 0.5)*0.04

will convert any value x to the nearest multiple of .04.

You can probably put that anywhere you can put any other variable. I could be wrong but I'm pretty sure you can do stuff like this somehow.

This will *not* restrict the value but at least it will only suggest values that meet your requirements.

Having said that, the whole "it's best to use multiples of a single microstep" argument is probably wrong. It might be true of whole steps, but I doubt it's true of microsteps unless you also use the "tl-smoother" or have really good stepper drivers.

[jlgtx 0]

I assume that the stepper motors for this printer use 0.04mm increments, or something. The instructions say, "For best results, set your layer heights in 40 micron (0.040 mm) increments. For example, 0.16mm, 0.20mm, 0.24mm etc." So I'm just trying to make the Cura profile match that.

I hate to experiment with profiles, because my experience has been that a badly-written profile is a good way to completely screw up my Cura settings and have to start over. But, until the printer mfr decides to produce updated Cura profiles for their hardware, I guess that's where I am.

[ahoeben 1,986]

my impression was that the json file can contain javascript so you could use some javascript math functions such as "int()".  For example:

You got the wrong impression then.

The listed layer heights for a specific printer actually depend on the quality profiles available for that printer/material combination. See the quality profiles per printer in the resources/quality folder.

There is nothing constraining the "steps" of the value for layer height entered in the "custom" mode sidebar.

General tip for @jlgtx: the UM3 definitions and profiles are not the easiest to understand/learn from, because they use the whole set of tricks that can be used with definitions/profiles (ie: quality profiles per material, print core type and layer height, as well as some trickery to prevent some incompatible combinations for multiextrusion). Start with eg the Peopoly Moai quality profiles if you want to have a less steep learning curve (though that printer has other peculiarities, being an SLA printer).

Edited November 9, 2017 by Guest

[gr5 2,225]

my impression was that the json file can contain javascript so you could use some javascript math functions such as "int()".  For example:

You got the wrong impression then.

Well then how come when I set the shell width to various values there is clearly some kind of formula for auto calculating the wall line count? Or is wall line count not part of profiles? It looks like at a minimum one can do division (divide shell width by line width to get wall line count perhaps) in a profile. I thought I saw other examples of math happening but maybe none of those are part of the profile and they are all hard coded by cura?

[gr5 2,225]

@ahoeben - I just checked and there are these files - are these not printer configuration files? They sure seem to have javascript to control the parameters. This is from fdmprinter.def.json.

Now I'm even more sure than before that you can do this kind of thing that the poster asked for. Sort of.

                        "wall_line_count":
                       {
                           "label": "Wall Line Count",
                           "description": "The number of walls. When calculated by the wall thickness, this value is rounded to a whole number.",
                           "default_value": 2,
                           "minimum_value": "0",
                           "minimum_value_warning": "1",
                           "maximum_value_warning": "10",
                           "type": "int",
                           "value": "1 if magic_spiralize else max(1, round((wall_thickness - wall_line_width_0) / wall_line_width_x) + 1) if wall_thickness != 0 else 0",
                           "limit_to_extruder": "wall_extruder_nr",
                           "settable_per_mesh": true
                       }

[ahoeben 1,986]

Ok, I was not clear enough, and should have quoted a different part of your reply.

You can use javascript to set a value based on the value of other setting(s). You can use javascript (or an absolute value) to set a minimum and/or maximum value for a setting. You cannot use javascript to change the value of a field you just entered data into, so it is not possible to use javascript to round a value to a certain precision using code similar to the example you posted.

You can not calculate the value of the layer height setting from the value of the layer height setting.

What you can do with a carefully crafted printer definition is hide the actual layer height setting from the user, and introduce a different setting that maskerades as the layer height. Then the value of the actual layer height could be calculated from the mock-layer-height setting value.

[nallath 1,124]

It's python actually. But for the rest, Aldo is right (as usual)

[gr5 2,225]

You cannot use javascript to change the value of a field you just entered data into, so it is not possible to use javascript to round a value to a certain precision using code similar to the example you posted.

I didn't think you could. I was just saying you can at least have it default to favorable values for that printer.

What you can do with a carefully crafted printer definition is hide the actual layer height setting from the user, and introduce a different setting that masquerades as the layer height. Then the value of the actual layer height could be calculated from the mock-layer-height setting value.

That's cool!