Druckgeschwindigkeit und Temperatur

Hallo Willy,

wie testest du ob deine Bearbeitungszeit mit der Bearbeitungszeit des Druckers übereinstimmt?
Jedes Teil drucken um dann zu vergleichen ist ja etwas umständlich.
Ich vergleiche die Bearbeitungszeit, die mein Programm berechnet mit der Zeit die beim laden in Repetier Host angezeigt wird.
Nun würde ich gerne von dir wissen ob das bei dir immer genau übereinstimmt?
Bei einfachen Teilen so bei Zeiten von 1 Std. kommt es in etwa hin. Wenn ich die Datei für den Würfel, siehe oben, lade dann liegt meine Zeit ca. 25% höher als die von Repetier-Host angezeigte.
Inzwischen werte ich Linienzüge über mehrere Einzellinien möglichst exakt aus. Als Maß für ein mögliches Überfahren mit voller Geschwindigkeit prüfe ich auf einen Grenzwinkel. Den habe ich einfach mal ausgetestet mit ca. 10 Grad und komme damit teilweise auf sehr gute Übereinstimmung mit Repetier.
Hatte auch mal versucht dein Programm 1:1 nach PureBasic zu übertragen was jedoch nicht so einfach funktioniert.
Es gibt zwar alle Typen wie bei TP aber einige Funktionen sind anders und der Ansatz mit den vielen Arrays ist etwas unhandlich.
Zur Zeit arbeite ich mit einer einzigen Liste die das gesamte Programm aufnimmt und recht schnell bearbeitet werden kann.

EDIT: Habe den Hauptfehler gefunden. Ich vermute, dass die Zeitermittlung in Repetier Host recht ungenau durchgeführt wird. Wenn ich die Laufzeiten mit Cura vergleiche dann passen die über mehrere Stunden schon recht gut mit meiner Berechnung überein.

LG

Wolfgang

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

Hallo Wolfgang,

ich habe nur bei einem Teil die Druckzeit gestoppt und mit der Berechnung verglichen (Berechnung war bei 45 min ca. 1 min schneller). Ansonsten vertraue ich auf die Mathematik . Wenn ich bei längeren Drucken die Endzeit grob hochrechne, dann passt es immer ganz gut. Ansonsten habe ich auch die Erfahrung gemacht, dass die Vorhersagen von Printrun (verwende ich mit Skeinforge, einen Host brauche ich nicht, da ich nur von SD drucke) beliebig schlecht sein können.

LG, Willy

---

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

Moin moin aus HU.
Hallo Wolfgang.
Ich muß Dich noch einmal wegen Deines Programmes belästigen. Ist es möglich, das Programm so zu erweitern, dass man in der Farbzeile hinter den Farben noch 3 Felder hat, wo man zusätzlichen G-Code einbauen kann. ZB fahre Y auf 0, extruiere 30mm und drucke weiter. Das Programm müsste dann nur leere Felder ignorieren. So wird ja nur die Farbe umgestellt aber manchmal bei sofortigen Farbänderungen muß man den Düseninhalt austauschen oder bei kleinen Drucken auch mal warten.

lG

Frithjof

---

Liebe Grüße aus Kaltenkirchen.
Frithjof
Meine Seite
[www.facebook.com]

Hallo Frithjof,

du hast jetzt zwei weitere Möglichkeiten:
1. Du kannst in der Farbtabelle hinter jede Farbe drei zusätzliche Befehle einfügen die dann automatisch ins Programm eingefügt werden wenn diese
Farbe gesetzt wird.

2. du kannst jetzt in der Steuerdatei hinter der Zeile an Stelle des Farbcodes "HKS" die Kennung "BEF" schreiben damit wird der folgende Text als
Befehl nach der angegebenen Zeilennr eingefügt.
Willst du z.B. nach der Zeile 34 zusätzliche Befehle einfügen lassen dann einfach in die Steuerdatei schreiben:
34;BEF Befehl1
34:BEF Befehl2
34;BEF Befehl3

LG

Wolfgang

Moin moin aus HU.
Man, bist Du schnell. Entweder hast Du nen ruhigen Job oder bist so wie ich im Unruhestand.

Vielen Dank.

lG

Frithjof

1-mal bearbeitet. Zuletzt am 21.10.14 11:23.

---

Liebe Grüße aus Kaltenkirchen.
Frithjof
Meine Seite
[www.facebook.com]

Hallo Frithjof,

Unruhestand ist es nicht!
Beim ruhigen Job gehen die Meinungen auseinander!
Wollte dir erst schreiben, dass es machbar ist. Bei einer Bearbeitungszeit von ca. 15 Minuten für die Programmerweiterung macht es aber nicht so viel Sinn und da hab ich das Programm gleich mitgeschickt. Hoffe es ist in deinem Sinne
Vielleicht kannst du ja auch mal was für mich tun?
Möchte mir demnächst auch einen eigenen Drucker bauen und da kann ich Profis für die Unterstützung gut brauchen!

LG

Wolfgang

Moin moin aus HU.
Noch mal vielen Dank.
Vom Profi bin ich noch weit entfernt. Halt interessierter Laie. Aber wenn Du etwas brauchst, dann helfe ich immer im Rahmen meiner Möglichkeiten.

lG

Frithjof

PS.
Wenn Du das optisch und bedienerfreundlicher gestalten könntest, hätte ich da evtl eine Firma, die sich dafür interessiert.

1-mal bearbeitet. Zuletzt am 21.10.14 14:36.

---

Liebe Grüße aus Kaltenkirchen.
Frithjof
Meine Seite
[www.facebook.com]

Hallöchen zusammen!

Ich lasse mir gerade mal die Wege pro Schicht in meinem Analyseprogramm anzeigen.
Bei der Schraube M10 x 16mm sieht man sehr schön wie sich die Länge des Druckweges ändert.
In der ersten Ebene mit Skirt 799mm, dann Ebene 2,3,4 ca. 500mm wegen des Bodens.
Der Schraubenkopf hat pro Schicht ca. 148mm.
Dann kommt die Oberseite des Kopfes wieder mit einigen Schichten zu je ca. 410mm und
dann das Gewinde mit ca. 58mm.
Habt ihr einen Vorschlag wie man die Geschwindigkeit je Schicht setzen könnte um in Verbindung mit der optimalen Temperatur gute Ergebnisse zu erhalten?

LG

Wolfgang

Hallo Willy,

die Geschwindigkeit ändere ich nun Ebenenweise automatisch im gcode.
Ansatz:
Es gibt folgende Parameter: Mindestdruckzeit pro Ebene, minimale Druckgeschw., maximale Druckgeschw.
Berechnung welche Druckgeschwindigkeit sich bei der Mindestdruckzeit ergeben würde.
Ist die Geschwindigkeit unter der minimalen Druckgeschw. dann minimale setzen.
Ist die Geschwindigkeit größer als die maximale dann die maximale setzen.
Liegt sie dazwischen dann diese Druckgeschwindigkeit im Programm setzen.

Denke, dass es so ähnlich auch in Cura gemacht wird.

Jetzt wollte ich noch die Drucktemperatur setzen und dazu eine Frage:
Du hast ja die Strecke des Extruders aufaddiert und dann durch die Zeit geteilt.
Die Frage ist jetzt ob man auch einfach die Fahrwege aufsummieren kann bei denen extrudiert wird weil ich die sowieso schon berechnet habe.
Sollte egal sein weil ja die Extrudierwege fest an die Verfahrwege gekoppelt sind oder?

LG

Wolfgang

Hallo Wolfgang,

bei der ebenenweisen Änderung der Druckgeschwindigkeit geht aber der Unterschied zwischen Perimeter und Infill verloren? Der Infill wird üblicherweise deutlich schneller gedruckt, da es da nicht so auf Genauigkeit ankommt.

> Du hast ja die Strecke des Extruders aufaddiert und dann durch die Zeit geteilt.
> Die Frage ist jetzt ob man auch einfach die Fahrwege aufsummieren kann ...

Bei der Fahrwege-Lösung gehen die Retracts nicht mit ein. Ein Retract braucht merklich Zeit ohne Material zu fördern. In dieser Zeit kann sich das Hotend aufheizen und hat dann "Reserve" für den nächsten Strang.

LG, Willy

---

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

Hallo Willy,

zu Perimeter und Infill:
Das Problem ist, dass der Temperaturenwechsel mit 3 Sekunden pro Grad recht träge ist.
Es ist aber ja nur sinnvoll verschiedene Geschwindigkeiten für Perimeter und Infill zu verwenden wenn Infill deutlich schneller gedruckt wird als Perimeter.
Also z.B. Perimeter mit 20 und Infill mit 50mm/s.
Gehen wir mal davon aus, dass bei 50mm/s die Temp = 200 Grad und bei 20mm/s = 185 Grad gesetzt werden muss.
Damit beträgt die Zeit für die Temperaturänderung 45sek.!!
Das würde doch bedeuten, dass in dieser Übergangszeit die Temperatur entweder viel zu hoch oder viel zu gering ist und das Druckergebnis wird schlechter!
Damit geht doch der Sinn der ganzen Aktion verloren!

Selbst wenn man Infill so schnell druckt wie Perimeter ist es nicht so ganz einfach.
Zum Beispiel meine Lieblingsschraube M10x16
Eine Schicht oben am Kopf benötigt 8,6 Sek. bei V=47mm/s und eine Temp von 199 Grad.
Die nächste Schicht ist die erste vom Gewinde und benötigt 4,9sek bei v=11mm/s und einer Temperatur von 183 Grad.
Damit die Temperatur für das Gewinde passt müsste also schon 16 * 3 = 48 Sek. vorher die Temp von 183 gesetzt werden.
Da der Wechsel so lange dauert müsste er schon ca. 5 Schichten vorher gesetzt werden.
Das ist im Augenblick mein Problem, für welches ich noch keine richtige Lösung habe.

EDIT: Retractzeit
Bei einem Rückzugweg von 2mm und einer Geschwindigkeit von 40mm/s ergibt sich eine Zeit von 0.05 sek.
Selbst wenn man die Zeit verdoppelt für zurück und wieder vor sind das nur 0.1Sek.. Das ist nichts!

LG

Wolfgang

1-mal bearbeitet. Zuletzt am 26.10.14 09:10.

Habe gerade zwei Schrauben gedruckt. Eine mit einem Infill von ca. 20% und die andere mit 100%.
Geschwindigkeit automatisch zwischen 5 und 50mm/sec. und automatischer Temperatureinstellung mit einem Vorlauf von einer Schicht.
Sieht beides sehr gut aus.
Besonders der harte Übergang zwischen Schraubenkopf und Gewinde ist richtig gut!
Das geht schon in die richtige Richtung!

LG

Wolfgang

Quote
derschutzhund
Bei einem Rückzugweg von 2mm und einer Geschwindigkeit von 40mm/s ergibt sich eine Zeit von 0.05 sek.
Selbst wenn man die Zeit verdoppelt für zurück und wieder vor sind das nur 0.1Sek.. Das ist nichts!

Beim klassischen Wade wurden 10 mm/s empfohlen und Skeinforge macht u.U. sehr viele Retracts. Aber die Retracts wegzulassen hat zumindest den Vorteil, dass nicht genau nach einem Rückzug die Materialmenge berechnet wird und dann ggf. viel zu klein ist .

LG, Willy

---

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

Hallo Willy,

im Cura ist eine Geschwindigkeit von 40mm/s voreingestellt und ein Weg von 4,5mm.
Bei einigen Berichten von Usern sind diese Einstellungen für den Protos V2 so belassen.
Da Cura von Ultimaker unterstützt wird könnte ich mir vorstellen, dass der Rückzugsweg wegen des Bowdenextruders auf diesen relativ großen Wert von 4,5mm voreingestellt ist.
Ich habe ein wenig herumexperimentiert und bin da auf 2mm gekommen bei dem es gute Ergebnisse liefert.
Angeblich sollte die Rückzugsgeschwindigkeit so hoch wie möglich sein um optimale Ergebnisse zu bekommen.
Bei Cura hält sich die Retraction relativ in Grenzen wie ich finde.
Nur wenn man mehrere Teile gleichzeitig druckt findet sie natürlich häufig statt, was ich bisher noch nicht oft gemacht habe.

Werde jetzt erst mal wieder einige Testdrucke machen! Die Zeit für die Temperaturänderung muss ich für meinen Extruder auch mal genau ermitteln.
Könnte mir vorstellen eine Art Kombination zu nutzen:
1. Dauert die Änderung der Temperatur länger als die Druckzeit der vorhergehenden Lage dann wird die neue Temperatur am Anfang der vorherigen Lage gesetzt.
2. Dauert die Temperaturänderung nicht so lange wie die gesamte vorherige Lage wird innerhalb der Lage, bei der erforderlichen Zeit die neue Temperatur gesetzt.

LG

Wolfgang

Hi Wolfgang,

ein kleiner Tip für das schnelle runterkühlen des Extruders - wie der Name schon sagt - KÜHLEN
Ich mache das schon seit meinen ersten verzweifelten Druckversuchen.

Man kann dazu sehr gut einen Filament Kühler verwenden - man muss ihn nur entsprechend modifizieren, dass man damit auch das Hotend geziehlt abkühlen kann...

dann kann man auch sowas ohne GCODE Postprozesser drucken.... auch wenn das jetzt ein Beispiel ist, dass ich separat gedruckt habe (0,2er Layer) - das funzt auch mit dem dazugehörigen Arm und Body am Stück ....

oder der abgeschnittene Würfel - hier ist die Spitze das Interessante ....

viel Erfolg mit Deinem Postprozessor
Viele grüße
Gerhard

Hallo Gerhard,

kühlst du das Hotend ständig? Das macht man ja eigentlich nicht so gerne oder schaltest du einen zusätzlichen Kühler dazu?
Dann muss der ja wieder gesteuert werden.

LG

Wolfgang

Hallo Wolfgang,

Du kennst meine Kühler - die sehen nicht ohne Grund so aus..... und nein, kein zusätzlicher, ständiger Kühler für den Heizblock/Düse... geregelt allerdings schon.

Ich habe das inzwischen so gut im Griff, dass ich aktuell keine weiteren Verschlimmbesserungen plane

Gruß
Gerhard

1-mal bearbeitet. Zuletzt am 27.10.14 10:03.

Test von eben: Kegel 55mm Höhe, Durchmesser unten 42mm, Wandstärke 1mm, weißes Filament von GRRF
Berechnete Druckzeit 22min stimmt mit der wirklichen Druckzeit überein. Speed zwischen 45mm/s und 5mm/s
Die Geschwindigkeitsanpassung in Verbindung mit der Temperaturverteilung gefällt mir sehr gut. Alle Schichten sind sauber zu erkennen (0,2mm).
Nirgends zu heiß oder zu kalt.

Der Retract ist noch Mist. Bei jedem Ansatz kommt immer, schon sichtbar, etwas zu viel Filament.
Da muss ich noch fummeln

Wenn ich die Zeit stoppe die für das Heizen und Kühlen gebraucht wird, komme ich auf 10sek für 20 Grad, egal ob der Lüfter läuft oder nicht.
Dabei habe ich z.B. bei 160Grad die Heizung eingeschaltet, bei 180Grad die Messung gestartet und bei 200 Grad gestopt.
Kontrolliert man die Temperaturänderung direkt beim Drucken dann ändert sich die Temperatur von z.B. 190 auf 191 innerhalb von 2 bis 3 Sek.
Ich denke, das liegt daran, dass die Heizung selbst erst etwas braucht bis die volle Heizleistung zur Verfügung steht.
Damit wäre die Heizzeit nicht konstant und ändert sich von max. 3 Sek. pro Grad auf min. 0,5Sek. pro Grad!

LG

Wolfgang

Das 'Problem' ist ja nicht das Heizen, sondern das Abkühlen.

Kurze Zwischenfrage, wieso eigentlich PureBasic?
Für die Anwendung wären doch pearl(auch wenn ich es nicht mag), python, java, ... viel geeigneter?
vor allem würde das unter anderem für python ja schon gcode parser geben.

1-mal bearbeitet. Zuletzt am 01.11.14 01:45.

Warum PureBasic?
Es liefert extrem schnelle und kleine Programme!
Mein aktueller Postprozessor mit grafischer Oberfläche hat eine Größe von 134KB! Es sind keinerlei zusätzliche Libs oder dlls etc. erforderlich!
Keine Ahnung wie das geht, aber es ist absolut top!

Pearl, Java, Phyton sind alles interpreter und benötigen daher für die Ausführung immer eine Laufzeitumgebung!
Gerade Java hat den Nachteil, dass es teilweise langsam ist und du immer die passende Javaversion auf dem Zielrechner haben musst.
Das ist ein Krampf ohne Ende! Das ist ähnlich blöd wie die win.net - Programmierung. Damit bindest du dich stark an Windows und hast dafür eigentlich keine großen Vorteile. Auch was die Geschwindigkeit der Programmentwicklung angeht hatte ich noch keine Entwicklungsumgebung die schneller fertigen Code liefert.
PureBasic ist ein Crosscompiler und liefert damit ausführbare Programme für die drei großen Betriebssysteme Windows, Linux, Mac.
Für Purebasic gibt es ein "3D-Modul" mit der man extrem einfach 3D-Objekte darstellen und in Echtzeit drehen kann. Damit habe ich gestern in ein paar Stunden eben eine 3D-Darstellung meiner Druckobjekte in mein Programm eingebaut.
Den gcode-Parser für PureBasic hatte ich noch aus einem früheren Programmierung die ich mal für eine CNC-Anwendung geschrieben habe.

LG

Wolfgang

BTw interpreter und scriptspache nicht verwechseln.

welcher Zielrechner hat kein Java?
und passend muss die Version nur sein wenn du die neuesten Features auch verwendest, die VM selbst ist immer abwärtskompatibel.

Also in Zeiten in denen thingiverse seine items im 3D Modus im Browser darstellt braucht man in meinen augen nicht mehr über die Performance von 3D Darstellung sprechen, die relativ primitiven 3D Modelle die durch die aktuellen 3d Drucker laufen sind ja jetzt nicht wirklich eine Herausforderung für einen halbwegs aktuellen Rechner.
Abgesehen davon gibts es extrem performante 3D libs für Python und Java.

Genau weil eine Anforderung ja war Windows/Linux/Mac frage ich mich wieso crosscompilen wenn python, java das nicht benötigen, und die aktuellste java VM findest du eigentlich auf jedem Desktop rechner heutzutage.
Find PureBasic einfach unheimlich kompliziert zu programmieren bzw. bietet es viele Dinge im OO Bereich einfach nicht oder nicht so gut/schön.

aber ich glaub das passt hier nicht so rein war eigentlich nur eine interessens frage da ich eigentlich so noch nie von jemandem gehört habe der PureBasic benutzt.

2-mal bearbeitet. Zuletzt am 02.11.14 02:26.

Hallo mantus,

ohne jetzt eine Grundsatzdiskussion über die geeignete Programmiersprache hier im Forum für 3D-Drucktechnik anzufangen vielleicht noch eine letzte Info zu diesem Thema.
Natürlich kann man langsamere Programme erstellen wenn es schneller geht aber es macht aus meiner Sicht keinen Sinn! Es macht auch keinen Sinn große Programme zu erstellen wenn es kleiner geht. Ebenso wenig ist es für mich sinnvoll sich von einer Laufzeitumgebung abhängig zu machen wenn es ohne geht. Pearl, Java, Phyton benötigen alle Laufzeitumgebungen die ich vorher auf das System laden muss. Natürlich spielt es bei der Analyse von umfangreichen 3D-Objekten eine Rolle ob ich ein langsames oder schnelles Analyseprogramm habe. Die Idee bei Java war ursprünglich mit einem Code auf fast jeder Hardware lauffähige Programme nutzen zu können und natürlich auch für jeden Browser. Oft funktioniert das aber nicht weil, wie gesagt, die passende Javaversion vorhanden sein muss und was die Laufzeit angeht gibt es wohl keine Diskussion darüber das Javaanwendungen mit richtigen, ausführbarem Code nicht mithalten können.
Inzwischen gibt es schon wieder Programmierer die von Java zurück auf andere Entwicklungsumgebungen wechseln und zwar aus den obigen Gründen!
Zu langsam zu inkompatibel!
Natürlich gibt es immer verschiedene Philosophien! Wir leben in einer Überflussgesellschaft wo auch Rechenleistung und Speicherplatz scheinbar in Hülle und Fülle zur Verfügung stehen. Für mich macht es immer den Eindruck dass sich die Hardwareentwickler und die Softwareleute gegenseitig anheizen. Weil es soviel Rechenleistung und Speicher gibt machen sich die Softwareentwickler keine Gedanken und bringen Programme auf den Markt die neben dem Programm 1MB eine Laufzeitumgebung von 300 bis 400MB benötigen wobei das gleiche Programm auch mit 200KB ohne jegliche Laufzeitumgebung machbar wäre. Ich habe genau das mal bei einem Konfigurationsprogramm für mein Linuxsystem durchgespielt. Es geht dabei um ein Linux welches ich in unserem Technikbereich in der Schule einsetze. Am Ende bin ich dann bei PureBasic gelandet. Vielleicht liegt es auch daran, dass ich halt schon ein paar Jahre auf dem Buckel habe und sowohl beruflich als auch hobbymäßig einiges erkundet habe darunter waren Assembler, Turbopascal, verschiedene Basicsysteme, Delphi, Lazarus, Java mal ganz kurz, Phyton ebenfalls kurz, HTML und CSS, und jetzt halt PureBasic.

Quote
Find PureBasic einfach unheimlich kompliziert zu programmieren bzw. bietet es viele Dinge im OO Bereich einfach nicht oder nicht so gut/schön.

Gerade das kann ich nicht bestätigen. Ich habe noch nie mit einem System gearbeitet das so schnell und einfach vergleichbare Ergebnisse liefert!
Das PureBasic so relativ unbekannt ist mag an der Art der Vermarktung liegen, ist mir aber absolut egal!

LG

Wolfgang

naja ich seh das anders rum
wozu ein schnelleres programm schreiben wenn der nutzer davon nichts mitbekommt?
wozu ein kleineres programm schreiben wenn es keinen nutzen für den benutzer bringt?

Was einen nutzen für den Benutzer bringt ist eine angenehme Oberfläche, Fehlersicherheit, ......
und da bietet z.b. PureBasic sehr "wenig", und jeder hat heute eine java umgebung sowieso auf seinem Rechner und solang du keine Spezialfunktionen der neuesten Version verwendest, ist auch die Java Version kein Argument, da sie zueinander kompatibel sind. Also deine angeführten negativen Eigenschaften sind so einfach nicht richtig.

Und es kann sein das man in purebasic sehr schnell brauchbare einfache sachen bekommt, ich habs einmal für ein Projekt an getestet, und muss sagen sobald es in die höhere Funktionalität ging wurde es plötzlich unnötig kompliziert, ich fühlte mich an Zeiten von MFC erinnert. Da bieten moderne GUI Frameworks in Java oder auch in C++ mit QT z.b. xfach mehr komfort.

du arbeitest ja anscheinend schon länger mit purebasic, gibt es vergleichbare GUI frameworks wie z.b. QT für C++ ? ich habe damals nichts gefunden und habs dann eben mit QT gemacht.

aber egal wollte keinen Glaubenskrieg auslösen oder so, lieber wieder back to topic.

Eine dumme Frage von einem Neuling sei erlaubt: Geht es hier noch weiter oder hat es allen die Sprache verschlagen?
Ein brauchbares Programm dass das Drucken (die Ergebnisse) verbessert wenn man es nur mit ein paar einfachen (auch für Anfänger) zu ermittelnden Daten füttert wäre doch das worauf gerade ein Anfänger, und sicher nicht nur der, gewartet hat.
Jede Programmiertsprache hat Vor- und Nachteile, es ist aber wirklich so das Programme die fast das Selbe machen wie vor 10 Jahren heute immer größer werden und mehr Rechenpower brauchen wenn sie denn stabil laufen sollen.
Wenn das hier vorgedachte schon als "Werkzeug" vorliegt, dann her damit.
Ich hoffe das ich jetzt keinen auf den Schlips getreten bin und nicht gesteinigt werde.

---

Velleman 8200. Arduino Mega2560, Ramps v1.4 mit RepRapdiscount Full GraphicDisplay, MK2B, 1,75 mm Direcktextruder (China), Optische Endstops für Min und Max, 2X16A 12V Netzteil, Doppelkühlung mit Luftführung, 2 Z-Achse mit Motor wie andere Seite und demnächst Leveling.

Quote
Harry2006
Ich hoffe das ich jetzt keinen auf den Schlips getreten bin und nicht gesteinigt werde.

Hier herrscht teilweise ein rauher Ton, da musst du dich schon mehr anstrengen.
Gesteinigt wirst du höchstens für die Leichenfledderei, schau mal auf das Datum

---

Best regards / Viele Grüße
Till

Habe ich doch glatt übersehen da hatte ich noch keinen Drucker. Das Thema ist aber gut und ich weis nicht warum es so abrupt geendet hat....ich hatte schon gedacht das ich überlesen habe wo es weiter geht.
Sollche Basic´s wie Temperatur, Geschwindigkeit und Erfahrungen mit Einstellungen oder Material sind besonders für Anfänger interessant.
Mal sehen vielleicht greift einer das Thema auf.
Womit muß ich mehr anstrengen? rauher Ton ist ja OK solange man seine Kinderstube (wenn Vohanden) nicht vergisst.

Ich hoffe das ich jetzt keinen auf den Schlips getreten bin und nicht gesteinigt werde.[/quote]

Hier herrscht teilweise ein rauher Ton, da musst du dich schon mehr anstrengen.
Gesteinigt wirst du höchstens für die Leichenfledderei, schau mal auf das Datum [/quote]

1-mal bearbeitet. Zuletzt am 07.07.16 06:59.

---

Velleman 8200. Arduino Mega2560, Ramps v1.4 mit RepRapdiscount Full GraphicDisplay, MK2B, 1,75 mm Direcktextruder (China), Optische Endstops für Min und Max, 2X16A 12V Netzteil, Doppelkühlung mit Luftführung, 2 Z-Achse mit Motor wie andere Seite und demnächst Leveling.

Daher ist es ja auch sticky, das hatte ich übersehen.
Aber wenn so ein Thread erstmal im OT ist kommt da meist auch nicht mehr viel...

---

Best regards / Viele Grüße
Till

Richtig böse gehen wir allerdings nur mit den Leuten um welche nicht richtig zitieren können.

---

Gruß,
Steffen

Geetech Full-Acrylic Graber Air V3 SteBa Edition, v6 J-HEAD v5 E3D Custom Hotend, 230v Induktionskochfeldheizplatte mit Aceton Beschichtung, Rumpsbaradds 64-Bit AliExpress Edition, Softeisextruder

Ich bin schon auf dem Weg nach Canossa......

---

Velleman 8200. Arduino Mega2560, Ramps v1.4 mit RepRapdiscount Full GraphicDisplay, MK2B, 1,75 mm Direcktextruder (China), Optische Endstops für Min und Max, 2X16A 12V Netzteil, Doppelkühlung mit Luftführung, 2 Z-Achse mit Motor wie andere Seite und demnächst Leveling.