Slic3r "Slicing" Geschwindigkeit

Mahlzeit zusammen,

Ich probiere momentan verschiedene Slining programme aus. Cura, Kisslicer, etc. Aktuell hänge ich bei Slic3r und habe damit das eine oder andere Problem. Obwohl die Einstellungen ähnlich sind (selbe Geschwindigkeiten, druckhöhe etc) liegt die Druckdauer vergleichen mit anderen Slicern bei 30-40% länger (bei großen Drucken schonmal 1-2 Stunden mehr).

Außerdem dauert das Slicen an sich sehr sehr lange. Manchmal teilweise eine halbe Stunde, Kisslicer oder Cura brauchen da nur ein paar Sekunden. Woran liegt das? Gibt es Einstellungen die man machen kann damit es schneller geht?

Irgendwie macht der Slicer bei mir Probleme, aber es muss an mir liegen, bzw an meinen Einstellungen, sonst wäre der Slic3r nicht das beliebteste Slicing programm aktuell.

Vielen Dank für die Hilfe.

Eigentlich ist Slic3r recht schnell, außer wenn du avoid crossing perimeters aktivierst. Dann kann es eine gefühlte ewigkeit dauern.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

liegt u. A. Auch an Windows.
hatte auf meinem Macbook (i5/2.4Quad, 32GB RAM, SSD) Win7 nativ (also nix emuliert):
Slicen etwa 6 Min.
Das Macbook mit Mac OS X Lion neu gestartet und selbe Datei geladen:
Slicen etwas über eine Minute.
Grüße
seefew

Das slicen dauert bei mir auch extrem lange, allerdings nur das Schreiben des GCode auf die Platte.
Anscheinend schreibt er die Zeile für Zeile... hat dann glatt 20 Minuten gedauert.
Und es macht auch nen Unterschied ob aus Slic3r direkt der GCode erzeugt wird, oder von RepetierHost aus, da legt man knapp nochmal das selbe drauf.

Die selbe Datei braucht in CURA knapp über ne Minute.

Gruß
Jay

Quote
JayTheMaggot
Das slicen dauert bei mir auch extrem lange, allerdings nur das Schreiben des GCode auf die Platte.
Anscheinend schreibt er die Zeile für Zeile... hat dann glatt 20 Minuten gedauert.
Und es macht auch nen Unterschied ob aus Slic3r direkt der GCode erzeugt wird, oder von RepetierHost aus, da legt man knapp nochmal das selbe drauf.

Die selbe Datei braucht in CURA knapp über ne Minute.

Gruß
Jay

Genau das meinte ich. Er hängt immer bei "speichere GCode" Er brauch sehr lange obwohl Slic3r auf SSD läuft. Gibt es dafür ein "workaround"?

hatte ich auch
welche slicer version hast du ?
mit rc3 ist es nicht mehr da, mit rc2 war es extrem.

---

Commercium ----> Ramps, RADDS, e3d-Hotends und Filament kauft man hier.. und neu auch Schrauben,Muttern und Unterlegscheiben
Probleme mit dem e3d und bei mir gekauft? Schickt es ein, ich teste es für euch ob es wirklich defekt ist
Print Quality Troubleshooting Guide hier lang..

Leider ist es RC3

Es scheint irgendwie von der Rechner gesamt Konfiguration abzuhängen.

Ich hab das selbe Teil mit gleichen Einstellungen mal auf meinem großen (6cores; 8GB RAM; 2x SSD Platten) und auf meinem NETBOOK (Intel Atom Single Core; HDD; 4GB RAM) laufen lassen, beide mit Windows 8.1.
Dabei war das Netbook indirekt wesentlich schneller.
Indirekt deshalb, weil die Berechnung des GCodes zwar länger gedauert hat, aber das schreiben auf die Festplatte dafür quasi in Rekordzeit erledigt war.

Der einzige Unterschied, der mir momentan direkt einfällt wäre 64Bit gegen 32Bit Betriebssystem.
Am Wochenende werd ich mal genauer testen.

Greetz
Jay

Richtig langsam wird der gcode-export, wenn "avoid crossing perimeters" gewählt ist. Sowas kommt dabei raus :



LG, Willy

---

3D gedruckter Messerschärfer +++ RADDS für den Arduino-Due +++ Meine Drucker

Danke, das hat zumindest schonmal etwas geholfen. Wobei ich einen Bowdenextruder verwende, deswegen war es bei mir "an"

Ich enter hier einfach mal..
Momentan bin ich dabei, eine numerisch gesteuertes Heißkleberdüsengestell zusammenzubauen.
Bei der Auswahl der soften Ware bin ich da auch bei Slic3R (1.1) hängengeblieben.
Leider kann ich die u.U. ausufernde Geschwindigkeit nur bestätigen.
Meine ersten Versuchsobjekte waren Internetfindlinge (LM8UU-PLA-Bushings im IGUS Style von Thingdingsbums) und eigene Abwandlungen solcher, also SCAD Varianten als STL exportiert.

- Unverändert mit Voreinstellungen aufgerufen lief der Slicer einige Minuten, ca. 5 bis 10., die Dateigröße lag zwischen ca. 2 und 30 MB (800000 Zeilen), Einzelobjekt bzw. 12-fach mit 120 Schichten
- Nach diversen Einstellungen aus dem Bauch heraus ins blaue hinein wollte der Slicer nicht enden wollen, zweimal habe ich ihn nach ca. 60 - 90 ,in abgebrochen. Nach Abbruch zählte die Ausgabedatei ca. 2-3 MB und 60000-80000 Zeilen, also ca. 10%.
Daraufhin habe ich diesen Thread gefunden und den Tip mit der Perimeterkreuzung, es war tatsächlich die Hauptursache und für min. 95% der Rechendauer verantwortlich.
- Eine weiteres Kriterium scheint die Symmetrie der Konstruktion zu sein, nach min. Änderung meines Modells Richtung Punktsymmetrie sank die Laufzeit auf unter zwei min.

Dabei ist mir folgendes aufgefallen (Win7 64bit, 4 Kerne, Chipsatzgrafik):
Obwohl alle!! Kerne benutzt wurden, die CPU-Nutzung betrug exakt 25%!
Solo aufgerufen, dabei wurden 7 Threads geöffnet.
Via Repetier-Host war es nur ein Thread, die CPU Auslastung wurde zwischen 23,5 und 24,5 ausgewiesen.

Zum Vergleich:
CURA scheint unmittelbar intern zu rendern, das Log der Cura-Engine listet zeiten zwischen 6 und 36 sec.
Erstaunlich: Auch Cura zeigt eine CPU-Last von 25% bei stark frequntierender kernnutzung an, macht aber mehr Threads auf, min 10.

Nur bei KISS ist die CPU ausgelastet, 100% fast kontinuierlich.

Ist mir auch aufgefallen...

Die Qualität allerdings des g-codes bei Slic3r ist meisst wesentlich besser.
Mit Walder hatte ich mir das in der Tiefe angeschaut (Bootsrumpf, dünnwandig).
Da kam leider nur brauchbarer gcode mit slic3r raus.
Bei einfacher Geometire (Würfel z.B ) ist es wiederum egal.
Mal schauen, wenn ich ein .stl bearbeite (netfabb basic) und die Anzahl der "Dreiecke" wesentlich erhöhe, was da bei welchem Slic3r rauskommt.
(Layerhöhe 0,03 mm will ich versuchen, hab ja 32-Bit, müsste von Firmware Repetier kein Problem darstellen, Danke Willy und repetier)

Kisslicer wird nicht mehr supportet, also uninteressant.

Simphony3d ist lagsamer als Cura (getestet von jsturm) und hat schlechteren gcode -> also auch zu vernachlässigen.
Skenforge noch nicht getestet, da aber Modular und in python geschrieben subjektiv zu vernachlässigen.

Gerüchte haben mir geflüstert, das repetier einen integrierten slicer für repetier-host in Planung hat.
Ich glaube, das wenn repetier ein slicer in C schreibt, dann keine Wünsche mehr offen sind :-).

Verfolge das Thema gerne einmal, da es mich aktuell interessiert
(auf udoo quad slice ich mit cura für "einfache .stl" absolut ausreichend -> Octoprint).

1-mal bearbeitet. Zuletzt am 11.04.14 05:28.

---

Mein Club: [hackerspace-ffm.de]
RADDS-Shield -> Commercial [max3dshop.org]

Quote
angelo
Die Qualität allerdings des g-codes bei Slic3r ist meisst wesentlich besser.

Das habe ich bislang so gelesen, mit meinem Aufgalopp aber leider einen Bauchflatscher gelandet..
Möglich, dass meine beiden Konstrukte genau dessen Schwachstelle getroffen haben, trotzdem wundere ich mich über die recht unorthodoxen Verfahrwege, sofern ich dem G-Code Simulator trauen kann und der die Sequenz nicht durcheinander würfelt.

Quote
angelo
Mit Walder..

???

Quote
angelo
hatte ich mir das in der Tiefe angeschaut (Bootsrumpf, dünnwandig).
Da kam leider nur brauchbarer gcode mit slic3r raus...

Das wundert mich jetzt, ich habe mich soeben darüber ausgeheult, dass Slic3r bei mir völlig versagt (Dünnbrettbohrer) und nur gespickte oder gar durchlöcherte Wände abgeliefert hatte.

hi bianchifan,
poste mal deine stl datei
walder = [forums.reprap.org]
Manchmal liegt es an den einstellungen des Slice3r-> wenn du magst, poste mal dein druckermodell und deine *ini Datei bzw. Druckslicingconfig.
lies mal:
[forums.reprap.org]

---

Mein Club: [hackerspace-ffm.de]
RADDS-Shield -> Commercial [max3dshop.org]

Nochmal zu den Zeiten... mittlerweile bin ich zur Ansicht gelangt, dass die Forderung zur Vermeidung von Perimeterkreuzungen zwar die Programmlaufzeit in die Länge zieht, letztendlich aber nicht hauptursächlich für meine Extremlaufzeiten ist.
Entscheidend dafür sind m.E. Kollisionen zwischen unterschiedlichen Forderungen.
An erster Stelle möchte ich dabei dünnwandige Kontrukte benennen, bei denen die eingestellte Mindeststärke des Perimeters ohne weitere Füllung bereits die Wanddicke des Modells überschreitet.
Was im Grenzbereich bei Strukturen geringer Größe noch funktionieren mag stellt den Slicer dann bei größeren Konstrukten oder gar mehrfachen Exemplaren vor nahezu unlösbare Problme.

Ein schönes Beispiel dafür ist ein voll bestückter Teller Kettenglieder.
EIn einzelnes Glied wird meistens innerhalb weniger Sekunden abgearbeitet, auch bei Forderungskollisionen, bei den von mir getesteten Objekten so zwischen 2,5 und 10 sec.
Zum Vergleich : Cura benötigte zwischen 0,4 und 2 sec.
Erhöhte sich die Anzahl auf 10 nahm folglich aus die Bearbeitungszeit zu, erstaunlicherweise aber nicht linear bzw. proportional.
Cura reagierte eindeutig unterproportional, Faktoren zwischen 2 und 5 habe ich beobachtet.
Slic3R reagierte annähernd proportional, wenn das Modell keine konkurrierenden Forderungen abverlangte. Waren solche aber inbegriffen stieg die Zeit, bis zu 15 min.
Wurde der Teller dagegen gut belegt, 36 Stück, war Schicht: Der Abbruch nach 90 min Laufzeit zeigte gerade mal ca. 5% des erwarteten Outputs, 1,5 MB bei gemutmaßten 40 MB.
Cura genehmigte sich ca. 2:30 für die selbe Aufgabe.

Beherzigt man diesen eigentlich logischen Zusammenhang und passt die Druckeinstellungen an das vorliegende Modell entsprechend an und lässt dem Slicer noch Handlungsspielraum für sein Füllmuster, also notfalls bis zur Reduktion auf einen Perimeter mit der Stärke "1", ist alles in Butter.
Auch bei vollem Teller sind Laufzeiten von unter 2 min möglich, aber auch 7 min sind imho da akzeptabel.