ahoeben

Sounds like something you should add to your end gcode snippet (Preferences -> Printers-> Machine Settings)

Having said that, neither TweakAtZ nor ChangeAtZ can change infill parameters. Instead, use an additional mesh to modify the infill settings using per model settings.

Yes it is, see Extensions -> Pos processing -> Modify G-code Ok, it is named "ChangeAtZ" now, but it has the same functionality that "TweakAtZ" had.

Yes, it works for me that way. Can you post a screenshot like I did, and a link to a saved gcode file?

My bad, try it without ticking the "use regular expressions" box

It looks like this should work, but I have not tested it myself. Have you tried it, and inspected the resulting gcode?

If you specify 100% infill, Cura doesn't really add infill but makes everything a shell. Try 99% infill, and then "Infill layer thickness" will work.

Almost. Don't put a ";" in front of each line. This will make the firmware ignore the line as a comment. Update: It is also smart to put a final "\n;LAYER:" at the end, so you put that text that you are finding back in.

As luck would have it, some of us speak the Klingon dialect that Cura.log is written in. Can you upload it somewhere (eg pastebin.com) and post a link here?

How did you add your printer to Cura? As a "Custom FDM Printer", or did you use a .def.json file that you downloaded somewhere? It is entirely possible that a third party .def.json file sets that Enable Nozzle Temperature setting. I find that italics is a good way to guide emphasis, without shouting. Using bold text would be shouting again.

Try "Marlin" again. "Ultimaker 2" is the only flavor that sets Enable Nozzle Temperature Control to false, which removes all nozzle temperatures from the sidebar. The Enable Nozzle Temperature Control setting is not directly accessible (and has never been, in any version). If all else fails, you could install the Printer Settings plugin from the Toolbox. This makes the Enable Nozzle Temperature Control setting to the sidebar along with a whole host of other settings. I don't really recommend you do that though. First just set the gcode flavor to Marlin; Ultimaker 2 flavor is really only used for Ultimaker 2(+) printers. Writing in all-caps is seen as shouting, shouting is seen as aggression. Over-explaining such things is sometimes seen as being pedantic, so I'll stop doing that now ?

* Tick the "use regular expressions" box (so you can use "\n" for a new line) * Search ";LAYER:" * Replace ";whatever gcode you want goes here\n;LAYER:" Because you only have a single line to enter the replace code, use "\n" instead of a return

You can go to Extensions -> Post processing -> Modify G-code, and add the "Change at Z" script once or more times. This will give you some control over temperature at different heights (layers) of your print. However, your issue seems to be that you cannot set temperatures in the sidebar. I *think* that you inadvertently set your gcode flavor to "Ultimaker 2" in Machine Settings. Go to the Printers pane of the preferences, and press the Machine Settings button. Locate the dropdown for gcode flavor, and set it back to Marlin. All of this is not influenced by a version of Cura, but if you still want to try older versions of Cura they are available here: https://ultimaker.com/en/products/ultimaker-cura-software/list Note that you are coming across somewhat aggressively. That is not necessary.

Based on activity on github, I can predict there will be a beta-release of Cura 3.5 fairly soon, probably even as soon as coming week.

You can use the Search & Replace postprocessing script as outlined above.

Python does not have a switch-case construct, but it does have if/elif/else statements.

I’ve seen someone working on this on github. Don’t know if it was ready in time to be included in Cura 3.5

Not even on the "Printers" pane of the preferences? In that case, I need to see your logs. Go to Help->Show configuration folder. Locate the cura.log file, and copy/paste it into pastebin.com and post a link to it here.

Basically the “value” is what is shown and overridden in the frontend. If there’s no “value” in the definition or in the profile, the “default_value” is shown to the user. If “value” is a formula/function, it is inspected to see what other settings it depends on, so if those settings change value the function gets reevaluated. If a setting has an (evaluated) “value”, be it set in the definition, by a profile, or edited in the sidebar, then that value gets sent to CuraEngine as a literal (ie: evaluated).

https://github.com/ultimaker/cura/issues Note that in this case, even after 1000 layers, you are still talking about a discrepancy of half a millimeter. Even “splitting hairs” is many times more than the “bug” you are talking about. I don’t think it will get much attention.

From the top of my head, see ~/Library/Application Support/Cura/3.4/cura.log

CuraEngine works in whole microns internally. A micron is a 1000th of a mm. Making CuraEngine more precise than the micron level is going to take a LOT of refactoring and will likely decrease its performance significantly and/or cause rounding issues elsewhere.

Correct. The "value" property in .def.json files is always a string which can be interpreted by Python, and as such it can be a formula or any legal Python statement/structure. The frontend is written in Python, the backend (CuraEngine) is written in C++. CuraEngine does not contain a Python interpreter, and hence it can not interpret the "value" property. The "default_value" is always a literal.

Having said what I said above, you could try going into the Custom settings, and find the "Union Overlapping Volumes" setting (use the Search!), and turn it off. But it is much better to make proper models.

You don't. A proper hollow model for 3d printing has walls that have a thickness, ie: inner and outer walls. If you wanted to print that AUDI-logo-like model, you would create 3 tubes with inner and outer walls (and a top and bottom), and then properly union them. Otherwise you will have a model that confuses any slicer.