ahoeben

Unfortunately, @ghostkeeper has left the building...

Sure it is, but you need a recent release for it to be compatible with Cura 5 and newer. https://github.com/smartavionics/RawMouse/releases/

That's not a lot of fact to go on. What OS do you use? The reason I ask is that the issue does not reproduce for me on Windows 10. Perhaps, if you could let use know what OS you use (and possibly what GPU and driver version), we can narrow down the search for ways to reproduce this, and then fix it (or find a workaround).

It looks like Cura 5.4 is having an issue getting proper OpenGL 4.1 support from your GPU. Either that, or you may have (inadvertently) have enabled the option to "Force layer view compatibility mode" in the General preferences in Cura. This could also have been changed by loading a project file from someone else who has that option enabled. You might like the Tabbed Settings plugin available in the Marketplace:

Cura (normally) uses the color specified in the material. Change the material and it should change the color on the buildplate. What material do you have selected?

You may also be interested in the Tabbed Settings plugin (available from the Marketplace). It has a "smart catergory" which shows the settings that have a different value than the currently selected profile: For more information, see this thread:

The striped pattern indicates that the model does not "fit in the build volume" or that it collides with an area that is not available for printing. I think - but that is just a guess - that Cura is reserving space for a prime-tower in the unfortunate location where the model is located. The quick fix is to move the model to the side a bit, the better solution would be to change the position of the prime tower.

Ha, turns out there never was a profile selection dropdown unless the sidebar gui plugin was also installed, as evidenced by the screenshots in the opening post of this thread. Thanks again for catching this oversight @redeyesxbl! A fixed version is available here: https://github.com/fieldOfView/Cura-TabbedSettingsPlugin/releases/tag/v1.0.2-DEV Download the .curapackage file and drop it onto the Cura buildplate as if you were opening a 3d model. Barring any new bugs, I will push this to the Marketplace too ofcourse.

That was certainly not intentional. I mean, I am convinced that the UX of Cura with the Sidebar GUI plugin is better, but the idea is that the Tabbed Settings plugin works independent of the Sidebar GUI plugin. I will fix the Tabbed Settings plugin so it is also fully functional on Cura 5.4 without the Sidebar GUI plugin.

It looks like somehow Cura was not allowed access to write to its configuration folder. This could be a result of launching Cura "as administrator" in the past. Best not to do that.

Try renaming cura.cfg in C:\Users\Niki2\AppData\Roaming\cura\5.4\ to cura.cfg.bak.

In many places, the Cura frontend uses Python formulas to calculate values. One thing to keep in mind is that CuraEngine does not know how to parse Python statements in .def.json, and as a consequence it does nothing with the "value" specified in .def.json files. Instead it only looks at "default_value". You may notice in the Cura frontend that some settings are a "child" of other settings. These are "more specific" versions of their parent. As a general rule, CuraEngine only looks at settings that have no "more specific" versions. In the case of the "Infill Density", there is a more specific ("child") setting named "Infill Line Distance", which inside Cura gets calculated from the infill density and the infill line width. CuraEngine can not do that calculation, so you will have to do that for CuraEngine. In short, instead of the infill_density, you should be specifying the infill_line_distance. With regards to the bottom_layers setting, note that there is also a setting named initial_bottom_layers. Normally Cura copies the value from the bottom_layers setting automatically (with a Python statement in the "value"), but if you use the commandline, you are on your own and have to specify an initial_bottom_layers value too. I hope this helps.

Can you please elaborate what is broken with the tabs plugin?

None of these scripts will be very helpful. They are meant to be run from inside Cura, and it is no small feat to run them standalone. Additionally, there is no easy way to create a thumbnail image if all you have is a gcode file. Inside Cura, you have the 3d model loaded and it is easy to create a view of that 3d model. Outside Cura, how would you make that image that you would include in the gcode in the first place?

Looks like this is not a color difference, but a transparency difference, caused by a varying thickness. This varying thickness is caused by an uneven distance from the nozzle to the buildplate, ie an uneven buildplate. To mitigate the issue, you could try to increase your initial layer height in Cura, but it would be better to make sure the bed is actually level and flat.

Unfortunately, I can't. I know nothing about what printer you use. It sounds like Cura 5.4 may be using a different speed or acceleration for your feeder, but I don't know why or if this is indeed the issue. I need more information. Perhaps you could prepare a simple gcode file created with Cura 5.3 and the same file created with Cura 5.4. Then we can see the difference in the gcode files.

Don't be too hard on yourself; I must say it is a bit of a mystery to me why this was changed.

What OS do you use? On Windows, the Cura version you install should be totally independent of any version of Python you have installed.

The function of the "Custom >" button has been moved to the "Show Custom" link above the Infill slider.

If the above works for you, then uncheck the "Restore window position on start" checkbox in the General preferences. Cura will then no longer use those two lines.

Then you are going to have to share a link to the model so I (or someone else) can hev a look at what is going wrong.

we press the buttons and printer goes "weepweep" (for a couple of hours)

Try loading the model into 3D Builder (which comes free with Windows). It will complain that the model is "invalidly defined" and offer to repair it. Then export the model as a new version.

I don't fully understand why exactly, but lowering the `Maximum Resolution` setting (under `Mesh Fixes`) to 0.2 or lower seems to fix the issue for this model. See https://github.com/Ghostkeeper/SettingsGuide/blob/48b3c7902c6401cf43fffd14795947c74cd02275/resources/articles/meshfix/meshfix_maximum_deviation.md for more information about the setting