ahoeben

The plugin needs to be reviewed before it is published on the Marketplace. That normally takes between half a week and two weeks.

I think the best option is to use the ArcWelder plugin in Cura, and to deactivate it on OctoPrint. This has the benefit that the file gets processed on your (likely more powerful) computer that you slice with instead of the (slower) computer that OctoPrint runs on. There is no use in processing the file on both ends. Once @FormerLurker and I figure out a way to have the Cura OctoPrint connection plugin detect that processing of the file on OctoPrint is done I can make the plugin start the print automatically.

See Extensions -> Cura Backups -> Manage Backups

I have submitted an updated version of the plugin for inclusion in the Marketplace.

Unless you did a proper join / unioned / boolean operation in the application you used to merge the two models, the models are actually still separate and overlapping. Overlapping models confuse slicers. It is also possible that the basket is hollow and simply too thin to print.

Could you try entering 1,75, ie with a comma instead of a period?

Then next time, try water that is just 30 degrees. You can cut off a piece of filament and submerge it in the warm water. If it becomes malleable in the warm water, then so will your print.

Use the official AppImage instead of the package you use now. There is an incompatibility between Cura and the version of Qt on your system. The AppImage comes with a version of Qt that works.

Are you certain the water wasn't hotter than 50 degrees? Hot water can warp prints.

I do not mean to belittle Jos' strategic guidance in any way, but warm and friendly is certainly how I remember him from the year I worked at Ultimaker hq.

Even OpenGL does not get the 3d model you see, with volume added to the extrusion lines. That volume is added with a GPU shader, and cannot be captured.

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.