ahoeben

If you add a screenshot, or better yet a link to the image and a project containing the model and settings you used (File -> Save Project...) we'll be able to see what you mean by grainy.

I think few other people have the luxury of a timemachine. I don't think Cura 5.9 will be available before the end of 2023.

Without a crash log we can only guess. If you have the "Printjob Naming" plugin installed, please check if there is an update for it on the Installed tab of the Marketplace.

Could you also try this: https://github.com/pyinstaller/pyinstaller/issues/4855#issuecomment-679942344

Could you download and install DependeciesGUI from here: https://github.com/lucasg/Dependencies/releases/tag/v1.10 Then drag C:\Program Files\Ultimaker Cura 4.9.0\lib\Arcus.pyd onto its window, and post a screenshot of what you get? Hopefully that will tell us why that component won't load.

Not normally, no. Sometimes a newer version of Cura requires all your plugins to be updated. But not Cura 4.9 vs 4.8. Pay attention when you are installing the new Cura version though. The installer asks you if you want to uninstall each older version it encounters. If you choose to do so, it will ask you if you also want to remove its configuration data. That configuration data contains your plugins and ALL of your print settings. So you probably DON'T want to remove the configuration data!

No, that is not the issue at all. The installer is not the problem. The installer does not try to mount any drives. The problem is that Cura tries to look for its components on X: before looking in the place it was installed to. As I have stated elsewhere, this is due to the buildsystem that Ultimaker uses for Cura development. This is a long-standing issue. Cura 2.x had the same problem with drive D, which is much more common in computers. So they changed the build-system to X: (instead of properly fixing the issue that Cura insists to try to access the drive it was built on). But accessing the X drive does not seem to be the problem here. Something goes wrong accessing or using a part of Cura that is installed with the application.

No, not really. That means that either you changed the setting value from its default. Or it could be your cat. But more likely it was you, while scrolling through the settings you may have inadvertently clicked on the checkbox.

@ozhawk, @kazu_zo3 and @pjaxed, do you have a drive mapped to the driveletter X: ? If so, could you try mapping that drive to a different letter?

Users of the "Printjob Naming" plugin, if you have a problem opening files could you please check if there is an update for the plugin in the Marketplace? The latest version fixes an incompatibility with Cura 4.9, and was published around a month ago.

I am the developer of that plugin. A full cura.log would be helpful to fix the issue you were having. It also helps if you could say what sort of prefix & postfix pattern you were using.

Did you try any of the things I suggested?

The nozzle on the left of the printhead cannot physically reach the right of the print bed. Try pushing the printhead all the way to the right, and see where the left nozzle is in relation to the bed. Now do the same thing on the left side of the bed. The same works for the right extruder; it cannot reach as far to the left as the left extruder.

Hard to tell from these images. If you save a project (File -> Save Project...) and post it somewhere (google drive, onedrive, dropbox, etc), we can have a closer look at both the model and the settings you currently use.

Add a couple of cutting meshes. They will cause a solid layer (or two) where they overlap the geometry.

The project file works for me. In your screenshot, it does not look like the file has been opened; it looks like Cura was started but opening the project file just did not happen. Have you tried opening the file via File -> Open... (or the folder icon in the top bar underneath the word "Ultimaker")? You can also try dragging the file from file explorer onto the buildplate in the Cura application window.

Please be more specific than this. The gcode files look ok to me. I don't know what your problem is printing these files, since I can not run your gcode files on your printer, with the version of Marlin you compiled for your printer.

Kidding aside, it is mostly how I develop my plugins. The biggest difference is that I run Cura from source which shows the log output directly as Cura starts. Also my Cura starts up in 15-20 seconds, so I can keep my coffee intake moderate.

It is very possible that the firmware you use does not properly support G2/G3 Arc movements. I don't have your printer, and I don't know what firmware you have installed.

It is an artifact of the buildsystem. The source files are on a drive labeled X: at Ultimaker, and for some reason Cura keeps looking for the files in their "original" location before using the files installed in your program files folder. If there's an inaccessible drive X, each file will result in a timeout after ~20 seconds or so before continuing. There are many files. Why X:? Because it was deemed less prevalent than the previously used 😧 drive. The D drive used collide with removable drives, which caused a similarly annoying issue that Windows told the user there was not disk in drive D a couple hundred times. I'm not quite sure why the buildsystem doesn't use an ntfs junction instead of a driveletter. That would forego the entire drive letter thing. Better still would be to stop Cura from trying to find the files in their "original location" in the first place.

Modify the Python code, double-click on an STL to load up Cura, go get a coffee or something because Cura is DEATHLY slow, slice, check results, close Cura, lather, rinse, repeat.

A screenshot or two of what you see, or a link to the project file would be helpful to see what is going on. Could it be that you are on the "preview" tab instead of the "prepare" tab?

Do you have a network drive mapped to the driveletter X:? If so, try mapping it to a different drive-letter.

A new version of the Mesh Tools plugin is now available in the Marketplace, which lets you set a unit for STL, OBJ and PLY files:

A new version of the Mesh Tools plugin is now available in the Marketplace, which lets you set a unit for STL, OBJ and PLY files: