ahoeben

I have many thoughts. One even relates to your predicament.
 
I'm guessing you have multiple screens, and that the crash happens after you have dragged Cura to another screen and closed it down from there. For some reason Cura is unable to restore the window at that position on the next launch.
 
Disable all but one screen and start Cura. Go to the General pane of the preferences and uncheck the option to "Restore window position on start". Close Cura and reenable the other screens.

CuraEngine does not actually use the Nozzle Size setting, but instead it uses the Line Width setting and some other more specific line width settings. In part this is a leftover from a time where most Ultimaker profiles would use a line width that was 7/8th of the nozzle size (so a 0.4 mm nozzle would print with a 0.35 mm line width).
 
The optimal Line Width to print with is affected by the nozzle diameter. But you can print fatter and thinner lines than the nozzle diameter.
 
The line width and the layer height determine how much material needs to be extruded. The material diameter is used to convert that to the amount of E-steps. The flow parameter is just a multiplier to adjust for slight miscalibrations and material slipping.
 
For printers that have a nozzle size dropdown, you are actually not just affecting the nozzle size, but you are loading an entire settings profile that could have many other setting changes (such as printing speed, material temperatures, etc).
 

The message means that Cura thinks there is nothing printable on the buildplate. Is your model on the buildplate, or has Cura placed it off the buildplate?
 
Could you share a screenshot?

Cura tries to protect your printer against cold extrusion.
 
Cura tries to see if there is anything in your start gcode that heats up your extruder(s), and bed. If not, it will insert a heatup sequence on its own. Cura does not know about your PRINT_START macro.
 
The logic is here:
https://github.com/Ultimaker/Cura/blob/4.4/plugins/CuraEngineBackend/StartSliceJob.py#L428

Cura looks for the text "{material_print_temperature}", "{material_print_temperature_layer_0}", "{default_material_print_temperature}", "{material_initial_print_temperature}", "{material_final_print_temperature}" or "{material_standby_temperature}" in the start gcode to check if the start gcode contains extruder heating commands (so it does not actually care if you use M104 or M109 or not).
 
Cura looks for the text "{material_bed_temperature}" or "{material_bed_temperature_layer_0}" in the start gcode to check if the start gcode contains bed heating command (so it does not actually care if you use M140 or M190 or not).

That happens when Cura is running in "compatibility mode" . You may have set the preference to "Force layer view in compatibility mode" option in the General preferences in Cura.

Do you have an Ultimaker Original, or an Ultimaker Original Plus? The Original came with a wooden printhead, the one on the Original Plus came with a metal printhead. Make sure you add the proper model to your Cura, as the firmware is significantly different and gets selected by you having the active machine in Cura properly selected.

The USB support in Cura is not actively maintained, and hasn't been for man years. If it works it works, if it doesn't work it doesn't work. Period. You can be uninterested in the following advice, but it is all you are going to get.
 
Your best bet if you want to continue printing over USB is to install OctoPrint (either on the same computer as Cura, or on a separate computer such as a Raspberry Pi) and use the OctoPrint connection plugin to connect it with Cura, and disable USB printing from Cura directly.

Those screenshots (however many there are) don't give us a lot to go on (especially since the forum scales them down), but I can take a guess and say "turn off Spiralize Outer Contour".

Apart from that plugin, there's also the option to turn off the prefix altogether in the General preferences inside Cura: "Add machine prefix to job name"

This is a bug. Please report the bug at https://github.com/ultimaker/cura/issues
 
Cura 5.6 introduced the functionality to have simple math inside the {} patterns, and apparently that broke existing functionality to get a value for a specific extruder.

I guess you are talking about the replacement patterns in the start- and end-gcode snippets?
 
You can specify the extruder like this:
{line_width, 0} # linewidth of 1st extruder {line_width, 1} # linewidth of 2nd extruder {line_width, infill_extruder_nr} # linewidth of whichever extruder is used for the infill  

See this OctoPrint plugin for example:
https://github.com/paukstelis/OctoPrint-Cancelobject

The model seems to be too thin in the area where there's a hole.
 
There are a couple of things that can be done about this:
 
Enable the "Print Thin Walls" setting. This will let the printer use thinner lines to print very thin parts, although they might become wider than the model intends them to be. Reduce the line width. If you're printing something that has thin walls or webbings, make sure that the line width is slightly smaller than the minimum width of that part. However reducing the line width too much may cause underextrusion due to insufficient flow. To be able to reduce the line width further, you'll need to use a smaller nozzle. Add some horizontal expansion to the print. This makes the entire model wider on all sides, including the thin parts. They become less thin that way, so that they may now be printed. This does of course also ruin any dimensional accuracy and detail of the print since everything becomes thicker. Consider adjusting the model to the print, by making every piece at least as thick as your line width.  
 

Your model appears to be broken. At the very least the normals of some of the faces are flipped. You might be able to repair the normals in Cura with the Mesh Tools plugin from the Marketplace, or you can load the model into 3d Builder (comes with Windows) and let it repair the model when it tells you that "One or more models are invalidly defined", then save it as a new STL.

Coasting is the answer. You can read about the setting here: https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/experimental/coasting_enable.md
 

The problem is in this line in the Anycubic Chiron profiles:
https://github.com/Ultimaker/Cura/blob/4.13/resources/quality/anycubic_chiron/anycubic_chiron_normal.inst.cfg#L32
The material diameter should not be set in the quality profile. It overrides whatever is set in the Material preferences.
 
From a cursory look, this error is only present in the AnyCubic Chiron profiles. So the subject of this thread should be "Material Settings not considered with Aycubic Chiron printers".

I don't know why that would be happening to you, but you can always download the latest release of the plugin here:
https://github.com/fieldOfView/Cura-MeshTools/releases
 
Download the MeshTools_v3.7.2_Cura5.0-current.curapackage, and drop the file onto the buildplate in Cura as if you were opening a 3d model.

If they were the same, then why would we need to have both?
 
Here's a good article from the Settings Guide plugin on the subject of missing parts: https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/troubleshooting/missing_parts.md
Either the details are too small to print with your current configuration, or your model is faulty ("non-manifold"). From just the screenshots, it is hard to see which of these two options is the problem here.

It means that the printer is actively connected to Cura and you can send gcode files to it (as opposed to a printer that is not connected and you have to manually transfer a gcode file to it).

Actually the path does not go outside the buildplate.; the brim and skirt are now truncated to the buildplate, precisely to prevent those grey areas that people did not understand. It is a feature, not a bug.

I think this is an oversight, resulting from using a low resolution display and possibly having a couple of plugins installed that add icons to the toolbar.
 
One workaround would be to install the Sidebar GUI plugin from the Marketplace. It rearranges some UI elements, and as a side-effect it mitigates this particular problem.

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.
 
See https://github.com/Ghostkeeper/SettingsGuide/blob/48b3c7902c6401cf43fffd14795947c74cd02275/resources/articles/meshfix/meshfix_maximum_deviation.md for more information about the setting

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.

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

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.