ahoeben

It is the correct setting *if you want to print over USB*.

You get full control over all material properties in Cura, instead of having some in Cura and some on the printer.

A lot changed between Cura 3.2 and Cura 3.3: https://github.com/Ultimaker/Cura/compare/3.2...3.3#diff-1ffa6abbfcca423f5309011d0cce73ee Specifically for your plugin, moveHead (and other jogging functionality) was moved from the outputdevice to a "controller". Best you can do is look again at the Ultimaker BedLevelMachineAction and see how it has changed. https://github.com/Ultimaker/Cura/blob/3.3/plugins/UltimakerMachineActions/BedLevelMachineAction.py So for example, instead of calling moveHead on printer_output_devices[0] you have to call it on printer_output_devices[0].activePrinter. There may be other changes required. Making plugins requires ongoing work to keep up with changes in Cura.

If you want to do printing over USB with a UM2Go, make sure you set the GCode flavor to "Marlin" instead of "Ultimaker 2". This can be found in Machine Settings.

Looks like the bottom is not flat.

Because you use old, deprecated replacement patterns. Use “material_bed_temperature” instead of “print_bed_temperature”, and “material_print_temperature” instead of “print_temperature”.

The next major version looks like it will have native file dialogs on all platforms again.

As a workaround, use the cursor-keys to navigate through the menus. We haven't quite figured out why this happens on some systems, but there's a good chance it will finally be fixed in the next release because the UI framework that's used in Cura is upgraded to a much newer version.

3.4 has the same issue. I have submitted a fix, but it won’t be included until the next major version. As a workaround, make sure you press enter after editing the jobname, or click in any textfield in the sidebar.

Check the logs. Do you get errors? What do the errors say?

Check the logs. They should tell you what went wrong. Cura changes from version to version. That means you can't always use the same code in plugins between versions. Such is life.

"default_value always" needs to be a literal (ie: a numeric value for a setting that expects a number, and a string ONLY when the setting expects a string vaue). "value" should always be a string that can be interpreted by python. The string can contain a number, or a calculation, or another string, and any pythonically valid combination thereof. By that logic, only "value" can hold any sort of manipulation and/or calculation. This should work: "machine_start_gcode": { "value": "'G29 P' + str(int(machine_width/25))" }, 'G29 P' is a string in the python expression. The whole expression is enclosed as a string.

Cool! Do you need to set the flow to 50%?

Psst! @nallath, that functionality has not yet been pushed to the public. Or has it? Either way, it does not contain profiles for Colorfabb and PETg.

Hmm, strange. It did fix the issue for me. So there may be an additional issue. Could you describe what you do exactly to make it *not* work? The following steps resulted in the wrong filename for me before the patch, but in the correct filename after the fix. * Load a model * Click on the jobname and edit it * Do not press Enter when done, do not click any other text entry field when done * Press Save to File

Could you help test a fix for me? You have to edit resources/qml/SaveButton.qml: https://github.com/Ultimaker/Cura/blob/3.4/resources/qml/SaveButton.qml#L259 Around line 259, add the command forceActiveFocus(), like so: onClicked: { forceActiveFocus() UM.OutputDeviceManager.requestWriteToDevice(UM.OutputDev[...] } Note that I have shortened the line that starts with UM.OutputDeviceManager, because the forum would mangle the formatting otherwise. Please leave that line as is. If that works for you, I will submit a PR so it gets included in the next version. Update: See https://github.com/Ultimaker/Cura/pull/4057/files

You can download the cloud-based settings backup here: https://api.ultimaker.com/cura-packages/v1/cura/v4/packages/CuraDrive/download Drop the resulting file into the Cura window and restart Cura. It could be interesting to know if the plugin works even if the Toolbox does not.

Are you by chance using a 32 bit version of Windows 10? Cura needs the 64 bit version of Windows.

I have not tested this, but I think you can edit your extruder definition (or definition_changes config) to include machine_extruder_end_pos_abs, machine_extruder_end_pos_x and machine_extruder_end_pos_y. https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmextruder.def.json#L135

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 ?