speed_z_hop seems to be ignored in printer definition in 5.1.0

[bellzw 0]

So, my BIBO printer definition gets defaults from fdmprinter.def.json.  In that file, speed_z_hop is set by

                "speed_z_hop":
                {
                    "label": "Z Hop Speed",
                    "description": "The speed at which the vertical Z movement is made for Z Hops. This is typically lower than the print speed since the build plate or machine's gantry is harder to move.",
                    "unit": "mm/s",
                    "type": "float",
                    "default_value": 10,
                    "minimum_value": "0",
                    "maximum_value": "machine_max_feedrate_z",
                    "settable_per_mesh": false,
                    "settable_per_extruder": true
                },

In fdmprinter.def.json, machine_max_feedrate_z is set to the speed of light.  In my definition, I have

        "machine_max_feedrate_z": { "default_value": 2 },
        "speed_z_hop": {"default value": 2},

in the overrides.  However, when I add my printer to Cura 5.1.0, the value I see is 10, and, of course, this generates a slicing error until I change the value to 2 manually.  Is this a bug that needs to be reported?

Edited February 17 by bellzw

[Slashee_the_Cow 303]

 

In my definition, I have

        "machine_max_feedrate_z": { "default_value": 2 },
        "speed_z_hop": {"default<needs to be underscore instead of space>value": 2},

[bellzw 0]

@Slashee_the_Cow Absolutely correct; that fixes it.  Dumb typo on my part!  Thanks for your help.

 

But, in my definition, I have

        "machine_max_feedrate_z": { "default_value": 2 },

and without the speed_z_hop line in my definition, Cura puts 10 for speed_z_hop and seems to disregard the "maximum_value" setting.  Perhaps fdmprinter's default value should be machine_max_feedrate_z?  I guess Cura doesn't check a value against the max or min values unless a user types in a number.

 

I find that if I put

"speed_z_hop": {"default_value": machine_max_feedrate_z},

in my definition, z hop speed is set correctly, and this lets the default value track my printer's actual z feed rate.

 

[Slashee_the_Cow 303]

fdmprinter.def.json is supposed to just be a template that you override the majority of settings of, but your idea sounds pretty sensible. Here's the feature request form.

[bellzw 0]

@Slashee_the_Cow  Thanks for you continuing help.  Yes, I have a fair number of overrides in my definition.  Overriding speed_z_hop lets me avoid what was described in issue #13067.

 

I did manage to confuse myself with setting speed_z_hop: apparently, it causes problems if the "default_value" is not a an integer constant.  It really needed to be "default_value": 2 and not what I wrote above.  Cura tells me that my printer profile is corrupt when I have the text machine_max_feedrate_z or "machine_max_feedrate_z" in the json.

 

Do you know if there is a document describing valid syntax in the json files?  For example, I am pretty sure there is no way to include a comment, but I don't know that for a fact, but blank lines seem to be OK.   I am interested to find out what is legal to put as a value.  I can tell where strings and booleans are expected, but I wonder if a symbol, like machine_max_feedrate_z, is ever permitted when an int or float or double is expected.   Also when should value be set rather than default_value? Do you know if there a document describing the meanings/purposes of the parameters I find in the metadata and ahead of the metadata in the printer definition and extruder json files?  Things like "setting_version" which are not in the settings and replacement patterns document by fieldofview.

[Slashee_the_Cow 303]

3 hours ago, bellzw said:

Do you know if there is a document describing valid syntax in the json files?  For example, I am pretty sure there is no way to include a comment, but I don't know that for a fact, but blank lines seem to be OK.   I am interested to find out what is legal to put as a value.  I can tell where strings and booleans are expected, but I wonder if a symbol, like machine_max_feedrate_z, is ever permitted when an int or float or double is expected.   Also when should value be set rather than default_value? Do you know if there a document describing the meanings/purposes of the parameters I find in the metadata and ahead of the metadata in the printer definition and extruder json files?  Things like "setting_version" which are not in the settings and replacement patterns document by fieldofview.

Cura's JSON parser is pickier than a reference JSON parser should be, which doesn't help.

• Comments aren't valid in the JSON specification
• Try wrapping machine_max_feedrate_z in quotes like so:

  "speed_z_hop": {"default_value": "machine_max_feedrate_z"}

  to see if that will make it parse it as a Python statement. Usually Python statements to get numbers in definitions or startup/end gcode are written as conditionals, something like this one is entirely moot but just in case for some reason it expects a conditional or mathematical operation instead of just the variable (which is a valid Python statement itself)

  "speed_z_hop": {"default_value": "machine_max_feedrate_z if True else machine_max_feedrate_z"}

• I don't know why some things use "default_value" and some use "value" and I'm happy to let @ahoeben jump in and explain why (I'm curious too). I'm not sure if they're interchangeable so you could try switching it to "value" to see if it makes a difference.

• I think the metadata is documented somewhere in the Cura GitHub, but I don't know where. I don't bother spending time question things like "setting_version" when I know setting it to the right thing makes it work and doesn't actually change anything in the file I've created.

• FWIW, Python doesn't have doubles, just int, float and complex for numeric types. And complex deals with imaginary parts of numbers. I probably skipped out of school too early to learn what that actually means.

Edited February 19 by Slashee_the_Cow

[bellzw 0]

@Slashee_the_Cow: Tried the " " and got a crash on the next restart; see the attached image.  While Cura was open, I removed the printer, changed the speed_z_hop line in my definition, copied the definition to the resources/definitions folder, and added the printer.  Cura 5.1.0 was happy to add it without errors.  The crash occurred when I reopened Cura after closing it.  It seems to be unhappy about converting the string to a float.  Changing the default_value back to 2 restored Cura to normal operation, without having to remove the printer and add it back again.  I haven't tried putting your quoted Python statement in for the value; I'll leave that for Monday.

 

I'm interested in "setting_version" only if I can use it as a method of printer/extruder definition version identification.  I once tried changing "version" to something other than 2 and Cura didn't like it at all, so I surmised that that's a reference to the format of the printer definition file rather than a sequence number identifying the contents.  I figured out quickly some years ago that the "manufacturer" parameter is what tells Cura to group my definition with other BIBO definitions under    > BIBO when I go to add a printer.  But I don't know the significance of has_materials or has_variants being true or false.  After peeking at some other printer definitions, I see that there are many more of these parameters than I see in fdmprinter, but I have no idea what they do or if I can use any of them for my printer.

[Slashee_the_Cow 303]

Okay, important bit first:

The good news is that it is evaluating the line as Python - it's just that the variable name itself is just a string literal.

I tried with mine (which I never bothered to set speed_z_hop anyway) and this works fine:

"speed_z_hop": { "value": "int(machine_max_feedrate_z)/2"}

The division is in there just to test it. And it works! That sets it to half my machine_max_feedrate_z! (And yes, I tested it without that and it went to the full feed rate. The important part is that you're casting it to an int.)

 

Worth noting is that it only seems to work with "value" instead of "default_value". I tried changing "value" to "default_value" and it ignored that entirely and inherited from the definition it's based on.

 

1 hour ago, bellzw said:

But I don't know the significance of has_materials or has_variants being true or false.

"has_variants" refers to if there are definitions with some slight amount of information changed. In my case it's True, there's a variant for each different size of nozzle available. It's what triggers this in the dropdown when you click on the material:

Just to confuse you, the variants aren't JSON files, they're in a more traditional format which I don't know if it has a name or not:

[general]
definition = creality_ender3v3se_slashee
name = 0.4mm Nozzle
version = 4

[metadata]
hardware_type = nozzle
setting_version = 22
type = variant

[values]
machine_nozzle_size = 0.4

And I honestly have no idea what's up with the "version = 4" and "setting_version = 22". But the variants are for having little things you can change about a printer without having to make a whole new definition.

"has_materials" I'm assuming has something to do with printers which either track their own material or can only select from certain materials. Here's a snippet of the definition file for an Ultimaker 2+:

"exclude_materials": [
            "generic_hips",
            "generic_petg",
            "generic_bam",
            "ultimaker_bam",
            "generic_pva",
            "ultimaker_pva",
            "generic_tough_pla",
            "ultimaker_tough_pla_black",
            "ultimaker_tough_pla_green",
            "ultimaker_tough_pla_red",
            "ultimaker_tough_pla_white",
            "ultimaker_tough_pla_blue",
            "ultimaker_tough_pla_gray",
            "ultimaker_tough_pla_yellow",
            "generic_cffcpe",
            "generic_cffpa",
            "generic_gffcpe",
            "generic_gffpa",
            "generic_petcf",
            "structur3d_dap100silicone",
            "ultimaker_petg_red",
            "ultimaker_petg_blue",
            "ultimaker_petg_grey",
            "ultimaker_petg_black",
            "ultimaker_petg_green",
            "ultimaker_petg_white",
            "ultimaker_petg_orange",
            "ultimaker_petg_silver",
            "ultimaker_petg_yellow",
            "ultimaker_petg_transparent",
            "ultimaker_petg_red_translucent",
            "ultimaker_petg_blue_translucent",
            "ultimaker_petg_green_translucent",
            "ultimaker_petg_yellow_fluorescent",
            "ultimaker_petcf_black",
            "ultimaker_petcf_blue",
            "ultimaker_petcf_gray"
        ],
        "has_materials": true,

I don't know if "exclude_materials" means you can't manually pick them in Cura and it's up to the printer to provide that or what. But all of those materials have files in the resources/materials folder. And just to keep you on your toes, they're in XML!

Edited February 19 by Slashee_the_Cow

[ahoeben 1,955]

6 hours ago, Slashee_the_Cow said:

I don't know why some things use "default_value" and some use "value" and I'm happy to let @ahoeben jump in and explain why (I'm curious too). I'm not sure if they're interchangeable so you could try switching it to "value" to see if it makes a difference.

 

A "value" is always a string and needs to be interpreted ("calculated") by a Python interpreter to result in an actual value that can be used by CuraEngine. The nummber 1.0 should be passed as "1.0" (or - if you wish - "2 - 1"), the string "G0 E1.0" most be passed as "'G0 E1.0'" (note the " and ' quotes), and values can contain both the names of other settings and Python functions. CuraEngine can not read the "value" directly; Cura calculates the value and then passes them to CuraEngine.

 

Every setting requires a "default_value", which is a literal value. A number is a number, a string is a string, and there is no way to do math or reference another setting in default_values. CuraEngine uses the default_value for a setting when it is not passed a value for that setting by Cura.

[bellzw 0]

This is all very helpful and explains the behavior I observed.  I appreciate the effort put into answering my question.

 

@ahoeben Can you tell me if there is a document describing the parameters other than those in machine settings of fdmprinter, and if there is a document, how to get to it?  I would like to have some way of indicating a version for my printer definitions and the date. 

[ahoeben 1,955]

4 hours ago, bellzw said:

Can you tell me if there is a document describing the parameters other than those in machine settings of fdmprinter, and if there is a document, how to get to it?

I am not aware of any document like that.

 

4 hours ago, bellzw said:

I would like to have some way of indicating a version for my printer definitions and the date. 

I think you can add any metadata you want, just make sure it is valid JSON and that the keys you use don't conflict with existing keys (eg by adding your own prefix).

 

{

  {"metadata": {

    "bellzw_version": "0.1.0",

    "bellzw_data": "2024-02-22",

    ....

 

[bellzw 0]

OK, but how do I know what are the existing keys?  Are they specific to the printer?  That is, in fdmprinter's metadata, am I seeing all the keys something inheriting from fdmprinter would need to supply to Cura?  Other printers have more keys, not in common with fdmprinter.  What I'm trying to find out is how to learn what effect these have on Cura, so that I can know if further improvements to my printer definition can be made or are needed.

 

As an example, the Anycubic Chiron definition has a "platform" file in the resources\meshes forlder, and "platform_texture" set to a file name in the resources\images folder.  These parameters are not in fdmprinter.  When I add the Chiron printer, I find the image appears under the platform and behind it.  I've looked at the platform file and see that it is is a representation of the bed.  I suppose I can create an obj or 3mf (are other 3D files allowed?) for my printer, but how do I know what orientation to put the platform (they seem to be in the X-Z plane rather than X-Y), what minimum detail is necessary (a plate the size of the print bed?), and where Cura will put the image, other than by trial and error.

 

More important, perhaps, is the has_variant as described above.  Poking around the resources folder, I found the variants subfolder and saw the files there.  Are the [general], [metadata], and [values] the only sections?  I've looked at a few of the .inst.cfg files, and they all have version =4 in [general], setting_version = 20, type =variant, and hardware_type = nozzle in [metadata], and then what are probably overrides in the [values] section.  Are there other metadata variables than hardware_type?  I assume type=variant tells Cura that the .inst.cfg file is a variant of the definition specified in the [general] section (although that would seem redundant since the file is in the resources\variants folder). 

 

Yes, I could probably figure it out by trial and error, but that is not a very efficient use of my time.  Can you or someone not point me to the relevant part(s) of Github?

[bellzw 0]

On 2/22/2024 at 2:45 AM, ahoeben said:

I am not aware of any document like that.

 

I think you can add any metadata you want, just make sure it is valid JSON and that the keys you use don't conflict with existing keys (eg by adding your own prefix).

 

{

  {"metadata": {

    "bellzw_version": "0.1.0",

    "bellzw_data": "2024-02-22",

    ....

 

OK, but how do I know what are the existing keys?  Are they specific to the printer?  That is, in fdmprinter's metadata, am I seeing all the keys something inheriting from fdmprinter would need to supply to Cura?  Other printers have more keys, not in common with fdmprinter.  What I'm trying to find out is how to learn what effect these have on Cura, so that I can know if further improvements to my printer definition can be made or are needed.

 

As an example, the Anycubic Chiron definition has a "platform" file in the resources\meshes forlder, and "platform_texture" set to a file name in the resources\images folder.  These parameters are not in fdmprinter.  When I add the Chiron printer, I find the image appears under the platform and behind it.  I've looked at the platform file and see that it is is a representation of the bed.  I suppose I can create an obj or 3mf (are other 3D files allowed?) for my printer, but how do I know what orientation to put the platform (they seem to be in the X-Z plane rather than X-Y), what minimum detail is necessary (a plate the size of the print bed?), and where Cura will put the image, other than by trial and error.

 

More important, perhaps, is the has_variant as described above.  Poking around the resources folder, I found the variants subfolder and saw the files there.  Are the [general], [metadata], and [values] the only sections?  I've looked at a few of the .inst.cfg files, and they all have version =4 in [general], setting_version = 20, type =variant, and hardware_type = nozzle in [metadata], and then what are probably overrides in the [values] section.  Are there other metadata variables than hardware_type?  I assume type=variant tells Cura that the .inst.cfg file is a variant of the definition specified in the [general] section (although that would seem redundant since the file is in the resources\variants folder). 

 

Yes, I could probably figure it out by trial and error, but that is not a very efficient use of my time.  Can you or someone not point me to the relevant part(s) of Github?

[Slashee_the_Cow 303]

Double posting won't make documentation magically appear. Obviously @ahoeben will know more than me about this, but the Cura GitHub is not exactly a treasure trove of information. The closest I could find to what you want is this, and that isn't what you want. It's mostly a case of "the people who are doing it know the system because they've been doing it for ages" or "learn by examples".

 

33 minutes ago, bellzw said:

When I add the Chiron printer, I find the image appears under the platform and behind it.  I've looked at the platform file and see that it is is a representation of the bed.  I suppose I can create an obj or 3mf (are other 3D files allowed?) for my printer, but how do I know what orientation to put the platform (they seem to be in the X-Z plane rather than X-Y), what minimum detail is necessary (a plate the size of the print bed?), and where Cura will put the image, other than by trial and error.

Are other formats valid? I would assume that there's probably an example of every kind of valid format already there. It's easy enough to convert between these formats. But it doesn't take much trial and error to compare a few of the platform files with how the printers appear in Cura to figure out the common links.

 

39 minutes ago, bellzw said:

More important, perhaps, is the has_variant as described above.  Poking around the resources folder, I found the variants subfolder and saw the files there.  Are the [general], [metadata], and [values] the only sections?  I've looked at a few of the .inst.cfg files, and they all have version =4 in [general], setting_version = 20, type =variant, and hardware_type = nozzle in [metadata], and then what are probably overrides in the [values] section.  Are there other metadata variables than hardware_type?

A lot of UltiMaker printers will use print core variants that change a lot of things, not just nozzle size, but the configuration files say nozzle. I'd guess that's so they appear in this dropdown where you select the material:

45 minutes ago, bellzw said:

I assume type=variant tells Cura that the .inst.cfg file is a variant of the definition specified in the [general] section (although that would seem redundant since the file is in the resources\variants folder). 

Not redundant. Programs should never trust the user and make assumptions, like that every file in a folder is going to be a valid (or invalid, but an attempt) configuration file of the correct type.

 

Although more to the point, Cura doesn't really care where a configuration file is. I can do this:

And my printer definition still loads. Hence why each file needs to specify what kind of file it is, regardless of where in the folder structure it is.

This doesn't work for every folder, by the way:

It's not looking for any configuration files in the scripts folder... just scripts.

[ahoeben 1,955]

3 hours ago, bellzw said:

I could probably figure it out by trial and error,

Instead, figure it out by looking at the examples.

 

The only documentation is here:

https://github.com/Ultimaker/Cura/wiki/Adding-new-machine-profiles-to-Cura

 

[bellzw 0]

Yes!!!  That page and the Definition Files Explained to have what I sought. Thank you.

 

I'm running into a new problem now, probably of my own making, so I'll start a new thread.