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
