ahoeben

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.

Depends on your definition of a bug. The default behavior is working correctly (inheriting the normal printing temperature if no specific temperature is specified), but there is also a problematic second mechanism that is poorly documented as a "good thing to do", when in fact it isn't.

What happens is that Cura just blindly fills in what the "Printing Temperature Initial Layer" is set to, which apparently is 0 in your case. The lemma "no special treatment" unfortunately only applies to how CuraEngine treats the value. In a way, because you reference {material_print_temperature_layer_0} in the start gcode, you are forcing the special treatment of layer 0. The default behavior of the "Printing Temperature Initial Layer" is to default to the same value as the "Printing Temperature" setting: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json#L2313 I personally dislike the use of an arbitrary value for special cases. Why does 0 mean not to use the value? What if I want the first layer to print at a temperature of 0 degrees celsius for my (hypothetical) ice printer? So my advice is never use the 0-for-no-special-casing, and instead use the setting inheritance that Cura uses (where "Printing Temperature Initial Layer" inherits from "Printing Temperature" unless the user enters a specific value in "Printing Temperature Initial Layer").

You don't have to print to see the difference. Check out the preview. It is modular and editable. You don't actually need to dig into the .exe file, but you would have to edit Python files in the Program Files/Ultimaker Cura 4.x folder, and that is a slippery slope; You would have to make those edits over and over again when you install newer versions of Cura. Writing a "profile" system for Per Model Settings (ie: adding the ability to add sets of setting values to select from a list) has been on the back of my head for the past 6-ish years, but the problem is that the back of my head is a very busy place.

There isn't really a way to do this. The "pre-selected" settings are fairly hardcoded into Cura. Those default settings, which only appear when you select the "infill mesh only" option, make that option behave more like you would expect them. If you remove them, you get extra walls at the edges where the mesh intersects the main mesh. With these settings, you really only affect the infill.

Those are called "seams". Here's an insightful article on them, from the Settings Guide plugin (by @ghostkeeper) : https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/troubleshooting/seam.md

You are not being very specific about what you mean by "got stuck on the spool", so I can only guess the filament somehow got tangled (ie: the filament on the spool somehow got wound under the previous winding, instead of over). This can happen if you are not careful about rewinding the spool when you change materials. When the printer fully retracts the material from the bowden tube, you can end up with a "jumble" of filament behind the printer. If you just pull that tight, you can create a "knot" in the spool. That knot can sometimes move along with the unwinding of the spool as you print, but eventually it will get tight and cause a failure to pull material into the printer. Allways keep your spools of filament tought but putting the end of the filament in one of the holes along the brim of the spool, and always carefully rewind the spool after removing it from the printer.

If you do, please be as specific as possible, and don't heap multiple problems into one issue. "Reproduction steps" are especially important; these are the things you do that lead to a certain (problematic) effect. This way the developers can "follow along" and reproduce your steps to see what is going on. Often problems don't reproduce unless a specific order of steps is followed. An issue that just says "it doesn't work" cannot be remedied (because it likely works for the developers, otherwise it would not have been released), and "printing useless things" is just too vague to know for developers what is going on.

AFAIK, the printer adds its own M104 command before it executes your gcode, so any M104 commands you add should work, even with "Ultimaker 2" gcode flavor. But to be honest, I've always just set the gcode flavor to "Marlin" (since that also allows printing over USB through OctoPrint, which for me is the better workflow).

The current view on this issue is that it is an interplay between the drivers of your motherboard and the CPU. There's a very long issue at github with many suggestions but not a single cure-all solution: https://github.com/Ultimaker/Cura/issues/5265#issuecomment-460158267

One of the problematic assumptions the Ultimaker 2 was based upon is that all PLA prints the same, and the only difference between PLA and ABS is the temperature. The benefit was that you could slice once, and then print with whatever material you happen to have loaded on your printer. It was later realised that this does not really work, because you also need different speeds, different buildplate adhesion and different supports etc. No, it only means that temperatures are fully controlled by Cura and specified in the gcode, instead of the printer inserting the temperatures on the fly. You don't have to change a thing on your printer, but your printer may tell you that the gcode file you are printing "overrides" whatever temperatures it thinks you want to use (which is exactly what you want). That might work. Or not. I am not 100% sure. It may work when you create custom materials.