Slic3r NEW Release 0.9.5/6 !!

Gib eine neue Slic3r Version Release 0.9.5/6
Slic3r Ver0.9.5/6


Ettliche Bugs raus

Kuirz von mir angetestet
Ergebniss füllt besser !

ABER immer noch NICHT so gut wie Skeinforge !


Hardwarekiller

1-mal bearbeitet. Zuletzt am 08.11.12 15:53.

Hardwarekiller Wrote:
-------------------------------------------------------
> Gib eine neue Slic3r Version Release 0.9.5/6
> Slic3r Ver0.9.5/6
>
>
> Ettliche Bugs raus
>
> Kuirz von mir angetestet
> Ergebniss füllt besser !

Ja, auch gleich ausprobiert:
Die Lücken beim Infill sind nun weg, das Ergebnis sieht sehr sauber aus.
Hab's mit verschiedenen Teilen ausprobiert und keine Macken entdecken können.
Richtig gut erkennt man die Verbesserungen bei Zahnrädern.

Das unten abgebildete Teil lässt sich mit Skeinforge nicht sinnvoll slicen. Das Skeinforge-Ergebnis sieht zwar angesichts der hohen Druckgeschwindigkeit (bis 140 mm/s, PLA) ganz gut aus doch im Bereich der horizontalen Schraubenlöcher, die beim Druck um 15° zur Horizontalen geneigt sind, füllt Skeinforge im Bereich von fast 10 mm Höhe nur in einer Richtung (senkrecht zu den Löchern, da diese als Brücke behandelt werden). Dadurch wird das Teil labil und unbrauchbar. Wenn "infill in direction of bridge" abgestellt wird, dann werden die anderen Brücken, die auf den Fotos nicht sichtbar sind, unbrauchbar.

Slic3r füllt da wesentlich besser, da nur im Brücken-Bereich die Füllrichtung an die Brücke angepasst wird. Leider ist das Ergebnis (Bild 2) trotzdem unbrauchbar, da sich in der Krümmung "Knubbel" bilden, die darauf zurückzuführen sind, dass die Firmware an der jeweiligen Stelle kurzzeitig stoppt. Das Stoppen habe ich im gcode versucht nach zu vollziehen und bin auf sowas gestoßen:

G1 X153.692 Y88.300 E7.05140
G1 X157.946 Y88.494 E7.20587
G1 X162.153 Y89.070 E7.35994
G1 X162.153 Y89.070 E7.35994
G1 X162.206 Y89.077 E7.36185
G1 X162.206 Y89.082 E7.36203

Von den beiden mittleren Zeilen ist eine komplett überflüssig. Aber auch danach ist die Bewegung so winzig, dass statt der erwünschten Genauigkeit wohl eher eine "Firmware-Überlastung" auftritt, die zu den Knubbeln führt.

Daraufhin habe ich mir ein "gcode-Bereinigungsprogramm" geschrieben (in Tuirbo-Pascal ) das überflüssige G1-Befehle rausschmeißt. Das Ergebnis ist in Bild 3 zu sehen. Jetzt bin ich auch von Slic3r überzeugt . Wünschenswert wäre aber noch eine eingebaute "Bereinigung".

LG, Willy


Skeinforge + Marlin:


Slic3r + Repetier:


Slicer + Bereinigung + Repetier:

---

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

Häng mal das STL bitte mal an

Hardwarekiller

Ich sehe schon, Du glaubst noch nicht, dass Skeinforge hier Mist macht ;-)

LG, Willy

---

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

@Willy

Ich glaub dir das schon, währe nur eins der wenigen Teile wo es mal grössere Probleme gibt><
Slic3r ist zwar besser geworden jedoch noch nicht auf dem Level den Skeinforge hat.
Was mich an Slic3r immer stört ist 2 Bugs raus und 3 neue rein

Ist dein "Tuirbo-Pascal " (kenne ich noch gar nicht die Sprache den Open Source oder Bierware oder Only for Special User
Kann man das bekommen ?

Hardwarekiller

2-mal bearbeitet. Zuletzt am 14.11.12 22:13.

Doppelte GCodes oder Microfahrwege könnte man bestimmt auch schön in der Firmware abfangen, oder?

@Hardwarekiller:

> Ist dein "Tuirbo-Pascal " (kenne ich noch gar
> nicht die Sprache den Open Source oder Bierware
> oder Only for Special User
> Kann man das bekommen ?

Wenn Du nicht in den 80er Jahren damit programmiert hast, dann stehen die Chancen recht schlecht Turbo-Pascal kennen zu lernen. Man konnte es noch eine Zeit lang im Borland-Museum kostenfrei runterladen, aber ich glaube, dass die Seite mittlerweile auch geschlossen ist. Außerdem erfordert es DOS, was bedeutet, dass es nur bis XP läuft. Trotzdem hat es nach wie vor den schnellsten Compiler mit sinnvollen! Fehlermeldungen und eine herrlich einfache Oberfläche / Entwicklungsumgebung .

@Jack_n:
>Doppelte GCodes oder Microfahrwege könnte man
>bestimmt auch schön in der Firmware abfangen, oder?

Nein, eben gerade nicht. Bei hohen Druck-Geschwindigkeiten ist der Arduino ohnehin schon überfordert (Stichwort Doppel- oder Vierfach-Stepping bei Repetier) und genau das führt ja dazu, dass kurze Pausen Knubbel ergeben. Das Problem scheinen die Slic3r-Entwickler aber zu kennen.

LG, Willy

---

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

@ Willy
er meinte dein I dazwischen
Tuirbo-Pascal

@Le-Seaw:

Danke

Ich glaub' ich brauch ne neue Brille

LG, Willy

Ne das liegt daran das man nicht glaubt das Hardwarekiller mal was nicht kennt

Und das war jetzt nicht negativ gemeint.

Ich kenne schon Turbo Pascal, kenne auch noch Fortran, mein erster Computer war ein selbstgebauter Elektor SC/MP-Computer von 1977
Da hat man noch die Speicher-adresse und den Hex Wert per Kippschalter eingegeben, danach gab es nen Z80 Sinclair, der hatte zumindest schon mal ne Folientastatur><

Ich dachte schon das "Tuirbo" weil da ein i drinen ist wieder mal was mit Apple zu tun hat von wegen i.
iBook, ipod, ipad, iMac, i irgendwas, iKlodeckel usw.

Hardwarekiller

Ich hätte da noch einen 4004 und einige 8080er Mikroprozessoren. Interesse?
Richard.B

... jemand Interesse an alten Home-Computern und Software dazu ... oder dabei ein Computermuseum o.ä. aufzubauen?

Ich hätte noch einiges aus den Anfängen funktionsfähig da, von Commodore VC20/C64/C128/Amiga500 bis Atari 800XL / ST 260/520/1040/Mega ... die ersten/älteren PC's aus der Ära habens meist nicht mehr überlebt und habe ich entsorgt - eine PC-Emulatorbox mit NEC V20-CPU für Atari ST/Mega und eins der ersten PC-Notebooks mit einem speziell angepaßen Windows und im Displaydeckel integriertem Trackball statt Maus sollten auch noch irgendwo rumliegen

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

hallo,
hätt da auch noch in etwa das sortiment vom vdx, dazu noch einen fast neuwerigen toshiba libretto cw110 und einen panasonic m34.
gruss hd

... ich glaube, wir sollten den thread splitten oder aufräumen - das gehört wohl nicht mehr so ganz zu Slic3r

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

stimmt, denn slicen mit den alten dingern ist echt müssig
gruss hd

@Willy: wie entscheidest Du, ob ein Befehl überflüssig ist? Ich hab mir mal ein ähnliches Skript in Java geschrieben, das recht stumpf alle Befehle entfernt, die zu zu kurzen Linien führen würden - basierend auf einem anzugebenden Threshold.
D.h. dass z.B. alle GCodes entfernt werden, die zu einer Linie < 0.01mm führen würden. Machst Du das ähnlich? Hast Du bereits Erfahrungen, welche Thresholds sinnvoll sind?

Hi, so'n Sinclair zx81 wars glaub ich, Spectrum und ein paar Atari ST samt Nadeldruckern und Floppy-/ Kasettenlaufwerken dürften sich auch noch in meinem Elternhaus verstecken

Der aktuelle Slic3r stürzt mir am Mac sehr oft ab. Mit 0.9.3 gehts dann problemlos.

Gruß
Stefan

1-mal bearbeitet. Zuletzt am 18.11.12 17:28.

@schmelly:
Ich habe folgende Abfrage eingebaut:

if ((f3 = f2) and ((al+bl)*sin_phi < 0.05) and (cos_phi > 0) and (abs(e3 - e1) < 0.05)) or 
   ((f3 = f2) and (l2 < 0.001)) then begin  (* Punkt 2 ist überflüssig *)
   .
   .
end;

Dabei werden immer 3 aufeinanderfolgende Punkte betrachtet (Startpunkt erste Linie, Endpunkt erste Linie = Startpunkt zweite Linie und Endpunkt zweite Line). Im Detail:
1) Die Feedrate-Abfrage (f2 = f3) soll verhindern, dass "retracts" gelöscht werden.
2) al und bl sind die Beträge der Vektoren von Punkt 1 nach 2 bzw. von 2 nach 3
3) sin_phi und cos_phi sind - wie der Name schon sagt - der sin bzw. cos des eingeschlossenen Winkels von 2)
4) Die cos_phi Abfrage soll verhindern, dass "Spitzkehren" mit relativ langen Wegen gelöscht werden.
5) Die Extruder-Abfrage (e3 - e1) soll verhindern, dass der erste bzw. letzte Punkt nach bzw. vor einer längeren Geraden gelöscht wird.
6) Nach dem 'or' werden identische Punkte rausgeworfen.

Gelöscht werden also im wesentlichen "zuviele" Punkte bei kleinen Kreisen, die entstehen, wenn in OpenScad dxf-Dateien mit sehr unterschiedlichen Radien und mit $fn-Angabe eingelesen werden, da durch $fn kleine und große Kreise in dieselbe Anzahl Segmente aufgeteilt werden.

LG, Willy

---

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

Der alexrj hat gestern glaube ich einen Fix für das Problem comitted: [github.com]

>Der alexrj hat gestern glaube ich einen Fix für das Problem comitted: [github.com]

Mal sehen wie das funktioniert. Wenn ich das richtig sehe, dann wird eine Auflösung von 0,0125 angenommen, was 80 Schritten pro mm entspricht. Soweit so gut. Wenn aber bei kleinen Kreisen für jeden Schritt ein G1-Befehl generiert wird, dann ist ein 16 MHz Prozessor weiterhin überfordert.

LG, Willy

---

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

Esvt. kann ja Repetier diese "Bereinigung" in seine Software mit einbauen. DIe PCs haben ja genügend Rechenpower

Achim