bellzw

@Slashee_the_Cow: You are indeed correct that the comma didn't belong. I appreciate your sharper eyes. Looking through my history of the definition, I realized that there used to be a "first_start_actions" : ["MachineSettingsAction"] after the extruder trains (with no comma at the end of that line). I removed it during my search for the differences between a definition that displayed the platform and my BIBO definition and neglected to remove the comma. It's always something. An online JSON syntax checker detected the error, but Cura 5.1.0 didn't issue any warnings via the user interface. I corrected the syntax, and replaced the file in \definitions, but the platform did not appear until I closed Cura and restarted. Now it seems to be working. The first_start_actions line was in the BIBO definition that ships with Cura. Can you tell me what MachineSettingsAction is/does? It's not in my definition now, and Cura seems to be slicing models correctly. Do you know anything about the platform_texture png? Size, black background, white background, etc? Most are png, but a couple are jpg. How does Cura know where to put the image and how to size it? I did notice that some of the files in \meshes are in the XZ plane, while others are in the XY plane. At least one of them, Anycubic Chiron, has a plane surface in the XY plane and a surface at 45 deg w.r.t. the XY plane and Cura puts the Anycubic logo on the top of the tilted surface and the bottom of the build plate. However, the Hellbot Hidra Plus, has its image seemingly on the top surface.

So, I include "platform": "BIBO_platform.obj", in my definition.json, put the definition in \resources\definitions, put the extruder definitions in \resources\extruders, put the obj file in \resources\meshes, and add the printer, but do not see the platform. The obj file was made with FreeCad 0.21.1 and Windows 3D Builder is happy to display it. I tried adding printers that had obj and 3mf files in \meshes and saw the platforms. Thinking there might be a problem with the obj file, I renamed it to FelixPro2_platform.obj, and added Felix Pro 2 dual, to see if the same occurred with a different printer definition, and much to my surprise, it displayed under the print volume. The displacement is because of a platform_offset in the Felix Pro 2 Dual definition that I didn't remove. Any ideas regarding why it doesn't display under my BIBO print volume? After several hours looking for differences between my definition and others, I'm stumped. My definition and the obj are attached. Any help will be appreciated. BIBO_platform.zip

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.

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?

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?

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.

@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 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 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.

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?

That's what I expected was the answer, since I've not seen any examples in which the replacement patterns were part of expressions. I was aware the feature was in PrusaSlicer. A pity it's not part of Cura.

I mean constructions like my_macro_name = if ({material_standby_temperature, 0} > {material_standby_temperature, 1}, 1, 0) ; return 0 if 0 T0's standby temp < standby temp of T1, else return 1 M109 T{my_macro_name} S{material_standby_temperature, my_macro_name} ; wait for the coolest tool to reach standby temperature so I can get, for example, for my dual extruder printer, the extruder number of the one that will be at the lower standby temperature. I've used if ( condition, true clause, false clause) as a shorthand and example; I know there are other ways to express the concept. If Cura does support these constructs, can someone point me to some documentation? I'm aware of the list of macros at http://files.fieldofview.com/cura/Replacement_Patterns.html.

I have been studying the behavior of the Translucency (that's the word in my English installation of Cura 4.8.0) for making lithophanes, my ultimate goal. The error related to the model not being manifold is, I think, unrelated to the Color Model. It's a statement about holes or other irregularities that were found when model was sliced. There is an article about this at Cura support, article 360014055959-Why-am-I-getting-Your-model-is-not-manifold-popups-in-Ultimaker-Cura-. When making lithophanes, I have not had a problem printing the object, despite seeing these errors. I am a little confused by the screen shots since the importing of the jpg should have resulted in a model that was 12 mm (11+1) because Height, according to the screen tip, is height above the base. Both 10.1 and 2.6 seem wrong. However, I won't comment further on this because I may have misinterpreted the previous comments. To study how Cura 4.8.0 imports a jpg, I created an 400x300 grey-scale image with Paint having nothing but 8 square columns with shades of grey from 128 to 1, stepping down by a factor of 1/2. The columns were on a white (pixel value 255) background. I set the top and bottom layers to 0, layer height to 0.1, first layer thickness to 0.1 also. I imported with Height = 25.5, Base=0, Width=120, Depth=90 using Linear and Transparency modes and Darker is higher and Lighter is higher. I found that Linear worked correctly and gave me objects that were 25.5 mm in height, exactly what I should have gotten according to the Base and Height I set and the pixel values in the jpg. Translucency darker is higher was successful, however it is not clear that the slicing is correct. I set 1 mm transmittance = 50% and the resulting slicing had 176 layers to the top of the tallest tower, a factor of 2.2 times what should have been given the layer height was 0.1 mm. The reason I expected an 8 mm tall model was because if the light loss is 50% in 1 mm, then there needs to be 8 mm of material to attenuate 255 to 1 (2^(-8)). Cura did correctly scale the towers according to the logarithm (the steps in the image below are equal), but seems to have an error that makes it think the layer height is smaller than the user sets. This factor of 2.2 does not seem to depend on the user-supplied layer height parameter. Translucency fails when it is used in lighter is higher mode. The image below shows that all the holes either go to the bottom or stop only 1 or 2 layers from the bottom. The picture should have looked like the one above, just upside down. This means you can't make a negative lithophane.