ahoeben

Or, in the case of an STL file, a file format thing. STLs don't support more than a single body, so even when separated, all parts are defined as a single body.

You could use the Measure Tool from the Marketplace. Or you could calculate the full size - 2 * the size needed for the brim/skirt. The size of the brim/skirt is determined by the print settings (see the "Adhesion" category).

I really don't know. I had a longer response here, but having looked into it a bit more, what I said was incorrect so I removed it.

Ooh, shiny! I did not know about that.

Creality must be thinking all their printers are the same then... (I don't think Creality submitted any of the printers in the list)

You could use a "smart" power plug, ie the type you control with an app.

The REST API you found is for “local” networked printing. There’s also a cloud API, but I don’t know if that is also published. AFAIK, the local networking functionality is no longer getting much attention, but it still works.

Please save and share a project, not the gcode file. File -> Save project... With a project we get both the model and your current configuration and settings.

Because originally, Cura did not have the notion of saving a project. The workflow for which Cura is architected is "load one or more models, save gcode". The concept of a "project" was bolted on later. Personally, I think the "Save..." vs "Save as..." problem itself is fairly trivial (what's a couple of extra mouseclicks), but you do mention a couple of things that deserve fixing: * Cura offering to reload the project (or model) if it overwrites it itself. * No lost changes warning when exiting Cura.

Sorry, I forgot to answer this. They should be, but it is always possible a bug was introduced in Cura 5. This is correct. There is a number of variables in addition to what is available from the fdmprinter.def.json file. These are "application defined", hence why they are listed in that section on top of the "easily readable" document. Edit: I just tested all the "Application-defined patterns", and they all work as intended for me in Cura 5. How are you using these patterns?

It won't. Without a project file (File -> Save project...) it is hard to be sure, but there are generally two possible causes for this: Either your model has issues and needs to be repaired, or your settings are telling Cura to do this. One setting that can cause this is the "remove all holes" setting. If you load the same model into 3D Builder, does it say that "One or more models are invalidly defined" and offer to fix it?

With the release of the Cura 5.0 beta, a lot has changed in the core of Cura. So much so, that in order to be compatible with Cura 5.0, all plugin need to be updated and resubmitted to the Marketplace. @thopiekar, the author of the Inventor plugin for Cura may not have had the time to make the necessary changes.

Challenge accepted. I think I would personally go the route of injecting the icon in the _icons dictionary of the theme instance. The following code is untested. from UM.Application import Application theme = Application.getInstance().getTheme() detail_level = "default" icon_name = "my_category" icon_path = os.path.join( os.path.dirname(os.path.abspath(__file__)), "icons", "my_category.svg" ) theme._icons[detail_level][icon_name] = QUrl.fromLocalFile(icon_path) This is also "dirty" (since it accesses a "private" variable), but I think creating and self-editing a stub theme file is dirtier. And if your plugin adds settings, it is probably already accessing "private" variables. I'll admit that your method is creative 😉

Please share a project. You create a project with File -> Save project..., not with File -> Export... A project file not only includes the model, but also all your settings.

I was home during the weekend, like many of us. Patience is a virtue, they say.

The Sidebar GUI plugin is now also available in the Marketplace, for all versions from 4.0 through 5.0. All of my official plugins are now in the Marketplace, and the prereleases for these plugins should no longer be used (but will remain available on github).

Your model is likely "non manifold". Read this article: https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/troubleshooting/missing_parts.md#non-manifold-meshes The model (also?) has an issue where the normals are not consistent. Some are pointing outwards, some are pointing inwards. Your model needs to be repaired.

It looks like you have the Settings Guide plugin installed. I think that plugin has a setting to take over the tooltips in the settings floater ("Show articles in setting tooltips"). You may want to turn off that setting if these extended tooltips bother you.

It looks like your model is "non-manifold", which confuses Cura.

No, that is not possible with the current firmware.

Hard to tell what is going wrong without seeing the code, and the cura logs.

Effectively, UM.Application.getInstance() and Cura.CuraApplication.getInstance() point to the same object, so in use they are equivalent. Technically, Cura.CuraApplication inherits from UM.Application. Cura.CuraApplication has additional properties that UM.Application does not have. For example, UM.Application has no method getExtruderManager(). However, because the object is actually instantiated as a Cura.CuraApplication, Python does not complain at runtime. It is more "correct" to use Cura.CuraApplication if you want to access getExtruderManager(). and a decent IDE will tell you so.

Then you actually miss-copy-pasted your current solution; it should be as follows: extruder_stack = self._application.getExtruderManager().getActiveExtruderStacks()[0] My original version works, if you import Cura.CuraApplication. You probably have imported UM.Application in your code. I know how Z-Offset plugin works; I wrote it.

Depends on what you have imported and how you have defined self._application

The retraction amount can be different for each extruder. Even if you have only one extruder, you need to get the value from the extruder stack, not the global stack. For example, to get the value from the first extruder, use: extruder_stack = CuraApplication.getInstance().getExtruderManager().getActiveExtruderStacks()[0] if not extruder_stack: return retraction = extruder_stack.getProperty("retraction_amount", "value")