ahoeben

Turn off “Coasting”.

* Download this file (see the "Raw" button) as theme.json: https://gist.github.com/fieldOfView/e00ca6953754e53962196a0af4b9f256 * In Cura go to "Help -> Show configuration folder" * In the "themes" folder create a new folder named "cura-nontransparent" and place the theme.json file in it * Restart Cura * Go to the General preferences and from the theme dropdown select "Ultimaker Dark non-transparent helpers" * Restart Cura again You should now have the same dark Cura theme, with the transparent helpers turned opaque.

If you can't see temp settings, your printer is likely using UltiGcode. When using UltiGcode, temperature settings are set on the printer, not in Cura. You can change the gcode flavor to Marlin in the Machine Settings for your printer, and gain full access of temperatures in Cura. The "Enable prime blob" setting has been disabled for all printers.

Nope. At least not easily. You could go the route of a custom theme. Switching themes requires a restart though, so it will not be a convenient toggle switch. Let me know if the amount of trouble you are willing to go through.

The plugin will insert the linear advance gcode at the appropriate place(s) in the gcode file for you. You don't need to insert anything in the start gcode (anymore).

Your Cura 4.1 has been modded with new/changed configuration files. Those precise configuration files don't come with Cura 4.6.1. The settings that are part of Creawesome mod have been integrated into Cura 4.6.1 (since Cura 4.2), but not the exact files themselves. Cura does not know what changes you made to your Cura 4.1, so how could it possibly make an update to Cura 4.6 without breaking things? Seriously the best thing to do is to Reset and start over. Another thing to do is to ask the person(s) who instructed you how to mod your Cura 4.1 to include those configuration files if they have a way to "unmuck" your configuration.

Signing out from your Ultimaker account in Cura until this is fixed is also a likely workaround.

Well, it is the weekend, and it was well into the weekend when this post was opened (note: I'm not team UM, I just don't have a life)

With the Startup Optimiser plugin from the marketplace, "Extensions -> Startup Optimiser -> Load only 'generic' and custom materials" should make Cura forget about all Ultimaker materials, except those that are currently selected for a printer on the next start. That is something to try easily and safely (the "Restore all configuration files" if it doesn't work is very foolproof).

Check if there is a file at C:\Users\auman\AppData\Roaming\cura\stdout.log. If so, remove it.

These decreased-line-width-walls will also be placed closer to eachother, so given a layer that is entirely composed of walls (eg the bottom layer of a print) you get the same amount of material.

You can edit the speeds in the sidebar. The "Custom FFF Printer" and the Machine Settings dialog only let you set a minimum number of settings for the printer. If you want to make a printer definition that you can distribute to others, you would need to make a set of .def.json files, and those can also contain speeds.

Any and all offset created by the plugin is reset when the printer is "homed". The printer is homed on the start of every new print. Your printer uses "stepper motors". These can rotate by very precise increments, but they do not "know", nor can they meassure, their current angle. As a result, all the printer "axes" can move by a certain distance very precisely, but when started the printer has no idea where each of the axes are. When homing, each of the axes touches on a "known" position, and from there on all relative moves are added up so the printer knows where each axis is. The plugin "plays" with the internal knowledge of where the "0" for the Z axis is. It stays in the modified state until the z axis is homed again. As an aside: bold text is normally used for emphasis. You emphasized your whole post, as if you were shouting the whole thing. Please don't; it is not necessary.

You could try these articles: https://github.com/Ghostkeeper/SettingsGuide/tree/master/resources/articles But the better way to read those is to install @ghostkeeper's Settings Guide plugin from the Marketplace.

Look in %APPDATA%\cura (which expands to ...\appdata\roaming\cura) instead of the local appdata. This folder is also neatly accessible via Help -> Show configuration folder. Cura does not use registry settings.

This is a known issue (see https://github.com/fieldOfView/Cura-OctoPrintPlugin/issues/168) that I will be fixing in the next release of the plugin. I still don't know why the key that the plugin uses becomes invalid between updates of Cura, but entering a new key has become less of a hassle. Please help me test this by installing the development snapshot. After downloading, drag it onto the Cura buildplate as if you were opening a 3d model.

In the General preferences, scroll down to the "Privacy" section and uncheck "Check for updates on start".

Yes. They'll each have their own configurations.

yes. By the way, looking at the name of your plugin, I think you want your plugin to respond to a menu item in the Extension menu, and then export the settings, right? In that case, there's not much use in listing to every time the global stack is changed, but just get the global stack when that menu item is selected. See https://github.com/Ultimaker/UraniumExampleExtensionPlugin/blob/master/ExampleExtension.py You would get the global stack when you need it, ie in the sayHello method in that example. Tip: if you say what you want to achieve instead just what is currently bugging you, I can give you better help.

You are indeed trying to access the global container stack before Cura is ready for you to access it. Don't try to retreive the global stack from the machine manager in your __init__ method, because your plugin gets initialised before the global stack is created. The best way to get the global stack is to connect a method to the globalContainerStackChanged signal of the CuraApplication instance: def __init__(self) -> None: ... self._application.globalContainerStackChanged.connect(self._onGlobalStackChanged) ... def _onGlobalStackChanged(self) -> None: self._global_stack = ...

You could turn on the "Print thin walls" setting. The cylindrical features are quite a bit thinner than the line width, so normally Cura will not put a line in their place.

The non-manifold detection looks if any pixels are drawn with that packing paper pattern. This depends on camera-angle, so it also depends on object placement, especially for small defects. The MeshTools plugin checks the actual geometry instead (ie if all edges of all faces of the model are connected to other faces of the model), and is therefore more accurate. PS: @fieldofview is not active on the community forum, but I am.

Sure, in many cases the speedup can be minimal (though 2 out of 17 is still 11% faster). The speedup will be much more significant if you load Cura from a HDD instead of an SSD for example. The plugin also has other functionality: it lets you remove unneeded branded materials, and it helps you fix specific configuration corruptions. But you don’t have to use it.

Currently the best way is to save gcode and print it using Pronterface. For something more integrated into Cura, you could use OctoPrint and the OctoPrint Connection plugin.

The fact that the warning pops up during the print is because there is a specific time set after which Cura allows itself to warn you again, due to the way the model error is detected. It has nothing to do with the fact that Cura is printing the model.