ahoeben

I don't see a reason in the gcode file for your printer to show that message. The firmware checks if the first line of the gcode file starts with ";FLAVOR:UltiGCode" here: https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJarExtended/Marlin/UltiLCD2_menu_print.cpp#L432 Only if it doesn't start with that line, it shows the message you see here: https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJarExtended/Marlin/UltiLCD2_menu_print.cpp#L466 However, your gcode file starts with that line. So I don't see how the firmware would show the message from this file.

This is due to how the LK5 Pro definition is created. It says the printer has "a set of different nozzle sizes" for which it should include profiles, but then it only includes a profile for a single nozzle size. Had the creator of the printer definition just said that there are no nozzle-specific profiles, then you could have selected any size nozzle you wanted. You can add your printer as a Custom FFF Printer, and have full freedom over nozzle size, number of extruders and more.

You load the STL file into Cura, and let Cura "slice" it for you. Then you save the gcode. If you get stuck at some point then please be more specific about what you can not figure out.

That message is shown when you open a previously sliced G-code file in Cura. G-code files are not 3d models, so they can not be sliced again. This has nothing to do with backwards compatibility.

I think it is fairly bad advice to delete that file. On the next start of Cura, Cura will tell you to add a new printer. You will also loose configuration like what settings are shown. Temporarily disabling the second display, starting Cura and unchecking the "Restore window position on start" checkbox in the Preferences is really a lot less error-prone.

If you could slice a small model and post a link to the resulting gcode file, then we can have a look at what is going wrong gcode-wise. Also useful is a project file saved with File -> Save project...

In the Machine Settings, make sure the GCode flavor is set to Ultimaker 2, as opposed to Marlin. Note that if you want to do printing over USB (or via OctoPrint) instead of via SD Card, you need the GCode flavor to be Marlin. With GCode set to Marlin and printing via SD-Card, you will get that message but it should still be possible to start the print after that. Nothing changed functionally in the firmware for the UM2+ (which you effectively have) since then.

Save a project using File -> Save project... You don't even have to have a model loaded. Upload the project file somewhere and post a link here. That way we can see what your configuration is, instead of guessing.

Cool. Cases like yours are the reason why the option "Origin at center" is not automatically coupled to the elliptical buildplate option.

I always think this is a good explanation of what a non-manifold mesh is, and why it is a problem: https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/troubleshooting/missing_parts.md#non-manifold-meshes

@Joli can you elaborate on what you are trying to do? What exactly do you mean by "combining into one"? Grouping multiple objects, like @Carbon shows, is one thing, but there is also merging objects for printing with multiple materials. But perhaps you mean something like putting a Mandalorian helmet on a Buddah statue. The latter can better be done in a dedicated modeling application.

It is not "hardcoded" in the code (as few things as possible are in Cura), but it is the default value as specified in fdmprinter.def.json: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json#L3174

There's an extremely subtle queue in the screenshot. Do you see how the label for "Travel speed" is italicized? That means the value or formula originally set in the printer, quality or material profile is being overridden by a user-defined profile (ie: a profile you created). On a general note, you can get a hint of which settings affect other settings or are affected by other settings by looking at the tooltip of the setting. If there is a setting listed as "is affected by" then the value of the current setting is a formula that references those settings. However this mechanism is not very smart. In this (somewhat theoretical) example, speed_print affects speed_travel, but not in a way that is immediately clear: speed_travel = 120 if speed_print > 20 else 100 You would only see the travel speed change around a specific change in print speed. But I guess the tooltip mechanism also does not take into account that you have overridden the travel speed formula in a profile.

Please clarify what you mean by "no longer slice properly". What can happen is that Cura no longer starts or slices at all (eg because of changes in graphics drivers or changes in firewall policies). But a Windows Update can not change the actual gcode that is created. If you think that something changed between Cura 4.6.2 and 4.13.1, you could try reinstalling Cura 4.6.2: https://github.com/Ultimaker/Cura/releases/tag/4.6.2 Most previous releases can be found here: https://github.com/Ultimaker/Cura/releases

USB printing functionality in Cura should be regarded as rudimentary. Ultimaker has no interest in improving the USB printing in Cura, since no currently shipping Ultimaker printers support printing via USB. The idea of the current implementation is that it auto-detects printers connected to serial ports. If it works, it works. If it doesn't, you are sort of on your own. I recommend disabling the USB Printing functionality in Cura (via the "Installed" tab of the Marketplace), and use OctoPrint instead. That way you have a separation of concerns; Cura does the slicing, OctoPrint does the hosting. If Cura crashes or otherwise needs to be restarted, that will not affect your prints. There's a good integration between Cura and OctoPrint via the OctoPrint connection plugin from the Marketplace.

An off-topic tip, as a reaction to your screenshot: It looks like you have the option "Origin at center" checked in the machine settings, but you don't have a delta-style printer. It is fairly unlikely that your firmware actually has its origin at the center of the buildplate. So unless you are getting prints in the location where you expect them with your current configuration, you may want to uncheck the option "Origin at center" in the Machine Settings (on the Printers pane of the preferences).

See Extensions -> Manage backups

Ultimaker never released a Cura 3.6.31. If you are using a "fork" (someone else's version) we generally don't know what they changed and if that causes your issue. Have you tried a recent Ultimaker Cura version? The current version is 4.13.

I'll add the information to http://files.fieldofview.com/cura/Replacement_Patterns.html since people are finding that more and more, though I am reluctant to make it into a full-on documentation page with all sorts of tips and tricks.

I think the model is just too thin there. You could try if scaling it up fixes the hole. Read the section about thin parts here: https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/troubleshooting/missing_parts.md#thin-parts

For some configurations I have heard it does. Can you try resizing the window after moving it to the secondary display?

In the General preferences, there's a checkbox that says "Restore window position on start". Uncheck that.

See that pointy gray "shadow"? That needs to fit inside the build volume. The model is striped to show that Cura thinks it does not currently fit inside the buildvolume. There seems to be a "stray" point or piece of geometry in the file. Can you post a link to the model?

"Build Plate Adhesion Type" -> "None" instead of "Skirt".

Obviously the Ultimaker lawnmower is long overdue. It has been rumored since forever: https://community.ultimaker.com/search/?q=lawnmower&quick=1