ahoeben

https://github.com/Ultimaker/Cura/tree/master/plugins/VersionUpgrade Cura has been trying to do that ever since version 2.1

That was fixed with the latest version of OctoPrintPlugin, which is available through... the Toolbox Fortunately you can also download the curapackage directly, and drop it into the Cura window https://api.ultimaker.com/cura-packages/v1/cura/v4/packages/OctoPrintPlugin/download

Nice result! Note that the research you reference is actually by Tim Kuipers (@bagel-orb). Matt just wrote the blog article on it.

The more "official" way to do what you describe is to write an OutputDevicePlugin. See https://github.com/Ultimaker/Cura/wiki/Plugin-Directory and specifically https://github.com/Ultimaker/UraniumExampleOutputDevicePlugin That way you would not have to create an intermediate file on disk, but just send the gcode to your http connection. For inspiration you might also want to check out http://github.com/fieldOfView/OctoPrintPlugin which sends gcode to OctoPrint over an HTTP connection, but that is a rather bigger plugin (that also provides monitoring). A postprocessing script could work in some cases, but is really meant for something else. It does not give you access to the gcode file (just the raw gcode as a string), and is actually run *before* the gcode is handed over to an OutputDevicePlugin.

If only Cura Connect were open source, someone could implement functionality like this...

Cool, I had forgotten all about the "Select models when loaded" functionality. So I did contribute to Cura 3.4 afterall ?

This is what it looks like for me. Could you try if there's a "hidden" button next to the red X ?

What OS are you using? Does it matter how long Cura has been running before it stops recognising new printers? Is it a consistent thing or just sometimes?

@mokush there seem to be a couple of interface elements missing. @ctbeke, have you seen this before?

The plugin is now available in the Toolbox

You create your own packages from github? In that case, use the current default branch, which is 3.4, not master.

Unfortunately Toolbox is still serving up the 3.4.0 version of the plugin, not the fixed 3.4.1.

Thanks for taking time to fix that after working hours.

Nope, api.ultimaker.com is still serving up the 3.4.0 version of the plugin. The fix is in OctoPrintPlugin 3.4.1. @Msuurmond, could you check?

All of these "importers" (FreeCAD, OpenSCAD, Blender, Inventor, etc) rely on the original application being installed on the computer. If you don't have it, the plugin will not work.

@Daid has said "contact me" on more than one occasion (talking about firmware sources)

I'm told the fixed version that I submitted a while ago should be available from today. A bit of a shame with the plugin having been downloaded >1000 times since the 3.4 launch. PS: it is not the Cura CONNECT window, it is the print monitor.

Point(s) taken.

Anyone who has a UM3 has the GPL-given right to receive the source as it is used in the product.

I am not as well-versed in CuraEngine innards as I am in Cura, but I know Cura and CuraEngine use libArcus to communicate. Cura used a dynamically linked python library. I can’t imagine CuraEngine uses a python library for communication, but I don’t see another dynamicly linked library in the Cura distributions, hence my assumption that CuraEngine is statically including parts of Arcus. But I can be all sorts of wrong about this.

Isn’t CuraEngine statically linked to libArcus, which is LGPL?

So a change in license for the CuraEngine is no longer going to happen?

I have not tested this, but upgrading NginX could be "as simple as" enabling developer mode, logging in to the printer as root/ultimaker over ssh, and running "apt update && apt upgrade nginx" (or nginx-light)

Slicing is currently done on multiple cores.

Ultimaker Cura 3.x has no manusl port selection (yet). The old Cura (15.x) did. It may still return in a future build, but USB printing has no priority for Ultimaker because it is not the officially supported way to print with Ultimaker printers.