Seite 1 von 1

Bauraum des RF1000 und Unzulänglichkeiten einiger Slicer

Verfasst: Mo 3. Jan 2022, 18:34
von rf1k_mjh11
Als ich diesen Beitrag las, kam mir die Idee zu diesem Thread, besonders als Reaktion auf dieses Zitat:
AtlonXP hat geschrieben:Der RF1000 hat einen echten Fahrweg von 245 x 245 x 200 mm.
...
Wenn du dir genau deine Druckplatte anschaust und die Stellung deines Hot End,
dann wirst du feststellen, dass das nicht der echte Bauraum sein kann.
Der 'echte' Bauraum beim RF1000 und RF2000, also das Volumen, dass ein Druckobjekt einnehmen könnte, sieht so aus:
BuildVolume.jpg
Hinweis: Der Bauraum des RF2000 sieht gleich aus, bloß ändert sich der X-Wert, je nachdem ob es sich um ein Single- oder Dual-System handelt.

Unbestritten ist, dass die nutzbare Bettfläche kleiner ist als die für den Drucker angegebenen 245x245mm. Aber von den möglichen Fahrwegen der X-, Y- und Z-Schrittmotoren ergibt sich ein Bauraum wie im Bild. Beschränkt man sich nur auf das Volumen oberhalb des Druckbetts, schenkt man mehr als ein dreiviertel Liter Bauraum ein!!! (So zwischen 1.7x24.5x20=833cm³ und 2x24.5x20=980cm³, je nachdem, wie weit das Bett vorne frei steht.)

Ich habe ein Druckobjekt konstruiert, dass auf dem oberen Bild basiert und somit den vollen Bauraum ausfüllt und so aussieht:
TestPartUtilizingFullBuildVolume_.jpg
Interessanterweise agieren die diversen Slicer mit ebenso unterschiedlichen Reaktionen auf so ein Druckobjekt.
Gut möglich, dass ich nicht alle Tricks der Slicer kenne, um die mir dabei aufgestellten Hürden auszuweichen.

Bei jedem Slicer wurde das Druckobjekt innerhalb des Bauraums positioniert, wobei jeweils der erste Layer zu 100% auf dem Druckbett zu liegen kam.

Hier die Reaktionen der Slicer:

Slic3r (v1.2.9):
Slic3r erlaubt die Eingabe eines Offsets für das Druckbett. Damit kann man die 17 bis 20mm, die beim RF1000 vorne 'leerbleiben', einstellen. Die Einstellung heißt 'Origin'. Bei mir steht dort bei 'Y' '-17mm' (das hängt von der Einstellung der Y-Endanschlagsschraube ab, andere werden vielleicht andere Werte stehen haben). Mit der Einstellung wird das Druckbett realitätsnah so dargestellt, dass man ein Druckobjekt nicht versehentlich außerhalb des Druckbetts platziert. Anders gesagt, der X=0, Y=0 Punkt liegt damit vor dem Bett, wie es auch wirklich ist. Mit der Origin-Einstellung von '-17mm' muss man andererseits als Y Wert für die Größe nicht 245mm, sondern 245-17=228mm angeben. Bei mir steht dort 227.70mm damit das Druckbett 0.3mm vor der mechanischen Kollision stehen bleibt. Slic3r zeigt also optisch, wo das Druckbett endet.
Slic3r meckert nicht, wenn das Druckobjekt außerhalb des Bauraums zu liegen kommt und sliced anstandslos. Auch eine eventuell vorhandene Hutkrempe oder Schürze wird generiert, ob diese im Bauraum liegen oder nicht. Damit liegt die Verantwortung für diese zwei Elemente (Skirt und Brim) beim User. Aber, vorausgesetzt man positioniert das Druckobjekt korrekt und schaltet Brim und Skirt aus, bekommt man vom Drucker ausführbaren GCode, dass den gesamten Bauraum ausnutzt. In Slic3r sieht es dann so aus:
With_Slic3r_v1,29.jpg
Man beachte die Schürze (in grün), die mittels 'Siemens Lufthaken' in Position gehalten wird. :ohmy:

Prusa Slicer (v2.3.0):
Baut eigentlich auf Slic3r auf. Man sollte daher ein ähnliches Verhalten erwarten. Man wird allerdings überrascht.
Man kann auch hier ein Offset angeben, damit die Bettkante dort ist, wo sie auch wirklich ist. Mit der Einstellung gibt es aber beim slicen Probleme.
Prusa Slicer verweigert die Erstellung von GCode mit der Meldung, in etwa: "ein Objekt außerhalb des Bauraums wurde erkannt, man möge das beheben". Prusa Slicer hebt auch die störenden Bereiche farblich hervor (im Bild dunkelblau). Ist auch nur ein kleiner Teil eines Druckobjekts außerhalb des 'Druckbereichs', wird das ganze Objekt blau dargestellt. Andere Objekte, deren Platzierung in Ordnung ist, werden nicht farblich hervorgehoben und bleiben (bei mir) grau, bzw. falls angewählt, grün. Sieht man im folgenden Bild:
With_PrusaSlicer_a_v2,3,0.jpg
Ich ging sogar so weit, dass ich Skirt und Brim deaktivierte und den Bauraum um 2mm in jede Richtung erweiterte. Trotzdem war kein slicen möglich.
Persönlich glaube ich hier an einen Bug. Die Entwickler werden sicherlich der Meinung sein, dem User mit dem demonstrierten Verhalten einen Gefallen zu tun. Damit kann verhindert werden, dass ein User sein Druckobjekt nicht am Druckbett, sondern im Nachbarort positioniert (was in Slic3r möglich wäre). Schließlich sind jene vom Nachbarort gar nicht am Druckergebnis interessiert :stinkt: . (Wie so oft in Software, hat ein Zuviel an Hilfe oft versteckte Nachteile - ich denke da zum Beispiel an Clippy (=Karl Klammer) in einer bekannten Textverarbeitung.)
Ich habe auf GitHub ein Request bezüglich dem Verhalten von Prusa Slicer eröffnet (#7677), man wird sehen, ob sich da was tut.

Cura (4.0.0):
In Cura kann man keinen Offset angeben (ich schaffte es zumindest nicht). Das ist nicht unbedingr verwunderlich, schließlich wurde Cura für den Ultimaker entwickelt - der Drucker kennt keinerlei Offsets.
Ohne einen Offset angeben zu können, bleibt die Verantwortung beim User, dass er das Druckobjekt nicht zu knapp vorne platziert. Hilfe wird dem User in dieser Hinsicht keine geboten. Aber das Druckobjekt ließ sich slicen, wie im Bild ersichtlich:
With_Cura_v4,0,0.jpg
Craftware (v1.20):
Craftware war das letzte Programm, dass ich testete. Craftware erlaubt die Angabe eines Offsets. Ähnlich wie Prusa Slicer, hebt Craftware vorstehende Bereiche farblich hervor, in einem warnenden rot-Ton, damit es ja nicht übersehen wird:
With_Craftware_v1,20(2).jpg
Anders als Prusa Slicer, klappt das Slicen sehr wohl. Das Ergebnis wird jedoch mit einer Warnung begleitet, die besagt, der generierte GCode wäre außerhalb des Arbeitsbereichs:
With_Craftware_v1,20(1).jpg
Guckt man im Bild genau hin, sieht man die Schürze, die 'mitten in die Luft' gedruckt werden würde (ein weiterer Fall für den 'Siemens Lufthaken'). Ich habe die Schürze aus den Einstellungen entfernt und wieder geslict. Und dieselbe Warnmeldung wurde geliefert. Eine Analyse des erzeugten GCodes bestätigte jedoch, dass alle Fahrbefehle innerhalb des Bauraums wären. Somit ist der GCode trotz der Warnung in Ordnung!

Wie andere Slicer, besonders S3D, mit der Situation umgehen, müssen deren User selbst ermitteln.

Also: es gilt, das Volumen einer guten Flasche Wein (0.75l) nicht ohne weiteres her zu schenken. :prost:

Prosit Neujahr!
Gesundheit!

mjh11

Re: Bauraum des RF1000 und Unzulänglichkeiten einiger Slicer

Verfasst: Mo 3. Jan 2022, 20:34
von AtlonXP
Hallo rf1k_mjh11,
du, machst dir hier wieder Arbeit.

Vor kurzem stand ich auch vor dem Problem, den Bauraum optimal von meinem RF1000 auszunutzen.

Da ich mit S3D drucke, bin ich folgender maßen vorgegangen.
Das zu druckende Teil hatte eine Länge von genau 240 mm.
Die Breite meiner Druckplatte ist genau 254 mm.
Wir wissen jedoch, dass wir mit der Düsenspitze nicht ganz rechts bis an den Rand fahren können.

Unter diesen Bedingungen war klar, dass ich das Bauteil genau linke Kante der Druckplatte + 1mm positionieren muss.
Zusätzlich durfte der Prim, keine 2 mm Aufmaß erzeugen.

Ich habe dann einfach, nur den Prim des Bauteils angedruckt.
Der Prim war wie zu erwarten nicht genau bei X Mitte.
Mit einem Lineal habe ich danach den Versatz einfach rausgemessen.

In S3D gibt es in der Projekt Datei unter dem Reiter G-Code, die Möglichkeit einen G-Code
Versatz einzugeben.

Ich glaube es waren 1 oder 2 mm.
Somit habe ich den Mittelpunkt des Druckteils um 1 mm verschoben.
S3D platziert den Druckteilmittelpunkt auf die Mitte der Druckplatte.
Wolla es hat gepasst.

Hier der Beitrag wo das Bild her ist.
viewtopic.php?p=32577#p32577

Bild


LG AtlonXP

Bauraum des RF1000 und Unzulänglichkeit des Prusa Slicers

Verfasst: So 9. Jan 2022, 18:08
von rf1k_mjh11
Die Prusa Slicer Leute von GitHub haben sich bei mir gemeldet, bezüglich dem Problem, dass der Slicer keinen GCode erstellt, wenn ein Teil eines Druckobjekts über den Bauraum hinausragt (wobei der Bauraum immer nur eine Projektion der Bettfläche ist).

Ihre Lösung: Man solle einfach eine Textur hinterlegen, wo die Bettfläche dargestellt ist.

(Nebenbei haben sie nicht gesagt, dass man gleichzeitig die Bettgröße auf den maximalen Fahrweg der Y-Achse erweitern muss.)

Die Lösung funktioniert, ist aber schließlich eine Krücke.
Man muss sich selbst ein Bild malen, dass der Baufläche entspricht (245x245mm), mit einem Strich, dass die Bettkante repräsentiert (oder überhaupt eine ganze Fläche, die den Bereich markiert, wo keine Bettfläche vorhanden ist). Dieses Bild muss man in Prusa Slicer, unter 'Printer Settings', unter 'Bed Shape', angeben (erlaubte Formate für das Bild sind *.png und *.svg).
TextureEntryBox.jpg
Damit hat man zumindest einen optischen Anhalt, wo das Bett ist. Das sieht dann so aus (hier ist nur eine rote Line als Bettbegrenzung optisch angegeben):
PrusaSlicerWorkaround.jpg
Da ist einmal die rote Linie, die nicht überschritten werden darf. Zusätzlich habe ich, strichliert, ein 10mm Raster hingepfriemelt, um das Originalaussehen in etwa nachzuempfinden. :S

Im Prusa Slicer wurde dieselbe STL geladen, wie im ersten Beitrag des Threads gezeigt.
Man sieht, das Druckobjekt ist grün, also innerhalb des Bauraums. Prusa Slicer hat dann auch anstandslos GCode generiert. Man muss halt als User selbst darauf achten, dass das Druckobjekt vorne nicht über die Bettkante ragt.

Nachdem diese Angabe (die Textur) in dem Printer-Profile hinterlegt ist, könnten es einige schwer haben. Ich selbst habe über 20 Printer-Profile-Dateien. Man benötigt pro Düsendurchmesser (mindestens) eine Datei, da hier nicht nur der Düsendurchmesser, sondern auch die minimale und maximale Schichthöhe vorgegeben werden, ebenso der Retraction-Wert (der sich bei mir, zumindest, mit dem Material ändert: flexibles Material verlangt einen größeren Wert!). Ich habe auch noch immer ein V0 und 2 V2 Hot Ends, die andere Retract-Werte vertragen (oder gar verlangen?) im Vergleich zum ganz-Metall Pico Hot End. Das Pico Hot End hat 5 verschiedene Düsendurchmesser, die Original-Hot-Ends haben 3 Düsendurchmesser. Das alles zusammen verlangt eben so viele Profil-Dateien. Die müsste man alle ändern :weinen:

Alle guten Schutzimpfungen sind drei (oder mehr),

mjh11