Hiermit möchte ich einen weiteren Slicer vorstellen, der eine Weiterentwicklung vom PrusaSlicer ist, der wiederrum eine Weiterentwicklung vom slic3r ist. Der Slicer ist bekannt unter dem Namen

SuperSlicer

Es handelt sich dabei um eine weitere Open Source Option für einen Slicer, und ist damit gratis. Weiters muss SuperSlicer nichts in die Windows Registry schreiben und ist damit sogar von einem USB-Stick aus ausführbar (quasi ‘portable‘). Voraussetzung für dieses Verhalten ist jedoch, dass man im Konfigurationsassistenten keine Dateiverknüpfungen erstellen lässt.

Falls man schon slic3r oder PrusaSlicer kennt, ist der Umstieg nicht zu schwierig, da die Benutzeroberfläche und die Programmstruktur in großen Teilen mit den Vorgängern ident ist.
Komischerweise weichen einige der Begriffe voneinander ab (ich habe mich noch nicht sehr tief eingearbeitet und kann gerade nicht mit einem guten Beispiel aufwarten). Jedenfalls sind die Optionen teilweise anders organisiert, womit man nach einem Umstieg zuerst einmal gelegentlich suchen muss.

SuperSlicer bietet im Vergleich zu slic3r und PrusaSlicer einiges an zusätzlichen ‘Knöpfen‘ an denen gedreht werden kann. SuperSlicer bietet beispielsweise 12 Einstellungen, die etwas mit Brücken zu tun haben, statt der 5 oder 6, die PrusaSlicer erlaubt.
Auch was Perimeter betrifft, ermöglicht SuperSlicer einiges an Tuningmöglichkeiten. Insgesamt entdeckte ich mehr als 30 Einstellungen, die in irgendeiner Weise mit dem Perimeter in Verbindung stehen.
Natürlich kommen die meisten der vielen, fast verwirrenden Schalthebeln nur im 'Expert'-Modus zum Vorschein. Im 'Easy'-Modus dürfte kaum Verwirrung herrschen. Aber auch schon im 'Advanced'-Modus kann man sich ordentlich austoben.

Es gibt einige Videos, die den Umgang mit dem Slicer zum Thema haben (in Deutsch), hier (Grundlagen), hier (auch Grundlagen, Teil 1) oder hier (Teil 2 der Grundlagen), zum Beispiel.
Damit müsste man schon gut klarkommen.

Hat man sich bereits Profile unter slic3r oder PrusaSlicer erarbeitet, können diese praktisch eins zu eins in SuperSlicer übernommen werden. Entweder kann man sich über das File/Datei-Menü (Import) die Profile holen oder einfach die Dateien von dem einen Verzeichnis in das entsprechende neue Verzeichnis kopieren
(üblicherweise, zumindest bei mir, von
               C:\Users\username\AppData\Roaming\PrusaSlicer (oder Slic3r)\print (oder printer oder filament)
nach
               C:\Users\username\AppData\Roaming\SuperSlicer\print (oder printer oder filament)
kopieren.

Beim Start von SuperSlicer meldet sich das Programm, falls es Ungereimtheiten findet, und berichtet, wie es diese gelöst hat. Zum Beispiel:

               Print settings: "Profildateiname" (Pfad\Dateiname)
               "arc_fitting" (Arc fitting) : "disabled" was substituted with false
               "gcode_label_objects" (Label objects) : "octoprint" was substituted with true

Daraufhin kann man diese Einstellungen entsprechend korrigieren, um dieselbe Fehlermeldung beim nächsten Start zu vermeiden.

Ich werde mich in nächster Zeit stärker mit dem Slicer beschäftigen. Besonders wegen dem letzten Parameter unter "Width & Flow". Dazu woanders dann mehr….

mjh11

Bevor man sich auf diesen Slicer einlässt, sollte man ein bisschen dahinter schauen: Der Slicer ist von Prusaslicer geforkt und gibt an, auf dem neuesten Stand von Prusaslicer zu sein, ist aber tatsächlich ein paar Versionen hinterher anscheinend (ist auf dem Stand vom Mai letzten Jahres Version 2.5., aktuell ist 2.7). Ebenfalls fällt auf, dass im wesentlichen nur ein Entwickler beiträgt - meine Hochachtung wer so viel Zeit darein inversiteren kann, aber das Risiko ist recht real, dass der irgendwann hinwirft. Weiterhin scheint das Projekt immer weiter zu divergieren, die Merges passieren seit mehr als einem Jahr nicht mehr als normale git-Merges sondern quasi händisch (also die einzelnen Commits vom Prusaslicer sind nicht mehr sichtbar). Erfahrungsgemäß geht das nicht lange gut, sprich er wird bald wohl nur noch mit viel Aufwand ausgewählte Änderungen vom Prusaslicer übernehmen können.

Meiner Meinung nach wäre der bessere Ansatz, die Änderungen in den Prusaslicer zu integrieren, nach meinen Erfahrungen mit Klipper kann ich aber verstehen, wenn einem das zu langsam und mühsam ist. Vielleicht macht er das ja parallel, das sieht man ja nicht unbedingt (wobei seine Merge-Strategie eher dagegen spricht).

Wer diesen Slicer benutzt, kann also einige sicherlich interessante Funktionen und Verbesserungen nutzen, die dieser Entwickler ausprobiert, sollte sich aber darauf einstellen, irgendwann wieder den Slicer wechseln zu müssen.

Hier bringt mhier berechtigte Argumente vor.

Ich, als nicht sehr "github"-bewandt (eigentlich ein völliger Blindgänger in der Hinsicht), kann den Aussagen nur Vertrauen schenken.

Somit sollten solche, die langfristig bei nur einem Slicer bleiben wollen, SuperSlicer mit Vorsicht genießen. Die Entwicklung der Slicer geht relativ rasch voran, zumindest wenn man sich PrusaSlicer ansieht (slic3r hat sich schon länger nicht mit was Neuem gemeldet, seit 5+ Jahren steckt es bei v1.3.0.). Wenn tatsächlich der derzeitige Autor von SuperSlicer einmal die Arbeit einstellt, wird der Slicer rasch 'verjähren' und veraltet sein.

Als ich 2011 mit dem 3D Druck anfing, kannte ich nur Skeinforge und Pronterface(?) als Gratis-Lösungen für Slicer. Inzwischen gibt es fast ein Dutzend. Auch ich habe mich durch diverse Slicer durchgearbeitet. Inzwischen bin ich mit PrusaSlicer beim 4. oder 5. Slicer angelangt.
Es macht keinen Spaß, Slicer wechseln zu müssen, vor allem, wenn man noch grün hinter den Ohren ist. Mir macht es inzwischen weniger was aus, einen neuen Slicer (parallel) auszuprobieren. Aber freiwillig mache ich es auch nicht, wenn der Anreiz nicht entsprechend ist.

mjh11

Also ich bin neulich von Cura auf PrusaSlicer gewechselt und der Wechsel war sehr schnell erledigt. Wenn man mal verstanden hat, was die Parameter bedeuten und wie alles zusammenhängt, ist das alles kein Hexenwerk mehr. Für mich Ausschlaggebend war, dass PrusaSlicer einen Parameter für die maximale Volumen-Geschwindigkeit des Filaments hat. Das ist im Grunde der zentrale Parameter und mir ist ein bisschen ein Rätsel, warum nicht alle Slicer diesen haben. (Vermutlich weil früher die meisten Drucker mechanisch so instabil waren, dass vorher andere Probleme auftraten?)

Ich habe mich noch immer nicht sehr in den Slicer eingearbeitet (zur Zeit liegt einfach kein Druckbedarf an). Aber ein wenig daran herumgespielt habe ich schon.

In der Menüleiste findet man einen Eintrag, der in slic3r und PrusaSlicer fehlt: Calibration (Kalibrierung).
Da werden automatisch mehrere vorgefertigte Objekte unter unterschiedlichen Einstellungen geslicet, um gewisse Kalibrierungsmaßnahmen zu erleichtern. Für Anfänger und Neulinge sicherlich brauchbar, und auch für erfahrene User brauchbar, falls eine völlig neue Art von Filament getestet wird, wo noch keine Erfahrungswerte vorliegen. Zur Auswahl stehen im Menü:
          Introduction (Einleitung)
          Bed/Extruder leveling (Bett-/Extruderausrichtung) – Bei RFx000-Druckern kaum nötig
          Filament Flow calibration (Kalibrierung der Fördermenge)
          Filament temperature calibration
          Extruder retraction calibration (wie immer das auf Deutsch genannt wird)
          Bridge flow calibration (Kalibrierung der Fördermenge bei Brücken)
          Ironing pattern calibration (… wird später erklärt)
          Und als letztes wird einfach ein Kalibrierungswürfel zum Druck angeboten.

Zu jeder Variante werden recht detaillierte Beschreibungen (samt Fotos!) mitgeliefert, damit ein Anfänger sich zurecht finden kann und bei der Beurteilung Vergleichswerte sehen kann. Leider ist der gesamte Text derzeit noch auf Englisch. Die Fotos sind aber in perfektem Deutsch gehalten!

Trotzdem ist bei der Benutzung des Calibration-Menüs Vorsicht geboten. Der generierte GCode enthält einige falsche Befehle, obwohl SuperSlicer anhand der Druckerangaben den verwendeten Firmware-Dialekt wissen sollte.

So wurden bei mir für die Brückenfördermengenkalibrierung (ein schönes deutsches Wort, wa?) folgende GCode-Befehle erzeugt (zum Glück ganz zu Anfang):
     M201 X9000 Y9000 Z500 E10000 ; sets maximum accelerations, mm/sec^2
     M202 X1500 Y1500 ; sets maximum travel acceleration
     M203 X30000 Y30000 Z720 E7200 ; sets maximum feedrates, mm / min
     M205 X10.00 Y10.00 Z0.20 E2.50 ; sets the jerk limits, mm/sec
     M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec

Mit den ersten zwei Zeilen habe ich nicht unbedingt Zores, obwohl es komisch ist, dass für die Leerfahrten (M202) eine deutlich niedrigere Beschleunigung verwendet wird, als beim Drucken selbst (M201).

Meine wirklichen Einwände habe ich mit den drei folgenden Zeilen.
M203 hat für ‘uns‘ (für RFx000-Drucker) nichts mit maximalen Fördermengen zu tun, sondern fungiert angeblich als Temperaturüberwachung (obwohl ich noch nie eine Wirkung feststellen konnte).
Und die nächsten zwei Zeilen sind noch problematischer. M205 dient für ‘uns‘ dazu, die EEPROM-Werte auszugeben. Der Befehl kennt keine Parameter.
Ich habe keine Ahnung, was der Drucker letztendlich macht, wenn er GCode-Befehle mit falscher Syntax gefüttert bekommt. Unbekannte Befehle werden ignoriert, das habe ich mehrfach geprüft. Ob bei falscher Syntax die gesamte Zeile ignoriert wird oder nicht, kann ich nicht sagen. Ich, jedenfalls, habe diese Zeilen allesamt auskommentiert.

Ob ein Neuling imstande ist, die potentiellen Probleme zu erkennen, bezweifele ich. Diese sind vielleicht nur RFx000-spezifisch.

Zusätzlich werden die meisten (oder alle?) dieser Mehrfachkalibrierungsdruckobjekte normalerweise sequenziell gedruckt.Da, durch meine zusätzliche Beleuchtung, es recht knapp mit der Höhe geworden wäre, musste ich nach der ersten Generierung der Teile und des GCodes die Option explizit abwählen und neu slicen.
Das könnte ebenso für jemand, dem das nicht auffällt und es übersieht, für Ärger sorgen.

Man muss die Kalibrierungsbeispiele natürlich nicht verwenden.

Zum Abschluss noch ein Beispiel der Kalibrierungsteile. Hier die Brückenfördermengenkalibrierungsteile:Ausgegangen wird von dem derzeit eingestellten Wert für die Brücke (hier, z.B. 85%), worauf dann mehrere Teile mit abweichender Fördermenge gedruckt werden. Die Schürze und der Brim wurden ebenfalls automatisch generiert. Ich war etwas überrascht, da ich immer eine Schürze verwende, aber sehr selten einen Brim.

mjh11

Herrschaftszeiten! Jetzt habe ich vergessen, etwas im vorigen Beitrag zu erklären.

mjh11 hat geschrieben:Ironing pattern calibration (… wird später erklärt)

Das hole ich jetzt nach.

Diese Kalibrieroption behandelt einen Flow Rate (bzw. Material Multi oder Extrusion Multiplier) der extra für die Lage über einer Brücke eingesetzt wird. Da Hängebrücken bekanntlich leicht durchhängen, kann man für die Fläche und die Lage genau über einer Brücke einen eigenen Flow Rate angeben, um das Durchhängen etwas oder ganz auszugleichen. Alternativ kann man mit dem gleichen Kalibrierungsschritt die Flow Rate der obersten Lage tunen (in den Einstellungen nennt es sich "Top Fill").

Der Name ist mit Ironing ein wenig irreführend. Es hat mit dem Ironing wie es in PrusaSlicer seit einigen Versionen angeboten wird, nur indirekt zu tun.Natürlich bietet SuperSlicer auch die bekannte Möglichkeit des Ironing an, mit einigen zusätzlichen Optionen.

mjh11

rf1k_mjh11 hat geschrieben: In der Menüleiste findet man einen Eintrag, der in slic3r und PrusaSlicer fehlt: Calibration (Kalibrierung).

Das klingt super praktisch. Wer es nicht weiß: Natürlich geht das auch mit anderen Slicern, in dem man ein "Layerscript" schreibt, das die Druckeinstellungen entsprechend der Z-Höhe verändert (ich gehe da mal von einem Turm aus, entsprechende Modelle kann man sich auf den einschlägigen Seiten herunterladen - manchmal ist das passende Layer-Script gleich in der Beschreibung dabei). Aber das ist natürlich immer etwas fummelig.

Offenbar sind die jeweiligen Sprachmöglichkeiten noch nicht völlig implementiert.

Das ist übrigens eine gute Möglichkeit, sich an der Entwicklung eines Open-Source-Projektes zu beteiligen, auch wenn man nicht programmieren kann. Meist kann man recht leicht die entsprechenden Dateien für die Übersetzungen ausfindig machen und dann selbst die deutsche Übersetzung ergänzen. Idealerweise schickt man dann einen Pull Request an das Github-Projekt - wer hierfür Hilfe braucht (man sollte sich schon etwas mit git auskennen), der sagt bitte bescheid, ich helfe gerne (allerdings habe ich keine Ahnung von git unter Windows... ) Idealerweise nimmt man aber vorher Kontakt mit dem Entwickler auf und fragt nach, ob ein derartiger Beitrag überhaupt erwünscht ist (sonst macht man sich unnötig Arbeit).

Ich würde andernfalls davon ausgehen, dass bei einem derart kleinen Projekt Übersetzungen nie stattfinden werden, wenn sie nicht aus der Community kommen. Der Entwickler selbst hat weder selbst Bedarf daran noch spricht er alle Sprachen, und Zeit ist ohnehin knapp und wird lieber in Entwicklung gesteckt.

Derartige Beteiligungen einer Community können durchaus einen Beitrag dazu leisten, die Chancen auf einen dauerhaften Bestand des Projektes zu erhöhen. Das kann weitere Nutzer und vor allem auch weitere Entwickler anziehen, wenn sichtbar wird, dass es eine aktive Community gibt.

Der generierte GCode enthält einige falsche Befehle, obwohl SuperSlicer anhand der Druckerangaben den verwendeten Firmware-Dialekt wissen sollte.

Auch hier bietet sich wieder Möglichkeit zur Beteiligung ohne große Programmierkenntnise. Eine Recherche, welche Firmware-Typen (und -Versionen, siehe gleich) da welche Befehle erwarten mit einer übersichtlichen Auflistung, das ganze in ein Ticket auf Githab geschrieben, kann da durchaus helfen. Unsere Firmware ist im Wesentlichen Repetier, die ist nicht besonders speziell, wenn auch inzwischen nicht mehr sehr verbreitet (Marlin und Klipper dominieren vermutlich) und möglicherweise auch "end of life" (letzte Änderung ist 2 Jahre her). Allerdings haben wir eine sehr alte Version von Repetier. Es könnte sich also lohnen mal zu recherchieren, ob der Befehlssatz sich da in diesen Punkten geändert hat zwischen "unserer" Version und der neuesten. Falls nein, gibt es durchaus Chancen, dass das korrigiert wird - wenn man dem Entwickler die nötigen Informationen zukommen lässt (am besten mit Quellenangabe, irgendwas offizielles natürlich, nicht unser Forum).

Ob ein Neuling imstande ist, die potentiellen Probleme zu erkennen, bezweifele ich.

Ich würde deshalb Neuligen eher nicht empfehlen, solche Slicer mit wenig Verbreitung zu verwenden. Es ist im Zweifel dann schwierig, Hilfe zu bekommen, wenn man nicht mehr weiter weiß. Vor allem ist es für Neulinge schwer, Bugs von eigenen Fehlern zu unterscheiden.

Zusätzlich werden die meisten (oder alle?) dieser Mehrfachkalibrierungsdruckobjekte normalerweise sequenziell gedruckt.[

Das wäre für mich ebenfalls ein Show Stopper, oder zumindest müsste ich extrem aufpassen, dass die Reihenfolge stimmt, damit mein Lüfterkanal nicht mit den Objekten kollidiert. Ich ziehe deshalb Kalibrations-Türme vor.

Ein serieller Druck ist bei der RFX000 Klasse nur mit sehr niedrigen Bauteilen möglich.
Meistens ist das Erst geduckte Teil zu hoch.

Bei Druckbeginn des zweiten Druckteils,
wird das Erst gedruckte zwischen Druckplatte und der Decke eingeklemmt (Kollisionsgefahr)!

LG AtlonXP

Hallo nochmals.

Zuerst einmal eine Korrektur meinerseits.

rf1k_mjh11 hat geschrieben:Da, durch meine zusätzliche Beleuchtung, es recht knapp mit der Höhe geworden wäre, musste ich nach der ersten Generierung der Teile und des GCodes die Option explizit abwählen und neu slicen.

Jetzt im Nachhinein sehe ich, dass die Teile 'nur' 7.4mm hoch sind. Irgendwie hatte ich beim ersten Mal den Eindruck, sie wären an die 15mm hoch. Da habe ich mich offensichtlich verguckt. Bei 7.4mm hätte ich problemlos sequenziell drucken können, bei 15 wäre es mit der Beleuchtung allerdings knapp geworden. Der Bauteillüfter bei mir hätte keine Probleme bereitet.

Ich habe extra den Punkt des sequenziellen Druckens und der 'falschen GCode-Befehle' aufgebracht, da ich ja weiß, was Andere für unterschiedliche Lösungen bezüglich Bauteillüfter hervorgebracht haben, bzw. was falsche GCodes anrichten können. Vielleicht hätte ich eine größere Schriftgröße verwenden sollen, damit das ja keiner übersieht.

mhier hat geschrieben:Natürlich geht das auch mit anderen Slicern, in dem man ein "Layerscript" schreibt, das die Druckeinstellungen entsprechend der Z-Höhe verändert

Das ist völlig richtig.
Nur steigt dort ein Neuling meist ebenso aus. Auch ich müsste mich da mit einiger Mühe erst einarbeiten - auf Anhieb bekäme ich es garantiert nicht fehlerfrei hin. Da war das Auskommentieren der falschen Befehle für mich einfacher. Doof war, zugegeben, das Entfernen des 'sequenziell Drucken'-Häkchens und das neuerliche Slicen.

mhier zitiert mjh11, der hat geschrieben:Offenbar sind die jeweiligen Sprachmöglichkeiten noch nicht völlig implementiert.

Anhand mhiers Bemerkungen habe ich mich ein wenig mit der Lokalisierung beschäftigt. Scheinbar muss man gar nicht warten, bis eine Sprache völlig implementiert oder unterstützt wird. Man kann auch bei einer bereits 'installierten' Version da 'herum pfriemeln'. Auf der github Seite vom SuperSlicer wird, unter 'localization' recht genau erklärt, wie man vorgehen kann/muss um Begriffe in die gewählte Sprache umzusetzen, oder falsche Übersetzungen zu korrigieren. (Eben sehe ich, dass exakt dieselbe Erklärung in der Datei namens README.md steht, der sich im SuperSlicer Programmordner befindet.)

Extrem tief habe ich mich da nicht hinein gekniet, aber am Rechner, in dem Unterverzeichniss (Unterordner) des SuperSlicer Programms (..\resources\localization\de) findet man eine Textdatei namens 'TODO.po', wo die offenen Begriffe, die noch nicht ins Deutsche übersetzt wurden, stehen. (Aber ein bloßes Hinzufügen/Korrigieren ist zu wenig - da muss 'kompiliert' werden, usw., bevor es vom SuperSlicer Programm auch benutzt wird.) Dazu benötigt man python und GetText und vielleicht noch etwas. Die Beschreibung ist mir nicht ganz klar (dabei ist es in meiner Muttersprache gehalten ). Daher ist es vermutlich auch nichts für Neulinge, die sich in der github-Welt nicht auskennen. Besteht trotzdem Bedarf, sollte man sich hier an mhier wenden.

mjh11

Hallo,

mhier hat geschrieben:Allerdings haben wir eine sehr alte Version von Repetier. Es könnte sich also lohnen mal zu recherchieren, ob der Befehlssatz sich da in diesen Punkten geändert hat zwischen "unserer" Version und der neuesten.

Basierend auf der (für mich, zumindest) umfangreichsten GCode-Liste, haben meine Aussagen noch immer für die Repetier-FW Gültigkeit (das wären: M203=Temperaturüberwachung setzen und M205 EEPROM-Werte ausgeben). Das habe ich natürlich schon vor dem Posten recherchiert.

Es könnte jedoch sein, dass in einer development Version was anderes inzwischen implementiert ist. Um das zu prüfen müsste man alle Change Logs durchackern.

mjh11