ahoeben

It would be helpful if you could give some examples.

Issues that magically resolve themselves have a tendency to reoccur. If it does reoccur, please let me know.

If you have two printers configured in Cura, each connected with a different OctoPrint instance, each should store its own key. I am not sure what is going wrong. Could you DM me, so we can exchange some files without exposing your keys to the world?

Are you perhaps using Cura over a remote desktop connection? There is a known problem when starting Cura over RDP, Windows tells Cura that a new "context" for 3d rendering can not be created because there is no GPU present. If Cura had already been running prior to starting the RDP connection, Cura can in fact use the GPU. There is nothing Cura can do about this, and it does not just affect Cura either. Recently, NVidia published a patch of sorts to fix the issue, if the computer running Cura has an NVidia GPU: https://www.khronos.org/news/permalink/nvidia-provides-opengl-accelerated-remote-desktop-for-geforce-5e88fc2035e342.98417181

Ja, als we allemaal onze moerstaal gaan spreken dan heeft niemand er meer wat aan.

It would be a lot easier to implement your program as a Cura plugin, because then Cura will deal with the stack of configuration files for you.

It is more complicated than that. There is a "standard list" that defines all settings and contains default values. This is fdmprinter.def.json in resources/definitions (plus fdmextruder.def.json for a hand-ful of extruder settings). Then there is a .def.json for the printer-type (eg an Ultimaker 2+), which contains setting values specific to that printer. Additional files contain setting values on top of that for the currently selected variant, material, intent and quality. Each configured printer has a "machine_instance" file that shows what files make up this "stack", and at least 1 extruder file that does the same for each extruder. Oh, and then there are setting values in the material xml files, which can also be printer-type-specific and either apply to the extruder or to the printer globally.

Without logs, there is no way of telling what is going on. You can find the logs via Help -> Show configuration folder. The file you are looking for is cura.log

Sounds like you got things working again, which is great. For the record, it would be nice if you mention you have manually edited your printer profile, so when we try to reproduce your problem we don't have to wonder why it works just fine for us but not for you. Also thanks for pasting the logs, but it would have been more helpful to also have the Error traceback.

Don't read too much into the wording "EngineErrorThread". This is the interesting bit: Any time the CuraEngine process quits with an errorcode that does not equal 0, that means that the slicer has crashed. 3111225477 is C0000005 in hexadecimal. Update: C0000005 is normally an "ACCESS_VIOLATION", meaning CuraEngine is trying to read or write memory where it is not supposed to. So definitely a bug, related to either the model or the settings. It will be helpful to debug this if you save the model as a project via File -> Save... (NOT File -> Export). This will save the model and all your settings.

We can't tell what is going on without looking at the logs. See Help->Show configuration folder. The file you are looking for is called "cura.log".

Have you read the rest of the page @nallath linked to?

I am by no means a benchy-expert. The stringing suggests to me you are printing too hot. Try 5 degrees colder. You could also try adjusting retraction settings. There seems to be quite some ringing, which you could try solving by printing a bit slower. 100% infill has challenges of its own. If the material is not perfectly the 1.75mm it is supposed to be, 100% infill can cause overextrusion and partial clogs. If you want the model "solid", try 80% infill instead. But also try with 20% infill. Finally, don't start with "super fine". First learn stand, then learn fly. Nature rule, Daniel-san, not mine

Looks like this issue: https://github.com/Ultimaker/Cura/issues/3815 If it is, it is only a visualisation error. Cura does not display the actual gcode in layer view, but a set of specially created "layer data". The error is in the "layer data", not in the gcode.

Could you clarify what *exactly* is happening? From the logs, it looks like the model loads just fine. 2020-07-23 20:22:45,224 - INFO - [Thread-3] STLReader.STLReader.load_file [52]: Using NumPy-STL to load STL data. 2020-07-23 20:22:45,233 - DEBUG - [Thread-3] UM.Mesh.MeshData.calculateNormalsFromVertices [548]: Calculating normals took 0.0010001659393310547 seconds 2020-07-23 20:22:45,234 - DEBUG - [Thread-3] STLReader.STLReader._read [104]: Loaded a mesh with 8520 vertices 2020-07-23 20:22:59,706 - INFO - [Thread-1] STLReader.STLReader.load_file [52]: Using NumPy-STL to load STL data. 2020-07-23 20:22:59,722 - DEBUG - [Thread-1] UM.Mesh.MeshData.calculateNormalsFromVertices [548]: Calculating normals took 0.0010020732879638672 seconds 2020-07-23 20:22:59,724 - DEBUG - [Thread-1] STLReader.STLReader._read [104]: Loaded a mesh with 4908 vertices 2020-07-23 20:22:59,737 - DEBUG - [Thread-1] UM.Mesh.MeshData.approximateConvexHull [503]: approximateConvexHull(target_count=1024) Calculating 3D convex hull took 0.008001089096069336 seconds. 220 input vertices. 220 output vertices. 2020-07-23 21:30:37,743 - INFO - [Thread-2] STLReader.STLReader.load_file [52]: Using NumPy-STL to load STL data. 2020-07-23 21:30:37,764 - DEBUG - [Thread-2] UM.Mesh.MeshData.calculateNormalsFromVertices [548]: Calculating normals took 0.0010001659393310547 seconds 2020-07-23 21:30:37,765 - DEBUG - [Thread-2] STLReader.STLReader._read [104]: Loaded a mesh with 5946 vertices 2020-07-23 21:30:37,775 - DEBUG - [Thread-2] UM.Mesh.MeshData.approximateConvexHull [503]: approximateConvexHull(target_count=1024) Calculating 3D convex hull took 0.006000041961669922 seconds. 207 input vertices. 207 output vertices. etc How do you open the files? By drag and drop? What happens when you do? Do any messages show up along the bottom of the display? Does the model show up at all in Cura?

The Initial Layer Height will affect how much material is extruded. If you make a "thicker" layer, more material will be extruded to "fill" that layer. A thinner layer results in less material being used for that first layer. Changing the initial layer height will not "squish" the print more or less into the buildplate. The Z Offset does not affect how much material is extruded, but only how close the first layer is printed to the buildplate. A negative Z Offset will squish the print into the buildplate. A positive Z Offset can make it easier to remove a print from the buildplate, while increasing the risk of the print coming loose during the print. The initial layer height is used to compensate for a buildplate that is not entirely flat or well leveled. The Z Offset is used to increase or decrease buildplate adhesion. They are two different tools for different goals.

The creality printer definitions - like the Ultimaker printer definitions by the way - is configured to have different quality profiles per material. If there is an "unknown" material, there are no quality profiles to choose from, and this is what Cura shows. A quality profile is much more than a choice of layer heights. The alternative to having different quality profiles per material in Cura is to have one set of profiles for all materials. If there is no set of quality profiles to choose from, Cura shows you the bare defaults of all settings. You can still adjust these, and the settings you enter will be used. To print with eSun PLA+ with PLA profiles, the simples way is to make a copy of the material and change the material type from PLA+ to PLA.

It is not a question of updating it. It is a question of finishing the work someone else started. Feel free to try, but there are bound to be dragons along the road which made @ghostkeeper abandon it. Or it could have just been a lack of time. I have not looked into the code, or problems therein. If you would want to make this into a plugin, you would have to jump through some hoops to contain the changes to Cura and Uranium inside your plugin.

Well, considering that an Ultimaker developer did not get this working in a satisfactory way, I would think that `setExtraOverhang is the least of your worries. You need to use/update the accompanying Uranium branch: https://github.com/Ultimaker/Uranium/tree/feature_custom_support

It isn't. It is used to show the temperatures in the monitor interface. There is no host-side thermal runaway detection in Cura (or any other host I know of). This should be handled by the firmware.

That is incidentally the situation with Cura and USB Printing. No printers since the Ultimaker 2 have officially supported printing over USB. As an effect, USB Printing has had no substantial work done to it since then. Auto temperature reporting does not work with all printers, because it is disabled in many firmwares. I don't think there are any Ultimaker printers that support it out of the box. So realistically, there is no chance that Ultimaker is going to put work into supporting it in Cura.

It does.

The list has a scrollbar, but it is hidden until you use it. This will be fixed in Cura 4.7.

You don't need another slicer, you just need another host; ie a program to send the gcode to your printer. You could try printrun/pronterface. Personally I am partial to using OctoPrint so I don't have to keep my main computer running and connected to the printer 24/7.

Alternatively, you could look into using the picking that is provided by Trimesh: https://trimsh.org/trimesh.ray.ray_triangle.html