Wenn unsere Theorie richtig ist, dann hat das mehr mit der Verweilzeit in deiner Schmelzkammer zu tun!

Die richtige Antwort dazu wäre:
Du brauchst eine größere Schmelzkammer. (E3D Vulkan?).
Mit der Temperatur zu weit hoch zu gehen rate ich dringlichst ab.

Versuch mit 25 bis 30 mm/s zu drucken.
Spiel einfach damit.
Die Wärme braut Zeit um dein Material aufzuheizen.

LG AtlonXP

Ihr könntet recht haben.

Ich konnte mit 0.8er Stahldüse und grob 225/230°C PLA (!) nicht schneller wie 60mm/s drucken - bei 70mm/s sind mir bereits die Spuren abgerissen.
-> Ich habe eine 50 Watt Kartusche im E3D-V6-Hotend. Das V2 hat glaube ich nur 34? 30? 25? Watt? (Steht irgendwo.)

Mit dem folgenden Bild will ich sagen, dass ich während des Druckens fürs Aufschmelzen ca. 20 Watt Heizleistung gebraucht haben muss.
Als ich vor Weihnachten meine Blumentöpfe gedruckt hatte, hab ich beobachtet, wie sich der Leistungsgraph unter der Temperatur verändert. Meine Notiz zum Bild war: 50W kartusche, 0.8er Düse, PLA rot, 50mm/s max.

Genaue Aussagen kann ich nicht treffen, aber ich nehme an, dass man mit PVA+V2 in jedem Fall kleiner <<< 50mm/s einplanen müsste? PLA ist bei den Temperaturen voll durchgeschmolzen schon ziemlich flüssig, PVA kenne ich nicht so gut.
25mm/s könnte also schon ein guter Hinweis sein?

Die 0.8er Düse habe ich voll liebgewonnen. Alles geht ratzfatz und auch das schlechteste Material ist sofort alle
Der Tipp mit Flex auf 0.8er Düse drucken fand ich genial! Das teste ich die nächsten Wochen mal.

LG

Ich hatte mal testweise kurz 230°C mit dem Material verdruckt, da meine ich aber ein extrem starkes Blasenwerfen beobachtet zu haben.
Allerdings war das damals auch ein etwas älteres Filament, das schon 3-4 Wochen offen rumstand.

Retracts sind bei meinen PVA Teilen eigentlich gar nicht vorhanden und dementsprechend vernachlässigbar.

An Nibbels:
Ich habe übrigens auch das e3dv6 Hotend, allerdings mit der 40W Heizkartusche und nicht das V2 Hotend verbaut.


Mit Ninjaflex konnte ich mit der 0,8mm Düse wirklich sehr gute Ergebnisse erzielen.
Zudem habe ich sehr geringe Temperaturen benötigt, weshalb ich wenige Probleme mit Fäden hatte und sehr matte und optisch ansprechende Druckergebnisse bekommen habe.

Wenn dem so ist, bist du in der Konfiguration mit dem Material an der Grenze. Kann jetzt wirklich an der "Überlagerung"
liegen, oder es ist einfach zu heiß für das Material im direkten Kontakt. Dann kannst wirklich nur noch mit dem Tempo arbeiten...
25 mm/sec ist bei 0,8er Düse ja jetzt auch nicht sooo langsam. Klar, 40 wäre schöner, aber das Pakts wohl nicht mehr.
Wie gesagt, eine immense Menge, die da pro sekunde verflüssigt werden muß...

Zur Not kannst du ja immernoch mal mit der 1.39 oder 1.38 (/7) testen.
Wenn es da nicht auftritt, hätten wir was.

Das was du als zickzack beschreibst ist tatsächlich so, aber im Step-Bereich.
Also bei X und Y ca. im 152stel Millimeterraster und beim Extrudieren mit 3:1 vermutlich ca. als 960stel mm.
Die Z-Achse wird mit 2560stel/mm angesteuert.

Sollte es wirklich am Aufschmelzprozess liegen:
Was du definitiv tun könntest, wäre den Vulcano zu testen
Dafür bräuchtest du vermutlich eine höhere Z-Schraube, du würdest etwas Z Bauraum verlieren, aber dieses E3D-Hotend ist genau für sowas entwickelt worden.
Ausserdem stehen wir mit 3mm-Filament schon besser da, als bei 1.75, weil sich gleichzeitig ~3x (3² / 1,75² = ~3) mehr Materialvolumen im Hotend befindet als bei den 1,75ern. Dass die Temperatur bei 3mm im Vergleich zu 1,75 länger braucht, um bis in die Mitte des Filamentes einzusickern macht angeblich nicht so viel aus - 3mm ist für hohen Materialfluss besser.

Hallo,
ich schreibe hier ohne irgendeinen Verdacht zu äußern.

Mein Problem ist, der RF1000 bleibt gelegentlich kurz, für etwa 5 sec., stehen bei dem Drucken.
Dies ist der Fall, obwohl ich meine Baudrate bereits auf 115000 Baud erhöht habe.

Da sich an meiner Schlepptop Gurke Programmmäßig, in letzter Zeit auch einiges geändert hat,
kann ich deswegen nicht mal einen Verdacht äußern.
Von SD Karte drucken, möchte ich erst gar nicht anfangen.
Früher ging das mit 38000 Baud sogar besser.

Deshalb hier meine Fragen:
- Hat hier noch jemand so ein Problem?
- Wie gehe ich Systematisch vor?

Ich glaube am Pufferspeicher vom Drucker sollte man anfangen.
Am Windows Treiber habe ich vor ca. 1 Jahr ein Update gemacht.

Für Infos und Ratschläge bin ich Dankbar.
Im Moment bin ich noch bei der FW 1.38.08 mit S3D V4.0.0

LG AtlonXP

AtlonXP hat geschrieben:Mein Problem ist, der RF1000 bleibt gelegentlich kurz, für etwa 5 sec., stehen bei dem Drucken.
Dies ist der Fall, obwohl ich meine Baudrate bereits auf 115000 Baud erhöht habe.

Das Problem hatte ich früher, als ich den RF1000 neu hatte (und es noch keinen Mod der Firmware gab) immer. Deswegen drucke ich ausschließlich von SD-Karte, da gibt's das Problem nicht.

Ich würde wenn dann versuchen, die Baud-Rate niedriger einzustellen. Ich glaube kaum, dass die Datenrate ein großes Problem ist sondern eher Übertragungsfehler, so dass die Übertragung erneut versucht werden muss (macht er das eigentlich? Sonst ist das natürlich Quatsch). Am wahrscheinlichsten ist, dass dein Computer zwischendurch einfach hängt und keine Daten sendet.

Pufferspeicher ist so eine Sache. Der Microcontroller hat einfach nicht so wahnsinnig viel RAM... Vielleicht müsste man einen Modus einführen, bei dem die SD-Karte quasi als Pufferspeicher genutzt wird. Der G-Code wird so schnell wie es geht auf die SD-Karte geschrieben und der Drucker fängt nach kurzer Wartezeit schon mal an (also noch während geschrieben wird), die Daten von der SD-Karte zu drucken.

Man muß ja die SD Karte nicht mögen. Aber wenn solche Probleme auftreten wäre es ratsam, den Schuldigen an der Misere ausfindig zu machen. Und da hilft einfach, mal einen Druck über SD Karte zu versuchen. Die beißt auch nicht, also da besteht keine Gefahr. Wenn dann die Probleme immer noch da sind, liegt es im Drucker, ansonsten in der Kommunikation, was leider sehr häufig passiert. Dann liegt es aber meistens am PC und am Kabel.

Vernünftige Anschlüsse vorausgesetzt, sollte man an den 115000 nicht drehen. Die Hardware und auch das Shaking im Arduino sind nunmal auf 115000 optimiert.

PeterKa

Ja gut, ihr habt ja Recht…
Bei Gelegenheit werde ich einen Druck von der SD Karte machen.
Vorher jedoch das Log. Speichern und durchforsten.
Mal sehen ob er dabei noch öfter stehen bleibt.

Meine Baudrate war wegen dem alten S3D auf 38 400 Baud eingestellt.
S3D hatte damals Probleme mit der Übertragung, es gab damals Fehler und der Drucker fuhr gegen die Wand. (rrrrrrrr………)
Das macht er heute nicht mehr.

LG AtlonXP

Servus

Ich halte persönlich noch nichts davon, dass man die Baudrate wegen dem Verdacht auf Übertragungsfehler drosselt. Meiner Einschätzung nach ist die Länge der seriellen Leitung auf der RFx000-Platine so kurz, dass eigentlich die serielle Verbindung bei diesen Standard-115200baud funktionieren sollte. (Ich habe aber das fertige Platinenlayout nicht untersucht und die Länge nicht nachgemessen.) OK, man kann die Verbindung auf einer Platine nicht Eins zu Eins mit einem geschirmten Twisted-Pair-Kabel vergleichen. Trotzdem finde ich den Ansatz unbefriedigend.
(Weiß jemand mehr aus der Praxis?)
Würde man nicht eventuelle Übertragungsfehler in der Log sehen?
Stichwort: "Checksum Error: Resend N223 ..."

Background:
PC->USB-Port -> Kabel auf USB-B am Drucker -> USB-to-Seriell-Chip von FTDI auf der Platine -> kurze Rx-Tx-Leitungen zum Arduino-Mega 2560.
Der Löwenanteil der Übertragungsstrecke ist USB, nicht RS232.

Wenn der Drucker zu langsam neue GCodes bekommt, drosselt er seine Geschwindigkeit. Intern gibts diesen 16-Plätze-MOVE_CACHE und wenn dessen Füllgrad unter 10 oder ähnlich sinkt, dann will der Drucker die Druckgeschwindigkeit automatisch drosseln.
Das wird vermutlich dann passieren, wenn zu viele extrem kurze Pfadstücke reinkommen, bei hoher Sollgeschwindigkeit -> vorallem bei Rundungen, Micro-Zick-Zack.

Was mich wundert:
Warum funktioniert das Drosseln der Seriell-Geschwindigkeit? Kann gut sein, dass das Zockeln weg ist, weil man mit 19200/38400 baud in Rundungen den MOVE_CACHE fast nie voll bekommt und der Drucker damit immer drosselt?
Kann gut sein, dass mit 115200 Baud der Drucker im Grenzfall wechselnd über und einmal unter dem MOVE_CACHE-Limit landet und darum anscheinend stottert?

Lösungen/Lösungsansätze die mir spontan einfallen:
Angreifen an der Quelle:
- Genauer nachschauen, ob die Firmware in manchen Situationen dem jeweiligen Host ungünstig antwortet? (Ich dachte mal gesehen zu haben, dass Quittierantworten für die erledigten GCodes im Block gesendet werden, bin mir aber nicht mehr sicher.)
- Die Geschwindigkeit nur langsam oder beim Eingang von längeren Pfadstücken steigern, wenn einmal gedrosselt wurde (Ist das schon so?).
- Nachschauen, ob die Geschwindigkeits-Drosselung zu aprupt/ungünstig sein könnte?
- Prüfen ob das Abremsen durch unsere eingestellte maximal Beschleunigung unsauber funktioniert. (Weil es theoretisch sein könnte, dass bei winzigsten Pfadlängen im Fall eines leer werdenden MOVE_CACHE dieser MOVE_CACHE trotz Drosselung leer läuft, weil die Geschwindigkeit wegen der Maximalbeschleunigung nicht schnell genug gesenkt werden kann?
- Zum Druckstart wird evtl. gewartet bis der MOVE_CACHE genug gefüllt ist. Passiert das u.U. auch mitten im Druck?
- Sonstige Bugs?

Kaschieren:
- Im Slicer (feinste Stücke nicht ganz so detailiert ausführen? Mindestlänge?)
- Im Slicer (Bei vielen Pfadstücken/Weg Geschwindigkeit runter.)

Vermeiden:
- Wenn nichts geht kann SD-Lesen wirklich schneller sein.
- Die CPU-Auslastung des Host-PCs prüfen, wenn das Zockeln auftritt./Andere Geräte am USB-Hub zum Drucker abstecken, falls das so ist (??)

@AtlonXP, wenn du nachweisen kannst, dass es beim selben GCODE mit SD-Karte ruckelfrei funktioniert und mit USB nicht, wäre das interessant

LG