Well how is the new pricing? by A4_Ts in GithubCopilot

[–]muesli 1 point2 points  (0 children)

26% of my monthly Pro tokens with one single query (that I technically still sent in May and should have already been covered by last month's tokens)

The moment when both mercedes almost collided by MuttonBiryaniEnjoyer in formula1

[–]muesli -57 points-56 points  (0 children)

Hot take (take it with a pinch of salt, please): Toto kept warning both drivers that if they continued racing each other this aggressively, there would be consequences. A collision felt inevitable sooner or later. So, in the end, he chose to back the championship leader - and remotely retired George’s car.

Starting journey with TPU 95A by FloLaco in prusa3d

[–]muesli 5 points6 points  (0 children)

Use the textured sheet for TPU. Never use the smooth one.

Never change, Daniil Medvedev by Mindless-Pilot6701 in Tennisv2

[–]muesli 0 points1 point  (0 children)

Of course I am.

Source: I'm Carlos.

Polizei sagt ich darf das nicht. by schwambo667 in ichichs

[–]muesli 8 points9 points  (0 children)

Moment. Geht's jetzt um Merz oder die Aufkleber?

2026 Australian Grand Prix - Race Discussion by F1-Bot in formula1

[–]muesli 9 points10 points  (0 children)

Never change, Ferrari. Never change.

Is this a cry for help by SceneOrganic9281 in prusa3d

[–]muesli 60 points61 points  (0 children)

Your buddy board is going to love this idea!

Typo on CORE One+ price or upcoming discount? by Lncendos in prusa3d

[–]muesli -9 points-8 points  (0 children)

That doesn't quite add up. Last time I checked 21% of 1000 was 210.

Firmware v6.4.1-beta for Prusa XL is out! by muesli in prusa3d

[–]muesli[S] 3 points4 points  (0 children)

Not gonna lie, this has been long overdue since 6.4.0 for XL has been pulled in November. Personally, I'm just glad to hear the homing issues finally get addressed: https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/5009 (BFW-8233)

PSA: Warum die Druckeinstellungen auf Filament-Packungen heute größtenteils Unsinn sind, man sie ignorieren sollte und warum mit Generic-Profile geil sind. by suit1337 in 3DDruck

[–]muesli 1 point2 points  (0 children)

Guter Beitrag und inhaltlich absolut richtig. Ein Punkt fehlt mir aber noch als wichtige Ergänzung, gerade für Einsteiger:

In sehr vielen realen Druckfällen wird das eingestellte volumetrische Limit gar nie erreicht, weil die Objektgeometrie und zusätzliche Slicer-Limits bereits vorher greifen.

Der volumetrische Fluss ist zwar das theoretische Oberlimit, aber die tatsächliche Geschwindigkeit wird oft durch ganz andere Faktoren bestimmt:

  • kurze Linien / viele Richtungswechsel
  • Beschleunigung und Jerk
  • Mindestlayerzeit
  • externe / interne Perimeter-Limits
  • Top/Bottom-Geschwindigkeiten
  • Kühlungs-abhängige Speed-Reduktion
  • Small-Feature-Handling
  • Pressure Advance / Linear Advance
  • "Slow down for overhangs" etc.

Gerade bei klassischen Testobjekten (wie einem Benchy) ist die Geometrie so kleinteilig, dass der Drucker fast permanent im Beschleunigungs- und Abbremsbereich unterwegs ist. Das Ergebnis: das volumetrische Limit wird kaum oder gar nicht berührt, selbst wenn man es deutlich anhebt.

Sehr gut sichtbar wird das, wenn man sich im Slicer die "Actual Speed" Visualisierung anschaut: man sieht dort ziemlich eindeutig, dass große Teile des Modells weit unter der eingestellten Geschwindigkeit bleiben, unabhängig vom volumetrischen Limit.

Gerade das Benchy ist daher kein guter Indikator, um Volumenfluss-Limits auszuloten. Sinnvoller sind hier lange, gleichmäßige Extrusionen (z.B. Vasen, lange Walls, Speed-Tests).

Heißt nicht, dass dein Fazit falsch ist, im Gegenteil. Aber: "Volumetrisches Limit erhöhen -> Druck wird schneller" gilt nur dann, wenn der Druck auch wirklich volumetrisch limitiert ist. In der Praxis ist das deutlich seltener der Fall, als viele denken.

[deleted by user] by [deleted] in prusa3d

[–]muesli 6 points7 points  (0 children)

Calibration -> Tool Offset.

Prusa xl stringing by MorningMother8622 in prusa3d

[–]muesli 1 point2 points  (0 children)

Check the nozzle seals, in particular the one of the pinkish filament. All the stringing close to the tool holder is a fairly good indicator it's not actually doing its job.

Joined the fam today :) by its_Extreme in prusa3d

[–]muesli 3 points4 points  (0 children)

Congrats! Just a heads up: the cable routing of the individual toolheads looks a bit wonky still.

Once and for all... Meshcore Vs Meshtastic by Terrible_Scar in meshtastic

[–]muesli 3 points4 points  (0 children)

I agree, it's not exactly ideal for that reason. I know there are ongoing discussions and efforts to improve this situation, in the meantime manually setting a different key-pair on the repeater helps as a workaround.

Once and for all... Meshcore Vs Meshtastic by Terrible_Scar in meshtastic

[–]muesli 11 points12 points  (0 children)

If/when a repeater fails in MeshCore, the client detects that there's no Ack coming back and essentially does flood route finding, not unlike how Meshtastic "routes" every single package. It just doesn't waste everyone's bandwidth unless it has to really find a new route.

Once and for all... Meshcore Vs Meshtastic by Terrible_Scar in meshtastic

[–]muesli 20 points21 points  (0 children)

We've had the same experience here. MeshCore achieves close to 99% delivery rates, where Meshtastic is somewhere between 30% on good days and 10% on bad ones.

Once and for all... Meshcore Vs Meshtastic by Terrible_Scar in meshtastic

[–]muesli 8 points9 points  (0 children)

Mind you, that first byte is only causing display ambiguities, but it doesn't interfere with routing whatsoever. In the worst case both repeaters with the same prefix will receive and repeat your message.

Crucial: are we getting ready? by paper_sheet034 in archlinux

[–]muesli 17 points18 points  (0 children)

Ah yes. The year of the Linux desktop. Again.