ahoeben

I am sorry, due to the GDPR we are no longer allowed to use the mindreader technology that is built in to Cura to figure out what you mean. So you'll have to clarify a bit. I assume that you don't mean Youtube or Vimeo? What sort of videos?

It is also frustrating trying to help you when you don't answer simple questions.

So, where did you put those files then? The print() in getMetaData() works for me. But since getMetaData() returns {} (because there is no ChituCodeWriter), register() never gets called. How do you run Cura? print() statements are not logged. They show up if you run Cura from source, but don't end up in cura.log. If you want entries in cura.log, use UM.Logger.Logger.log() instead.

Do you have a plugin.json? I don't think the plugin is loaded unless there is a plugin.json file with the appropriate data in it.

Not without either the full code you use (and where you put it) or a link to your cura.log

MeshTools also has an option to "fix" the normals. In case of flipped normals it unflips them. I am considering making it an option to always fix normals on import, but that may slow down loading huge models.

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.