ahoeben

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.

This is "by design". For the Ultimaker 2 family, you set the material on the printer, so the printer sets the temperatures. Also note the small exclamation marks in front of the checkbox. They have a tooltip. If you would rather control everything from Cura, go to the Printers pane of the preferences, click the Machine Settings, and change the G-code flavour from "Ultimaker 2" to "Marlin". Personally I think that is the better workflow.

What do you mean by "it"?

Good. That further narrows the issue down to the ZeroConf discovery of local printers. This is a third-party module, which has caused issues for some people before.

Cura should remember the last folder you used. However, if that folder does not exist anymore, it may default to the current working directory, which is the folder in Program Files. There is no easy way to change that behavior.

Then do a rough offset in the firmware (say -2.0 mm), and fine adjustment using the plugin (say -0.06 mm).

The Z Offset setting is provided by a plugin (created by me), not by Cura 4.12. From the readme of that plugin:

Ik weet de oplossing, maar die vind je waarschijnlijk niet leuk. Stop met Sketchup voor 3d prints. Sketchup laat je modellen maken die niet geschikt zijn om te printen. TinkerCAD is ook makkelijk, ook gratis, en maakt wel modellen die printbaar zijn.

You see "Print via cloud" now, because your printer is no longer found by Cura on the local network.

The text is not in the STL file. Any other application opening the STL file will also show the model without the text. Could it be that when you exported the model from FreeCAD, you just had the body selected? If so, you only exported the body. If you want the other bits included, you have to union them onto the body and - this is important - select the topmost object in the hierarchy to export the whole thing instead of just part of it.

Is the octoprint instance at solidoodle:80 the one that is showing the camera image, or the one that is not showing the camera image? Is the "Show webcam image" checkbox in the "Connect to OctoPrint" dialog checked? This is a "per printer" setting; ie you can have it checked for one printer and not checked for another. Do you use automatic discovery, or did you add the OctoPrint instance manually by its IP/hostname?

I'm very sorry, I got the linenumber incorrect. I meant line 55, like this: 53: def start(self) -> None: 54: """Start the network discovery.""" 55: #self._zero_conf_client.start() 56: for address in self._getStoredManualAddresses(): 57: self.addManualDevice(address) 58: 59: def stop(self) -> None: 60: """Stop network discovery and clean up discovered devices.""" 61: 62: self._zero_conf_client.stop() 63: for instance_name in list(self._discovered_devices): 64: self._onDiscoveredDeviceRemoved(instance_name)

Now that we've established the UM3 Networking plugin as the likely culprit, if you need that plugin we need to dig a little deeper. If you would like to experiment, open plugins/UM3NetworkPrinting/src/Network/LocalClusterOutputDeviceManager.py in a text editor and change line 62 from self._zero_conf_client.start() to #self._zero_conf_client.start() Put the # directly in front of self._zero_conf_client.start(), not at the beginning of the line. The number of spaces before #self._zero_conf... should stay the same. This should disable the zeroconf discovery of printers. Effectively this means that you have to manually add your local printer by its IP address.

There is a known issue that when your (Windows) username contains non-ascii characters ("Koolitööd" in your case). Unfortunately the only workaround that I know of at this point is to either create a new user with an ascii-only username, or go into the registry and change the TEMP path to a path that does not contain any non-ascii characters. I would not really recommend the latter, because there is a chance of breaking things.

See

The option was originally added because some Windows users with dual displays were having issues getting Cura to start once Cura was moved to the non-primary display. At the time there was a short argument that this option - though it describes what it does - doesn't describe why you would unset it and why it fixed the issue for those windows users. I am now glad I did not make the description more specific to that crash for some Windows users, since apparently it is a useful option for some MacOS users too.