Voraussichtliche Druckzeit stimmt nicht
Warum die im Slicer angezeigte Druckdauer meist mit der Realität nicht viel am Hut hat.
Die kurze Antwort ist:
Weil der Slicer nicht weiss, wie schnell Dein Drucker tatsächlich ist.
Etwas ausführlicher:
Um die Druckzeit korrekt berechnen zu können, braucht der Slicer wesentlich mehr Informationen als er tatsächlich hat. Lasst uns etwas ausholen..
Eingestellte Geschwindigkeit vs. Realität:
Wir geben zwar im Slicer eine Geschwindigkeit in mm/s (bzw. mm/min) vor, das ist aber eher eine gewünschte Maximalgeschwindigkeit als die tatsächliche Geschwindigkeit, die dann auch tatsächlich ausgeführt wird.
Warum ist das so?
Eine Geschwindigkeitsänderung erfolgt nicht sofort, wie auch im Auto brauche ich zum Erreichen meiner Wunschgeschwindigkeit einmal eine ausreichende Beschleunigung (engl. Acceleration) und eine entsprechend lange Strecke, um mit der mir zur Verfügung stehenden Beschleunigung meine Wunschgeschwindigkeit auch zu erreichen. Ist die Beschleunigung zu gering oder die Strecke zu kurz, dann wird die Wunschgeschwindigkeit niemals erreicht. Davon kriegt der Slicer erst mal nix mit.
Ich kann mit dem Auto auch nicht mit Vollgas um die Ecke fahren, muss also vorher bremsen.
Übersetzt auf den 3D Druck heisst das: ich brauche lange, gerade Strecken, damit ich auch an die im Slicer hinterlegte Geschwindigkeit heran komme. Bei kurzen Teilstrecken ist er die meiste Zeit entweder noch am Beschleunigen oder schon wieder am Bremsen.
Wie schnell druckt er wirklich?
Auch hier hilft wieder mal der Prusa Calculator auf: https://blog.prusaprinters.org/calculator/
Nehmen wir die Beschleunigungswerte eines Ender3 ab Werk, das sind 500mm/s² (Auslesen lässt sich das mit Pronterface und dem Befehl M503), dazu eine Strecke von 20mm – der allseits beliebte Testwürfel – und eine Wunschgeschwindigkeit von 80mm/s, das ergibt folgendes Ergebnis:
Nun kommt dann auch zusätzlich noch die Ruck (engl. Jerk) Einstellung zum Tragen, die vom Prusa Calculator nicht berücksichtigt wird.
Die meisten Slicer rechnen aber (vermutlich) hier mit 80mm/s über die gesamte Strecke. Tatsächlich sieht das ganze allerdings dann eher so aus, wie die ausführliche Analyse des kostenlosen Gcode Analysers zeigt:
Wie hier zu sehen, nur während so etwa 50% der Gesamtstrecke war der Drucker überhaupt auf der Wunschgeschwindigkeit.
Umsetzung im Slicer
Die meisten Slicer kennen weder die Beschleunigung noch die Ruckeinstellung des Druckers.
- Erst seit Cura 4 (oder wars schon Cura 3?) kann in Cura nach Aktivierung der Beschleunigungssteuerung bzw. Rucksteuerung Angaben hierzu gemacht werden.
- Simplify3D kann es heute noch nicht.
- Bei Slic3r weiss ichs nicht.
Aber auch wenn die Einstellung vorhanden ist, kann der Slicer nur dann korrekt rechnen, wenn diese Einstellung mit den tatsächlich im Drucker aktiven Einstellungen übereinstimmt (bzw. wenn, wie im Fall von Cura, der Slicer diese Einstellung am Drucker notfalls überschreibt).
Weitere mögliche Störfaktoren sind:
- Besondere Firmware Features wie S-Curve Acceleration
- Zeit zum Heizen von Bett und Düse – die Werte kennt der Slicer nicht
- Dual- oder MultiExtrusion und damit einhergehende Pausen zum Werkzeugwechsel und eventuelles „Nachheizen“ aus dem Standby, etc.
- zu lahme CPU auf dem Druckerboard
- Engpässe in der Datenübertragung, sei es extern über USB, schlechte SD-Karten(leser) oder intern.
- Z-Hops & Retracts sind zwar bekannt, aber auch berücksichtigt?
Unterm Strich bleibt die Erkenntnis:
Die Vorhersagen der Slicer der Druckdauer sind erst Mal nur grobe Anhaltspunkte. Je nach Beschaffenheit des Druckstück, den im Slicer hinterlegten oder hinterlegbaren Angaben mal mehr oder weniger genau.
Cura v4 oder neuer dürfte dabei bei korrekter Konfiguration für Ruck & Beschleunigung noch am genauesten sein. Wenn man sich entsprechend Mühe mit dem Übertragen der Parameter gibt, ist auch Repetier-Server brauchbar. Simplify3D kann man leider getrost abhaken in der Beziehung. Mit Slic3r und PrusaSlicer hab ich keine Erfahrung.
Will mans ganz genau wissen und scheut die Mühe nicht, das da extra hochzuladen und die Parameter händisch einzutippen, ist https://www.gcodeanalyser.com/ extrem praktisch.
Übrigens: dass Cura es kann, seh ich jeden Tag an den Drucken mit den Ultimaker Druckern, die stimmt relativ gut, hier hat Ultimaker ja auch ein leichtes Spiel, kennt die genauen Parameter ihrer Drucker und es pfuscht ihnen auch keiner in die Settings. Ähnlich gute Ergebnisse sollte PrusaSlicer für die MK2 & MK3 liefern (können), wenn nicht vom Anwender gross an den Settings gebastelt wird.
Für den PrusaSlicer und Prus Mini+ kann ich bestätigen, dass die Vorhersage zu 95% zutrifft. Nicht so beim Sidewinder X1 und Cura, da liegt die Vorhersage in der Regel 20% über der tatsächlichen Zeit.
Technisch sollte es ja möglich sein, das der Slicer sich die notwendigen Parameter vom Drucker holt. Er weiß z.B.: die aktuelle Temperatur vom Drucker und die ausgewählte zum Drucken. Dann bekommt er eine Rückmeldung, wenn die Temperatur erreicht ist mit allen Zwischenwerten. Genauso sieht es bei den Beschleunigungen aus, der Drucker liefert immer eine Bestätigung, wenn ein Befehl abgearbeitet wurde. Aus diesen Daten könnte die Druck-Dauer meines Erachtens sehr genau berechnet werden, wenn man denn will.
Danke für diesen tollen Blog. War sehr interessant zu lesen.
Hallo Stephan,
falls du einen Prusa Drucker hast solltest du den mal mit dem Prusa Slicer ausprobieren. Wenn ich das richtig verstanden habe wird da im Hintergrund der Druckprozess des Druckers simuliert was zu erstaunlich präzisen Vorhersagen führt. Selbst bei Drucken >24h liegt die Genauigkeit bei wenigen Minuten Abweichung.
Ja, das dachte ich mir, das dass bei den Prusas ähnlich gut klappt. Ich hab zwar 2 Prusas, aber den PrusaSlicer nicht in Benutzung. Danke für die Bestätigung 🙂
Habe zwar keinen Prusa Drucker, habe aber im PrusaSlicer meine Daten aus der Firmware des Druckers angegeben.
In 95% der Fälle stimmt die errechnete Druckzeit auf 2-3min mit den realen Werten ein, man muss ja noch Homen und BL-Touch mit zurechnen, dann geht sich das fast aus.
Nur bei gedruckten Fotos, da klappt es leider nicht. Da wird z.B. 6:30 h angezeigt, es sind aber real z.B. 8:10h.
Da liegt er ordentlich neben, aber da wird eben auch recht langsam gefahren…
Auch ich habe gute Erfahrungen mit dem Prusaslicer gemacht und meine Druckzeiten stimmen mit den errechneten Druckzeiten meiner Prusa’s überein
In der neuen Version werden sogar die Zeiten eingeblendet wenn man ein mehrfarbiges Teil drucken will wann das Filament gewechselt werden muß
Ich nutze den IdeaMaker als Slicer. In Verbindung mit dem Sapphire S Drucker und der aktuellen Firmware stimmen die Druckzeiten ziemlich genau. Beim 3 Stunden Druck eine Abweichung kleiner 5 Minuten.
Bei anderen Slicern ist die Differenz größer.
Vielen Dank für die Darstellung, auch ich habe damals lange nach einer Lösung gesucht und mich oft gewundert warum ein längerer Druck nicht nach der angegebenen Zeit fertig war.
Derzeit verwende ich in meinem HEVO ein Duet Ethernet Board. Hier ist es möglich über die Weböberfläche wo man seinen Drucker steuern kann und den Dateiupload macht, die Datei zu simulieren.
Das ganze funktioniert aber nur in der „Duet Web Control 2.0.0-RC7“ die Simulation greift hier aber auch nicht auf die Zeit für vom Aufheizen zurück. Jedoch hat man dann annährend eine Zeitangabe die dann auch mit der Druckzeit stimmt. Ideal wenn man mal die Druckzeit für ein Projekt erfassen möchte.
Bei Simplify3D hat sich die Vorhersage mit V4 oder 4.1 deutlich gebessert. Bei meinem Flashforge Creator Pro durfte ich früher teils 30-40% auf die Slicer Vorhersage draufschlagen, mittlerweile liegt die Abweichung eher im Bereich von <=5%.
Einen Parameter zum Beeinflussen dieser Berechnung kenne ich aber auch ned …
Dazu kommt, zumindest bei kleineren Modellen noch ein gewisser Offset durch die Aufheizzeiten von Bett und Düse, welcher dem Slicer auch unbekannt ist, in z.B. Marlin aber mit auf die Druckzeitanzeige gerechnet wird.
Trotzdem, habe gerade ein grosses Modell: Slicerzeit 35h 18m, reale Druckzeit (mit Heizphase) 35h 37m, also erstaunlich genau… 🙂
Hallo Stephan,
vielen Dank für die ausführliche Darstellung dieses Sachverhalts. Man, muss ich noch viel lernen 🙂