ahoeben

To elaborate on this a little more, I recommend you use OctoPrint. You can install multiple instances of OctoPrint on the same (multitasking) Linux system; one for each printer. Then use the Cura Octoprint Connection plugin to send prints to these. Disable (and forget about) the USB Printing plugin in Cura. This way you have the famous separation of concerns; Cura deals with slicing, and OctoPrint deals with serving the gcode to the printer; one process per printer. If one process dies for some reason, it does not take down all others too. Disclaimer: I'm the creator of the OctoPrint Connection plugin. It is not maintained by Ultimaker, since (recent) Ultimaker printers don't support printing via USB.

Many profiles made by manufacturers say "just use the default settings". https://github.com/Ultimaker/Cura/blob/master/resources/definitions/SV01.def.json#L11 https://github.com/Ultimaker/Cura/blob/master/resources/definitions/mp_mini_delta.def.json#L11 https://github.com/Ultimaker/Cura/blob/master/resources/definitions/jgaurora_a5.def.json (does not specify "has_machine_quality" as true, so it is set to false) https://github.com/Ultimaker/Cura/blob/master/resources/definitions/anycubic_chiron.def.json#L15 Only the Chiron specifies it has unique profiles. The rest all use the same default profiles, andas a result share your custom profiles among them too.

That is not true. Ultimaker Cura fully supports multiple extruders. In your start- and end-snippets, you can use the following syntax: {material_print_temperature, 0} # first extruder print temperature {material_standby_temperature, 1} # second extruder standby temperature You can even use replacement patterns to specify the extruder: {material_print_temperature, adhesion_extruder_nr} # the print temperature of whichever extruder is configured to print the skirt/brim/raft {material_standby_temperature, support_extruder_nr} # the standby temperature of whichever extruder is configured to print the supports

You have to press the "Slice" button in the lower right.

No, there is not. It really depends on which printers you have added in Cura. Typically printers that come with their own set of quality profiles get the individual user-created profiles too. Printers that basically only define the platform size and use the default set of profiles all share the same user-created profiles.

Yes, it can. Will it be addressed? Not by Ultimaker. Ultimaker has no interest in improving the USB printing in Cura, since no currently shipping Ultimaker printers support printing via USB.

I think SuperSlicer can make an STL out of a gcode file by exporting "pipes" for the toolpath. In theory, I could make a plugin that does the same for Cura, but frankly I don't see enough of a usecase other than "greens83 want it and thinks it is really important".

If you look carefully at this image (that you posted yourself), you can also see that there is an issue with the normals. Looking at the small section between the tail and the head of the cat from below, you see that you are looking "through" the wall as if it did not exist, and then instead you see the insides of the wall. It looks asif you are staring into a box, as it were. This is due to what is called "backface culling"; the application that made this image did not draw the "back" of the faces. Since all the faces are "inverted", only the "insides" of the walls get drawn.

The problem is that the model has conflicting "normals". The top of the model (the "walls") has the normals facing outward, the bottom (the modeled "brim") has the normals facing inward. This confuses Cura. You can sort of see this because the top section has a red "overhang" indication on top, instead of on the bottom. The easiest fix is to download the Mesh Tools plugin from the marketplace (if you don't have it already), select the model and right-click. Then select Mesh Tools -> Fix model normals. After that the model will slice properly.

This is correct; ArcWelder can not change the z seam. It just converts multiple consecutive G0/G1 moves to arc. Anything that would create a "seam" would also break the arc.

If by "preset" you mean a "profile", then that is how it is supposed to work. Profiles are shared between "similar" printers. There is no changing that. The difference between what I said before and what you are seeing is that as long as you don't commit the setting differences in a profile, the "current settings" are the unique per printer. But as soon as you put the setting value in a profile, that profile is the same between those 5 printers. Apparently your 6th printer is different enough that it has its own set of profiles. However if you add another one of those type of printers, they too will share a set of profiles.

To clarify this a bit: Cura does not understand the G2/G3 Arc movements that are inserted by the ArcWelder plugin. The normal preview is not affected by this; in the normal preview, Cura just shows the original linear moves. The Arcs are only getting Welded when saving the gcode file. When you load the gcode back in, Cura will have a problem visualizing the moves.

There are subtle differences. You can't just change the scale of a printer and expect it to print exactly the same. For example the bed of an S5 is understandably heavier than the bed of an S3. So the speed at which you can move the z axis up and down without introducing a wobble in the printer is different. The same with the print-head; though (I think) the axles have the same diameter, you can imagine that the S5 axles have a slightly higher tendency to sag and introduce vibrations at high speeds. That is why there are tuned profiles for all combinations of printers, cores and materials with sometimes very subtle differences. Though often the differences are negligible, you would then start to have to make a list of what type of difference between prepared prints is and is not acceptable, and it just becomes easier (and more reliable!) to say "no, a print prepared for one printer will not work on another printer".

Can you elaborate on that? I assume you Added a new printer 6 times, so you have 6 printers in the printer selection dropdown (normally on the left of the top bar)? What could happen is that a profile you create for one printer is also available for the other printers. What should not happen is that when you change eg the infill percentage on one printer, that all the other printers change the infill percentage too.

The model looks manifold indeed. That's why I said "in most cases", not "in all cases". If you save the model from Cura with File -> Save project... it also saves all your settings and I can have a look at those. Some settings can also cause this.

Here's a neat list of replacement patterns you can use in the start gcode: http://files.fieldofview.com/cura/Replacement_Patterns.html Specifically, here's the ones for the materials: {material_id} The id of the material (eg 'ultimaker_pla_blue') {material_type} The type of material (eg 'PLA') {material_name} The display name of the material (eg 'Blue PLA' {material_brand} The brand of the material (eg 'Ultimaker') If you don't want to use replacement patterns in the start gcode, here's how they are defined in code: https://github.com/Ultimaker/Cura/blob/master/plugins/CuraEngineBackend/StartSliceJob.py#L359-L363

Better yet, share a project saved with File -> Save project... That way get get the model and all the settings you use.

In most cases, it is non-manifold models. https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/troubleshooting/missing_parts.md#non-manifold-meshes

Wrong guess. I make sure that all my plugins can be used with as wide a range of versions as possible. Many of them are still compatible with Cura 3.5. I think it is more that the Marketplace dialog is a pain in the ass (it takes more than a minute to open on my computer), and syncing a selection of plugins via the Marketplace website does not always work. It looks like the Marketplace dialog is getting replaced by something entirely new for the next version of Cura, so that's something.

No, they should not have. The 4.13.0 AppImage is still available here: https://github.com/Ultimaker/Cura/releases/tag/4.13.0 You can have them both side by side. If the 4.13.0 AppImage still launches without a problem, then something went wrong when building the 4.13.1 AppImage. Just to be sure, @nallath, was the Linux build-system changed/updated between 4.13.0 and 4.13.1?

Every time? The logs show you loaded a model and moved it around and slicing it a couple of times last night. Did the crashes start to happen before or after that?

Cool, though honestly I question if trying to get the most out of a 6 DoF 3D printer with tricks like this is not at least as much work as writing a true multiplanar slicer from existing research. I would say it would make a nice PhD project.

elaborate

No, not out of the box. CuraEngine, the actual slicer that does the calculations, only supports slicing perpendicular to the buildplate. Theoretically? Yes. The frontend Cura is very modular. Even the CuraEngine backend is a plugin in Cura. CuraEngine itself is not as modularly built, and does not have a plugin concept. So you would need a (fair) piece of code that does what CuraEngine does, but allows multiple slicing directions. Then a plugin could send the model to that bespoke piece of code. This piece of code could be based on Slicer4RTN. Realistically though I would say this would be fairly tricky to implement. NB: I have made a version of Cura that slices for belt-style printers (Blackbelt Cura). By jumping through lots of hoops, I managed to use the regular CuraEngine for that. But I don't see how that could easily work for true non-planar slicing.

We also need to know more about the model, your settings, and how printing failed. The image you posted came across rather small, so it is hard to see. For the model and settings, the easiest way to make those insightful is to save a project file with File -> Save project, and post a link to it here.