ahoeben

What happens when you press Cancel?

Do you happen to have multiple monitors? If so, can you try temporarily disconnecting one before you start Cura?

The update is available on the Marketplace now. No need to use the curapackage anymore.

Are you sure you had the whole part selected when you exported the STL?

I'm having to answer the same question in multiple places, multiple times a day, so I guess I need to do some explaining. An updated version of the OctoPrint Connection plugin is needed for Cura 4.2 and 4.2.1. This updated version of the plugin has been submitted to the Marketplace, but at this time is still awaiting approval. For the time being, you can download the version that is compatible with Cura 3.5 all the way to Cura 4.2.1 here: http://files.fieldofview.com/cura/OctoPrintPlugin-v6.1.0-2019-08-02T07_23_49Z.curapackage Download the file and drop it onto a running Cura application window. Then restart Cura. Update: An updated version of the OctoPrint Connection plugin is now available in the MarketPlace. Each version of the OctoPrint Connection plugin has an built-in check to see what version of Cura it is running on: It specifies a minimum and maximum version it is compatible with. I check the plugin with each released version of Cura before submitting a version that is specifically marked as compatible with that version of Cura. I started doing this more than a year ago because on multiple occasions the plugin got the rug pulled from underneath it by changes to Cura between versions; at more than one point, having the previous version of the plugin installed with the new version of Cura would have stopped Cura from starting, even leading to certain versions of the plugin having to be specifically blacklisted in Cura. I normally try to update the plugin during the beta period for a new version of Cura, so that the updated version of the plugin is available through the Marketplace when the stable version is launched. In this case I submitted the updated version a week before the launch of the stable version. Unfortunately, the time between the launch of the beta and stable versions of Cura is a busy time for the Cura team, so approval of new plugins sometimes gets delayed. There was an additional issue with the "contributors portal" where new versions of plugins are submitted which has further delayed the release of the updated plugin. I will discuss with the Cura team if my additional compatibility checks are still necessary so this hopefully will no longer be an issue going forward.

Here's a new version for Cura 4.2.1 http://files.fieldofview.com/cura/OctoPrintPlugin-v6.1.0-2019-08-02T07_23_49Z.curapackage Download the file and drop it onto a running Cura 4.2 application window. Then restart Cura.

In FreeCAD, the function you are looking for is making a Union of two shapes

@johnse is correct that the normals of the model seem to be incorrect, however they don't affect slicing. Normals are only used for visualisation. From the looks of it, your model is not "manifold". I think you modeled the torus and the cylinders and just moved them so they look like they make a whole. However, you did not join (or union, or boolean, or something else, depending on the modeler you use) the shapes so they don't actually form a single geometry. As is, the cylinder geometry just extends into the torus geometry, so you have what is called "internal geometry". When slicing, Cura makes cross-sections of the model. Looking from the outside in, the first edge-loop it encounters will be an outer wall. Going in, if it encounters another edge-loop, that will become an inner wall of a hole. Etc. In your case, because you have (sub)objects intersecting eachother, Cura simply looses track of what should be the outside and what should be the inside. Long story short: Cura fails to meet your expectation because your model is "wrong". Just because it displays well does not mean that it is suitable for printing.

Two of my plugins need to be updated, and are still awaiting review. For now you can manually install them. OctoPrint Connection plugin: http://files.fieldofview.com/cura/OctoPrintPlugin-v6.0.0-2019-07-18T12_32_22Z.curapackage Sidebar GUI plugin: http://files.fieldofview.com/cura/SidebarGUIPlugin-v6.1.0-2019-07-18T12_34_52Z.curapackage After downloading the curapackages, just drop them in the running Cura application, and restart Cura.

A version of the OctoPrint Connection plugin compatible with Cura 4.2 is awaiting review. In the mean time you can download it here: http://files.fieldofview.com/cura/OctoPrintPlugin-v6.0.0-2019-07-18T12_32_22Z.curapackage Download the file and drop it in a running Cura application.

It is indeed a bat file, which I start from the RDP session on a remote computer. The script closes the RDP session, and you have to start another RDP session, but Cura will have launched on the remote computer. See the social.technet.microsoft.com link above for what the script does.

This script works for me from a Windows RDP session: Caveat: it needs to be run elevated to connect back to the console. I don't know how this will work on a server hosting multi-user RDP sessions.

This StackExchange post explains the problem adequately: https://stackoverflow.com/questions/51705471/current-state-and-solutions-for-opengl-over-windows-remote As mentioned in that answer, perhaps you could write a script that closes the RDP connection and then launches Cura https://social.technet.microsoft.com/Forums/windowsserver/en-US/c8295ef8-3711-4576-9293-2c4965280165/opengl-and-remote-desktop?forum=winserverTS

The changed parts of the configuration are written to file periodically every 10 seconds (and when closing the application)

No, sorry, I don't have something more basic.

You could create a copy of the SliceInfo plugin, and modify it to send its data to a server/database that collects the usage data for you: https://github.com/Ultimaker/Cura/blob/4.2/plugins/SliceInfoPlugin/SliceInfo.py#L31

I have experience with neither printer, but I think the difference in hotends could explain the difference. Due to differences in temperature sensors, conductivity between the heater and the nozzle, insulation of the nozzle, etc, the temperatures of the molten material could be different. Hotter material means more stringing, because the material is more oozy at hotter temperatures. The geometry of the hot zone could also play a role; I can imagine that if the hot zone is bigger, there is more molten material being pulled down by gravity so more material oozes out. That would suggest you would need more retraction in the stringy printer.

Only the AppImage is tested and supported on linux by Ultimaker.

Are you using the AppImage version? If not, please try that. There are some issues between Cura and newer versions of Qt. By using the AppImage, you will use a Qt version that is tested with Cura.

It is testament of how firmly Ultimaker believed the aluminum buildplates would be released.

AFAIK, development of the feature to support different types of beds was halted when the aluminum bed for the S5 was canceled.

You can use the Material Settings plugin from the Marketplace. Cura already has a "Build Volume Temperature" setting, though it is not used in the gcode. You can insert it in your start gcode snippet as " {build_volume_temperature} ". After installing and restarting Cura, see Extensions -> Material Settings -> Configure Material Settings to add this setting to the list of Print settings in the Materials preferences.

Wow, that's a lot of priming waste. Prints look good though.

Sorry, I forgot to mention that here. Thanks for letting me know the version on github works for you. Others, please help me test the updated version of the plugin: http://files.fieldofview.com/cura/OctoPrintPlugin-v6.0.0-2019-07-18T12_32_22Z.curapackage Download the file and drop it onto a running Cura 4.2 application window. Then restart Cura and the OctoPrint Connection plugin should be working again.

I don't think it is possible to solve the issue for mere mortals.