DivingDuck

Not the solution I would expect but hey, we take what ever we get that helps for an never solved problem - even a not intended behavior as workaround. Great finding, thanks for showing it!

Then you should check your printer settings in firmware with the settings in your Cura Printer Settings. This is an issue that all slicers have when max speed and -acceleration settings are not matching. You see this more often with Cura because there are some default values that are not from this universe 😉 like default max speed values in the fdmprinter.def.json definition: 299792458000 mm/s. This isn't a problem if you have a good printer profile, but in case it is not complete and do not have the correct values for your printer then you will face the behavior you see as those default values will then take place in the calculation. Add the plugin Printer Settings from Marketplace and you can check the values and adjust those that are not matching with your printers max values in speed and acceleration. And remember, it is always a good idea to make a backup of your configuration folder first or at least a copy of your printer profile for experimenting with a profile where you don't know how this will end because of missing experience. We all started with low experience once.

I'm not from Ultimaker, just a normal user that uses Cura since quite some years 😉 Anyway I guess as well that there is an issue with the registry that I do not see on my installations (actually 4 different versions on this PC). You can go throe all entries and check where the problem is but I think it is easier to use one of the registry scanner/cleaner for this kind of job. This is all what I can suggest. Edit: (forgot the answer of one of your questions): Regarding how the updates are done, here are not only users that uses the latest versions. That is for a good reason. Having the versions installed in parallel give the ability to use a once made good tuned configuration for models all the time again if needed and have no to mess up with new versions where everything change with each update. So you can see that there is maybe a reason why one like the way how this works actual. Not saying that I'm always happy with this solution, but still with all these update surprises with each new version I'm mostly happy to have this "fallback" if we want to say it that way.

One way is Right-Click a .stl file, choose [Open with] and select [Choose Other App] and find the actual Cura version. There you can usually mark the selected program as standard app.

@Slashee_the_Cow, indeed the poster should at least give some minimum information to understand his post better... The problem can happen with a desktop pc as well in case you have a cpu including graphics support and a additional graphics card. Unfortunately that isn't the main route cause of the problem. The problem is mostly a faulty (or faulty installed) display driver - except from the fact that the graphics hardware don't support opengl >= 2.0 as this is the minimum version for running Cura. And more often was this introduced from the windows update where they fall back to an ancient display driver at some point. The best advice for most users is maybe to check and update all installed graphic card driver's in the pc manually. Switching the graphic device is usually only a temporary workaround that will bite the user again later once more. It isn't a general solution as well as not every user have two graphics solutions build in and it assumes also that the second device uses updated drivers (what is maybe as well not the case). 🙂

Hi @ahoeben, was you able to find out what the reason of that error was? Best regards, DD

This is the case @GregValiant described. My A4/80 g printing paper is around 0.1 mm thick. This is the offset you would like to compensate with a tool like Z-Offset. Most people didn't compensate this that way back in the days and use a higher flow rate for the first layer instead.

@Slashee_the_Cow, this was what I had in mind. Or wrong reassembling of a dual screw after a cleaning session. Many possibilities for generating such problems. Anyway, hope, he will find a solution for his problem.

There is a plugin for manipulating print job names called Printjob Naming. Maybe you had use that some when and then forgot about it?

Maybe Z axis out of level? I have seen such problems sometimes when someone try to level a z axis to the bed axis not knowing that this is the wrong method doing this. I can't really believe that a manufacturer choose wrong steps settings for a t8 rod. This is a very basic calculation and will never change. The pitch of an lead screw is per definition exact. A difference of 1.1 mm on such a small distance of 20 or 40 mm makes no sense except there is a mechanical problem that cause a z-axis to be out of level. I would suggest to check whether your z axis is out of level. Do it in the old way manually. First delete the saved mesh values for auto bed leveling, if your printer have auto bed leveling. Home your z axis and move it up say 100 mm then try to exactly measure the height on both sides of the z axis against the bottom profiles. They have to be exactly the same. Move the axis again 50 or 100 mm. Now your measurement difference have to hit exactly that value on both sides. If not, find the problem as there is not a lot left over that can cause such a problem and most of them was already told. After this is achieved level the bed manually so that it is in level with the z axis. Two things that just came in mind while writing this post: Do you change the bed temperature during printing or are you leveling your bed cold or while it is heating up? This can cause as well height problems and is easily to check. Maybe your print bed is warping too much in some locations. This can be check by comparing the mesh bed leveling values for a cold and a heated bed.

Take all the time you need. For Cura 5.6 I had build up everything from scratch and after importing my own material definitions files again the problem was solved so fare. There was much to much left over artifact files in my config folders as you may recognize. 🙂

@ahoeben Here it is. Let me know when you finish the download. I then like to delete that big zip file. Edit: File removed

I can make a copy of my 5.5 configuration folder for testing if needed.

@ahoeben, everything ok from my side. My comment was not meant as critic to you. I well know that you only try to help fixing problems that are mostly not yours. Regarding the Material Settings plugin (v3.6.2), I just tested it and feel bad that I didn't thought on that and test this. You are on the right track, after removing the plugin the material manager do not crash. After reinstalling the plugin the material manager crash again.

@ahoeben, this is how it was shown on my installation for Cura 5.5 in case it maybe helps for other users with similar problems: This report was send several times with each >=5.1 version, but I guess it was never reviewed. cura-material manager crash.zip

I had this as well, but not only with Cura 5.6. Version 5.5 had the same Problem. You need to check your material files. For me it was a custom material definition for two filaments. It was working for all 4.x and 5.0 versions but then with newer version Cura crash when ever I try to open the material manager. Two weeks ago I thought I need to find the problem and deleted all custom materials and import them back again. I did it one by one and then identify two material definitions that had force a crash of the material manager. After deleting the GUID in the material files and correcting metadata I was able to import them again. If I remember correct there was something like a linked material definition inside those files. I can't remember that I ever did this, but who knows - I defined those two material definitions maybe 3 years ago....

c:\Program Files\UltiMaker Cura 5.6.0\share\cura\resources\materials\generic_pla_175.xml.fdm_material Looking to the generic PLA Material setting it state 60°C as default temperature.

It seems you have problems with all newer versions. Perhaps you have a problem with obsolete plugins and/or malformed configuration files. Since the spinning wheel is showing you should at least find a log file in those locations that can help to identifier your problems: %appdata%/cura --> stderr.log %appdata%/cura/5.6 --> cura.log It may be a good idea to start Cura without any configuration files that it can find and convert to a configuration file set for 5.6. Therefore you need to backup all directories in %appdata%/cura and then delete them all. You need to close Cura before doing so. After deleting all the directories you can start Cura 5.6 again. It should now start as a vanilla installation without any configurations and plugins.

@zerspaner_gerd, Das liegt an Cura und wie stl und 3mf interpretiert wird. Ich hatte dazu mal vor ein oder 2 Jahren was geschrieben, da es hier immer zu den gleichen Missverständnissen (?) kam. stl Dateien werden z.B. immer in der Mitte des Druckbetts positioniert und 3mf Dateien immer auf der 0,0,0 Koordinate Beispiel: Baugruppe in Fusion Die Baugruppe als stl Datei exportiert, Cura interpretiert das so: und nun die selbe Baugruppe als 3mf exportiert: Nett, oder? Edit: Ich habe den thread gefunden wo ich das verhalten von Cura diesbezüglich mal dargestellt habe:

Ja, so sollte es auch aussehen. Jedoch ohne dass ich das nochmals manuell in Cura zusammenfügen muss. 🙂 In Fusion360 kann man so eine Modellgruppierung schon immer exportieren. Ich habe dies früher auch regelmäßig benutzt, da es sehr bequem war. Unter anderem auch für Modelle, die ich als "Print in Place" modelliert hatte.

Wenn ich die Projektdatei importiere sieht es genau so aus, nur Support und neuer Drucker wurde hinzugefügt. Ich habe gerade mal ein wenig mit meinen Modellen in Fusion360 und dem Export für Cura herumgespielt. Cura verhält sich beim Import anders als früher wenn man mehrere Modelle als ein zusammengesetztes Gebilde im 3D Raum importiert. Man muss nun zuerst das automatische Platzieren auf dem Bett abstellen, dann die 3mf Datei platzieren, danach alle Modelle auswählen und gruppieren. Dann kann man die Gruppe wieder so positionieren, dass der Verbund der Einzelelemente im 3D Raum nicht verloren geht. Nun wieder die automatische platzieren aufs Bett einschalten und platzieren lassen. Ich meine mich zu erinnern, dass dies früher einfacher war - aber vielleicht irre ich mich auch. Das ist jetzt gefühlt ganz schön kompliziert in der Umsetzung geworden...

Bei mir sieht es so aus: Ich habe allerdings nur die Modelle in Cura 5.6 importiert und nicht als Projekt geöffnet.

Bei mir liegen deine Modelle richtig wenn ich diese importiere. Hast du vielleicht unter den Einstellungen Konfiguration -->Allgemein -->Setze Modelle automatisch auf der Druckplatte ab nicht aktiviert? Des weiteren gibt es ein nettes Plugin namens Auto Orientation welches ebenfalls für manche Fälle hilfreich ist

Check if there is a log file in folder 5.6 Edit: Please don't double post.

No and yes 🙂 You mentioned your firmware was from 2017. Smoothieware introduce in 2020 (if I remember correct) some changes that may break with your old config file. It is not a big deal but you need to download the actual config template from their Github page and transfer the config values from your old file into the new one. It's a one-timer and didn't happen since then again. Use the actual firmware that they provide on Github as they did quite some changes since 2017 and fix some errors as well. You can also copy/download the "actual" source code as well and compile the firmware yourself if you like to do so. And don't forget to backup your actual firmware and config file (but I guess you did already...)