ahoeben

What problem(s) do you have with the settings? What do you want to improve? Do you have certain parts that don't come out well? Do you want more speed? What are you looking for? There are no universal "best settings". If there were, they would probably ship with Cura.

Here's a good article to read: https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/troubleshooting/missing_parts.md

No, that is not possible with the search. But you can create custom "setting visibility sets" using the "Setting Visibility Set Creator" plugin available from the Marketplace. Using that plugin you can create a set with just those settings, and easily display just those and go back to your "normal" set (or all settings, if you are one of those people) afterwards. https://marketplace.ultimaker.com/app/cura/plugins/fieldofview/SettingVisibilityProfileCreator

No, this is not currently possible

@hobby_grade, not all slowdowns are necessarily the same slowdowns. Do you have any other plugins installed? Like for example the OctoPrint plugin or the Sidebar GUI plugin?

@BOULBA, if you have multiple displays, you could try to uncheck the option to "Restore window position on start" in the General preferences in Cura. Then restart Cura.

Also: what nozzle size have you selected? If you have a very small nozzle, you can not print at "normal" or big layer heights.

Both CuraBlender and Blender Integgration plugins seem to have trouble finding Blender. I would guess they are not yet compatible with Blender 3.0, and therefore need an update. You will have to contact the authors of both plugins for that.

I'ld rather have an answer from someone if *any* application successfully does USB printing. Printrun not working does not necessarily mean the core of printrun is at fault.

The Cura GUI log file, located at %APPDATA%\cura\<Cura version>\cura.log (Windows), or usually C:\Users\<your username>\AppData\Roaming\cura\<Cura version>\cura.log $HOME/Library/Application Support/cura/<Cura version>/cura.log (OSX) $HOME/.local/share/cura/<Cura version>/cura.log (Ubuntu/Linux) You can also reach this directory from the application menu in Help -> Show settings folder

The installer can be unzipped with most archive applications (I use 7-zip myself). Provided that the appropriate version "microsoft visual c++ runtime" has already been installed on the computer, Cura will run just fine from this unzipped installer folder.

You could print it using normal supports instead of tree supports, or try if your printer bridges the roof with the tree-supported rim.

As you have found out, you can either put your own heatup sequence in the start gcode, or CuraEngine can put it before your start gcode for you. The pattern replacement you can do in the start gcode snippet is fairly "dumb"; it literally just replaces the {}-pattern with the value of the setting. There is no logic applied whatsoever, only simple replacement. It does not "understand" gcode in any way, so it does not realise you are adding a heatup line that refers to a disabled extruder. There are no "conditional" lines. Just replacing a pattern by a value. Ofcourse the slicer itself is more intelligent than that. So if you tell it a certain extruder is disabled, it is smart enough to construct a heatup sequence that excludes that extruder. So the logic is as follows: If the user has specified a heatup sequence, just do a dumb pattern replacement on it. No further logic possible. If not, created a heatup sequence from all the settings specified by the user, taking into account the number of enabled extruders and which extruder will be used first.

It would actually be useful to know if Printrun works on your M1. If so, I might dust off my effort to integrate the core of Printrun into a plugin for Cura, replacing the existing non-maintained USB Printing functionality.

It could be that a driver is necessary. But since Ultimaker never officially supported USB printing with the Ultimaker 2(+), if Apple is not providing that driver for their new architecture then chances that you will get this to work might be slim. You could try if you can save the gcode to a file and then print it using Printrun (www.pronterface.com). Or if you want something that is nicely integrated into Cura, you could install OctoPrint (either on your Mac Mini, or on a Raspberry Pi), and print to that with the OctoPrint Connection plugin available from the Marketplace.

I think the text is just too thin; thinner than the nozzle size. But I can't be sure without a look at a project file.

AFAIK, this is not possible. Repetier and the UM3 don't speak the same language ("protocol"). They can possibly see eachother but don't know what to say to eachother.

Good thinking @tinkergnome! And here I was caught up in the fact that 100 / 35 is about equal to the filament diameter, and I could not figure out why/how that mattered 😉

On my PC, Cura defaults to the last folder I have saved to. Let's try to dig a bit deeper. Go to Help->Show configuration folder. In the folder that opens, locate the part that starts with [local_file]. For me, that part has the following entries: [local_file] last_used_type = application/vnd.ms-package.3dmanufacturing-3dmodel+xml dialog_save_path = C:/Users/Aldo/Documents/3d prints/molen lithophanes dialog_load_path = C:/Users/Aldo/Documents/3d prints/molen lithophanes Apparently I loaded from and saved to the same folder, and the last thing I wrote was an .ufp file for an Ultimaker S5 instead of a plain gcode file. What does it say for you?

Sounds to me like your enclosure would be limiting the build volume of your prints, which I think is a bad idea. What is your end gcode?

Een Ultimaker 2+ hoort niet te "kraken". Kan je het geluid beter beschrijven? Voor mij is kraken het geluid dat iets maakt als het aan het breken is. Stepper-motoren maken piep-geluiden als ze bewegen, belts kunnen als ze niet lekker op hun pulley lopen een ratel-geluid maken. Ventilatoren kunnen "ruis" maken of een zeur geluid. Voor bijna alles is wel een oplossing (soms eenvoudig, soms lastig), maar ik kan me weinig voorstellen bij "kraken".

I understand what you are saying, but it does in fact work "as intended" by replacing {mateiral_print_temperature_layer_0} by the value that you see in the sidebar: 0. In my opinion that bit of documentation to "Set at 0 to disable" should just be removed, exactly because of this confusion.

I would say it is an "inconvenience" in the printer definition. I would advise against using the "0 for no effect" values. Just keep the value unset in your profiles if you don't want to special-case the initial layer, and you can safely use the {material_print_temperature_layer_0} value. Also note that Cura adds an "f(x)" hint in front of the value. Mouse over that for an explanation; click on it to restore the automatic inheritance (replacing the "0" in your profiles).

What we could try is updating that 3rd party component to a newer version. First that would require you to undo the change you made (ie: remove the # again). Next, download and unzip this copy of the zeroconf library: https://github.com/jstasiak/python-zeroconf/archive/refs/tags/0.37.0.zip Inside that zip, there's a folder named "zeroconf", which contains among other files "asyncio.py" Replace the /Applications/Ultimaker Cura.app/Contents/Resources/lib/zeroconf with that entire folder. Make sure there are no old files mixed in. NB: I have not tested this myself. If it ends up not working, put back the original zeroconf folder or just redownload and extract the original .dmg file. Just in case I end up disappointing you at some point, please know that I am not affiliated with Ultimaker. I am just a community member, like you. Just one that happens to know a lot about Cura because 5 years ago I worked on Cura 2.3 a bit, and I have written one or two plugins.

The best way to reset Cura is to go to "Help -> Show configuration folder". Then close Cura, and remove all the files from the configuration folder that opened, but leave the empty folder in place. Then restart Cura.