ahoeben

This should be fixed in the new development snapshot. Could you check?

Here's a new development snapshot, including the options added by @Cuq and the 1.0.0 release of @FormerLurker's commandline version of ArcWelder.

Also see https://github.com/Ultimaker/Cura/issues/8745

As far as I know, a plugin can define only a single tool and a single stage. What other plugin was that?

Do you use multiple displays? If so, try disabling all but one of them temporarily. If Cura starts succesfully with a single monitor, go to the General preferences and uncheck the "Restore window position on start". Then you can re-enable the other screens, and Cura should always open on your primary screen.

"x86" and ARM are very different. To put it in a somewhat limited analogy, even if they are both capable of doing math, they don't use the same notation. In other words, they speak different "languages".

The "normal linux cura" is built for x64 (Intel / AMD) processors. Installing the 64 bit Raspberry Pi OS does not change that the Raspberry Pi has an ARM processor, instead of an Intel / AMD processor.

Cura is not tested on Windows 7 anymore. Microsoft has stopped supporting that version, and so has Ultimaker. I don't think the amount of memory is the problem, but compatibility between Windows 7 and the Qt (the UI framework used in Cura) is a more likely culprit.

Thanks, but in this case the amazing work has been done by FormerLurker.

It is far more likely a bug in the tutorial. I have not checked the entire thing, but the first thing that strikes me is that they seem to be using Cura 3.6 and not telling you. Profiles have a way of saying what version of Cura they are for. The "setting_version" needs to match whatever the setting version is in the other profiles that come with the version of Cura you are running. For Cura 4.8, that setting_version needs to be 16, not 12.

Cura only shows those buttons for the "active" printer. You have multiple printers added to Cura, and only one of them is active. Use the "Activate" button in that dialog. By the way, there seems to be something fishy going on with your UI. The topbar has gone transparent. Did you create a theme for that, or should we try to diagnose that issue too?

The ArcWelder was originally conceived to reduce stutter resulting from buffer underruns while sending many small gcode moves over the USB connection. The protocol for printing over USB is rather inefficient, and if processing the transfer of a gcode command takes longer than actually doing the move then you get a stutter. Printing from SD does not suffer from this.

That is correct. Cura normally does not output G2/G3 gcodes (nor do any other popular slicers), so there is no need to visualize them. Now that there's an egg, I can work on the chicken.

I think that due to the way I created the package, the executable flag on the ArcWelder tool may be missing. I'll look in to that.

When discussing results, it helps to include what printer you use, how you print (via USB or SD), and if you have customised the electronics or firmware at all.

The current version does not, but FormerLurker is working on a version of the ArcWelder tool that does.

This is getting "a bit" offtopic. The realworld benefits of converting multiple G0/G1 movements into fitted G2/G3 arcs are being explored and tested here: https://community.octoprint.org/t/new-plugin-anti-stutter-need-testers/18077 The creator of the original plugin for OctoPrint has also created a command-line tool to postprocess gcode. As I have said before, the post processing plugin is not ideally suited to launch external binaries, so I am working on a plugin. That plugin can be discussed here:

I'm working on a plugin that wraps FormerLurker's command line version of the ArcWelder plugin originally developed for OctoPrint. The plugin attempts to reduce stutter by simplifying gcode. It analyses subsequent G0 or G1 movements that make up arcs and replaces these sequences with G2 or G3 lines. Gcode containing these arcs may or may not print well on your printer, depending on the type of controller and the configuration of the firmware. For more information about ArcWelder, read the description of the original plugin, and the discussion of realworld results. Gcode before and after GCode processing by Arc Welder. The image above is gcode created with PrusaSlicer with and visualized with ncviewer. Image by FormerLurker An early development version of the plugin for Cura 4.4 and later can be downloaded here: Cura-ArcWelderPlugin Cura-ArcWelderPlugin (once available from the Marketplace, the plugin will be compatible with Cura 3.5 and newer). You can install it by dropping the file onto the Cura buildplate as if you were opening a 3d model. The plugin adds settings to the "Special Modes" category. You can easily find these settings by typing `Arc Welder` in the search field on top of the Custom settings panel. The plugin has not had extensive testing, and is fairly barebones at the moment. I have not personally tested printing with curve commands yet. When discussing results, it helps to include what printer you use, how you print (via USB or SD), and if you have customised the electronics or firmware at all. Edit: updated link to newer development snapshot Edit 2: the plugin is now available from the Ultimaker Marketplace; no need to manually install development snapshots.

This is a bit more readable version of the same file: http://files.fieldofview.com/cura/Replacement_Patterns.html

For showing the settings in the Print Settings on the Materials pane of the preferences, I recommend using my Material Settings plugin. That requires even more "illegal" hacking to "copy" into your own plugin and it will be hard to make something that can be run side-by-side with that plugin.

And Cura-ZOffsetPlugin too, though the Linear Advance one is a bit nicer because it uses a "familiar" json file instead of a dict. Note that the method I use in both plugins is not officially sanctioned. There is some "illegal" access to "private" variables, and it is a bit of a magic incantation that seems to work. It might break at any Cura update, though the method of adding settings has been fairly stable so far. I did my best to document how it works.

Out of the three, this one is a fairly bad idea. You would have to do it over and over when you install a new version of Cura, whereas the other two will carry over (as long as you don't uninstall your settings when installing a new version of Cura).

You meant this list: http://files.fieldofview.com/cura/Replacement_Patterns.html

It could be that the gpu does not support the required functionality, in which case there is nothing a driver can do to fix this.

That's not enirely true. You can load image files (jpg) into Cura, and they will be converted into a 3d relief, also known as a lithophane: https://www.google.com/search?hl=en&ei=6w-xX8_LJITpsAf0h7WQAw&q=lithophane+cura