ahoeben

No, that is not correct. There is no automatic piping of anything. The order of mimetypes just specifies what MeshWriter plugin is preferred for that printer. Only one MeshWriter gets called by Cura, but a MeshWriter might call other meshwriters. I'm sorry, I don't have time to hold your hand on this at the moment.

Do you want to write multiple files at once (ie: a thumbnail and a gcode file in two separate files)? That is not something the MeshWriter supports easily. You would have to build that yourself.

Yes, unless you specify your printer prefers using the mimetype specified in the UFPwriter plugin, like so: "file_formats": "application/x-ufp;text/x-gcode" Note how application/x-ufp is in front of text/x-gcode

Ok, then have a look at the UFPWriter as an example instead.

If you still want to go the MeshWriter route, I would suggest you take the GCodeGzWriter as an example/starting point: https://github.com/Ultimaker/Cura/tree/master/plugins/GCodeGzWriter https://github.com/Ultimaker/Cura/blob/master/plugins/GCodeGzWriter/GCodeGzWriter.py shows how to let the GCodeWriter to actually create the gcode file string, which you can then modify before you write it to the output stream.

> if printer is a tronxy, the g-code should be created, that g-code hat to be modified by my plugin. What sort of modifications are you talking about? Does the modified gcode file have to be named *.chitu? If not, it is easier/less confusing for the user to not use a meshwriter, but use something that simply post-processes the gcode when it is written.

It does not say "machine_id", it says "machine ID". See the line that says "machine": "tronxy_base_extruder". This refers to a file named "tronxy_base_extruder.def.json", which apparently does not exist. It is supposed to be the id of the machine definition (I'm just guessing, "tronxy_base"?).

File -> Export should allow you to at least try to export as a .chitu file (Save as type). That is, unless ChituCodeWriter fails to import. If ChituCodeWriter fails to import, that should be visible in the logs.

Your __init__.py needs a bit more (some imports and a register() function), but generally, yes: that is it.

One more time. Slow. Ultimaker depends on community members to make profiles for 3rd party printers. Since you are not even saying what printer you use, and you seem to be unwilling to even help test changes to be made to Cura so they are included in the next version, I am afraid you are going to be using Cura 4.4.1 for a while.

1. This is a known bug that has been fixed for Cura 4.6 2. This I did not know about, and will look in to.

Cura only shows that warning if you install the MeshTools plugin from the Marketplace.

I would say the problem is in the model. Fusion 360 normally exports good models though. Perhaps if you share the model I or someone else can have a look at it and see what is wrong about it.

@WardXmodem, the post you responded to is 8 years old. It referred to a totally different Cura.

The model is probably non-manifold/“broken”. It needs to be repaired before it can be properly printed. Cura has an “Xray view”, hidden away on the Preview tab, which could show you (in red) where the problem is.

If you want to be able to select materials for the Ultimaker 2 in Cura, you have to go to Machine Settings and change the GCode FLavor to "Marlin".

What do you want to modify in the Gcode? It could be possible to do the edit automatically with for example a search and replace gcode postprocessing script (see the Extensions menu). Or if it is part of the start or end gcode, you could edit those snippets in the Machine Settings dialog. There is no generic text editor in Cura to edit gcode.

Red or orange? If orange, Cura should still slice ok. Red is an error, which blocks slicing. Orange is a warning, and warnings are not blocking. If you want to be rid of the orange warning, you also have to increase the "maximum_value_warning": "default_material_print_temperature": { "maximum_value_warning": "400", "maximum_value": "450" }, "material_print_temperature": { "maximum_value_warning": "400", "maximum_value": "450" }, "material_print_temperature_layer_0": { "maximum_value_warning": "400", "maximum_value": "450" }, "material_initial_print_temperature": { "maximum_value_warning": "400", "maximum_value": "450" }, "material_final_print_temperature": { "maximum_value_warning": "400", "maximum_value": "450" }, "material_standby_temperature": { "maximum_value_warning": "400", "maximum_value": "450" }, Unfortunately, the dinky definition you uploaded is rather incomplete, so I cannot test with that.

I don't think so. The red parts are not an indication of what *needs* support, but of what will *get* support wth the current support overhang angle. But it does not take into account the "support placement" setting. It really is just an indication; not an error or warning that the world will explode if you try to print this without supports. Common sense is more important than the red indication here.

There is this: https://github.com/CadQuery/CQ-editor

Since the contact surface at the bottom is fairly small compared to the size of the model, supports might help or even be necessary to keep the model attached to the buildplate.

.

Only the user settings though, NOT the settings specified in the machine definition

The biggest change for the CR-10 in Cura was that in Cura 4.3 (or was it 4.2?) the Creawsome mod definitions were chosen as the basis for all Creality printers.

No. A normal gcode file does not contain all the settings, only the results of using all settings. So unfortunately, gcode files are the wrong place to look at. I can imaging a plugin that exports a flattened version of the settings "stack" that Cura uses for printing, which would work on both Cura 3.6 and Cura 4.5. Two exports, one from each version, could then be compared/"diffed". But I doubt that it would take only a few minutes, especially when taking into account multiple extruders (which a Cura dev would have to do). I've written my fair share of plugins for Cura. I think it would be quicker to manually compare the definition files for the printer between versions: This is 3.6: https://github.com/Ultimaker/Cura/blob/3.6/resources/definitions/creality_cr10.def.json#L16 For 4.5, the values are mostly set here: https://github.com/Ultimaker/Cura/blob/4.5/resources/definitions/creality_base.def.json#L126