Der 'echte' Bauraum beim RF1000 und RF2000, also das Volumen, dass ein Druckobjekt einnehmen könnte, sieht so aus: 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.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.
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: 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: Man beachte die Schürze (in grün), die mittels 'Siemens Lufthaken' in Position gehalten wird.
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: 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
. (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: 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: 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: 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.
Prosit Neujahr!
Gesundheit!
mjh11
