This seems to be a bug in the slicer. I’m seeing the same issue in OrcaSlicer if the skirt height is set to more than one layer (even if the skirt is disabled). This makes sense if a skirt is used (can’t print a continuous spiral if you have to switch between printing the object and the skirt), but not if it’s disabled.

What slicer are you using? If it’s a PrusaSlicer fork, this is likely the same bug.

My router is called Jupiter, everything connected to it is named after a moon. Callisto, Ganymede, Thelxinoe, Kallichore are what I’m currently using.

You can host a Firefox sync server yourself. You could run that on something like a Raspberry Pi in your local network. If you need remote access, use something like cloudflare tunnels (although I guess that’s something else to be paranoid about).

For quick, uncomplicated parts, SolveSpace works pretty well. It’s missing some features (like chamfers) that limit the kind of parts you can design, but it’s lightweight and relatively easy to use.

For everything beyond that, FreeCAD seems to be the only option (Or one of its forks, I find Ondsel easier to use). It has some issues and a pretty steep learning curve, but it is open source and you can design basically anything with it.

That’s why I don’t let every device decide individually. I know my router (FritzBox) prioritizes the pi-hole (it’s even called “preferred” and “alternative” DNS-Server in the UI)

I have my pi-hole setup as the upstream DNS in my router, with cloudflare as a secondary DNS. That way, all my devices always use the router for DNS (since that’s what is advertised in my DHCP) and the router then uses pi-hole if it’s available, or cloudflare if it isn’t. But the individual device doesn’t get to choose between different servers.

Tightening the belts seems to have helped, but I will have to do some more printing to be sure. Thanks for your help!

The belts are parallel to the axis, but I will try tightening them some more.

This is a 40x40 cube printed in vase mode:

The corners look pretty okay on that:

But I don’t see these kind of results on real-world parts. I guess I have to print some more test parts to narrow down the problem.

That might be part of it, my filament is probably pretty wet. I’ll try some other rolls of filament.

The part is just pretty small, I have the EW set to 0.45 mm withe 0.4 nozzle. But I will try turning it down further.

The rounding looks much more extreme than what I would expect or have seen on other printers I worked with (mostly Ultimakers).

It’s a printer of my own design running marlin. I’m going to try disabling input shaping, but if I remember correctly the problem was already there before I ever enabled it.

Good point, see my edit

I’m guessing it’s about documenting the assembly of safety-critical components. If some part of, let’s say an airplane fails because a bolt comes loose, the manufacturer wants to have a paper trail attached to it to prove that this specific bolt was indeed torqued to the correct spec. Connecting the wrench to the network could make this documentation much easier.

You can try to disable software End-Stops with this gcode:

M211 S0

Be aware though, if you do that, there is nothing preventing your printer from trying to move beyond the hardware limits and possibly destroying itself. You can enable the end-stops again with:

M211 S1

Marlin reference page

Solvespace might be exactly what you’re looking for. It is FOSS and works well for simple models. Some functionality is missing though, for example chamfers and fillets.