ahoeben

Not really. Though running a post processing process on the gcode is exactly what the Postprocessing Script is for, the architecture of the Post Processing plugin is not ideally suited for how ArcWelder would like to process the gcode. ArcWelder wants to read a file and create a new processed file. At the point the Post Processing plugin runs, there is not yet a file to hand to ArcWelder; only gcode in memory, divided by layer. You could write the gcode into files for postprocessing, and read the result back in, and then finally write the result back out as a final file, but you can see how that is suboptimal. I think this is more suitably handled by a bespoke plugin that runs after all other postprocessing tasks have been run. That has the added benefit of being able to distribute said plugin via the Marketplace, including the required ArcWelder binaries for several platforms (Windows, OSX, Linux, Linux ARM). There is no way to distribute a postprocessing script other than "put this file in exactly this place, and this binary in this other place". I'll try this approach the coming week.

This is the wrong replacement pattern. Use this and Cura will not have to prepend its own preheat sequence for your extruder: M109 S{material_print_temperature} Similarly, include this to stop Cura from having to preheat the bed for you: M190 S{material_bed_temperature}

Not directly, no.

Your wish is my command In the example above, the left extruder causes the "Not Supported" state, and the right extruder causes slicing to be outright inhibited because the material and printcore type are not compatible.

AFAIK, it syncs the selected plugins and materials from the web-based Ultimaker Marketplace.

The Material Settings plugin from the Marketplace will let you specify which settings are visible in the Material preferences.

It seems that something has a "lock" on the file C:\Users\philu\AppData\Roaming\cura\stdout.log. Please try deleting that file.

A problem has been identified with the 4.8 beta on Big Sur. It will be fixed with the final release of Cura 4.8.0, which will likely be released next week. If you really want to run the beta on Big Sur, there are steps but they are somewhat involved.

To get the obvious question out of the way: Did you press the "Slice" button?

I'm far from an expert on building Cura from scratch. Truth be told, I've never done so. As far as I know, the AppRun executable should be in the AppDir that has been created. If all else fails, you could try extracting the AppRun file from an official AppImage.

You only get so see the orange warning when you open the self-closing configuration thing. Sidebar GUI plugin mitigates that by showing a warning icon on the extruder tab. Worth stealing for the mainline UI? Shall I make a PR for it?

Something went wrong. When I add an Ultimaker 3 Extended to Cura, I get the following list of profiles: Can you go to Help -> Show configuration folder and locate the cura.log in the folder that opens? Please upload that file somewhere and post a link here so we can have a look.

And the unreadable mess above translates to: if infill_sparse_density == 0 return 0 else if infill_pattern == 'grid': factor = 2 elif infill_pattern in ['triangles', 'trihexagon', 'cubic', 'cubicsubdiv']: factor = 3 elif infill_pattern in ['tetrahedral', 'quarter_cubic']: factor = 2 elif infill_pattern in ['cross', 'cross_3d']: factor = 1 else: factor = 1 return (infill_line_width * 100) / infill_sparse_density * factor

A new version of the plugin is available from the Marketplace, with full support for Cura 4.0-4.8. The sidebar can be collapsed to a summary for all of them.

All supports in a print, be they automatic or "print as support" manual, share the same settings.

Even if that would mean you can no longer run multiple versions of Cura side by side, or easily switch back to a previous version?

As a general rule, only settings that don't have children in fdmprinter.def.json are actually used by CuraEngine. All the other settings are used in formulas to feed into those "final"/leaf settings. For example the infill_line_distance gets calculated from the infill_sparse_density and the infill_pattern by Cura (from a python expression) and fed to CuraEngine "value": "0 if infill_sparse_density == 0 else (infill_line_width * 100) / infill_sparse_density * (2 if infill_pattern == 'grid' else (3 if infill_pattern == 'triangles' or infill_pattern == 'trihexagon' or infill_pattern == 'cubic' or infill_pattern == 'cubicsubdiv' else (2 if infill_pattern == 'tetrahedral' or infill_pattern == 'quarter_cubic' else (1 if infill_pattern == 'cross' or infill_pattern == 'cross_3d' else 1))))",

Exported profiles are technically binaries; they are zip archives containing multiple text files.

Hard to tell from just the screenshots. Can you save a project? File -> Save as...

This happens (in all versions of Cura) because the bottom is not 100% flat. You can either fix the model, or move it down a fraction (into the buildplate): use the move tool and set the Z to -0.1.

If you are worried about water getting in through the layers, you can also apply a coating to the print.

Whoops, you are quite right. I have replaced the link the the development snapshot above.

In the Machine Settings (Preferences -> Printers -> Machine Settings), make sure the Heated bed option is checked.

You meant the Custom Supports plugin then, not the Support Blocker. The Support Blocker comes with Cura, and cannot be updated from the Marketplace.

A beta version of the SidebarGUI plugin for Cura 4.8 (and older) can be found here: This new version makes the sidebar collapsible! 🚀