Weiß jemand den genauen Wert für die Eingangspuffer Bytes / Empfänger Cachegröße, welcher für RF2000-Drucker v1.33 gültig ist?

Repetierhost sagt in seiner Grundkonfiguration 63bytes.
Repetierserver schlägt automatisch 127bytes vor.

Es geht um diese Werte, jeweils bei den Tooltips: Der Grund für die Frage ist, dass ich meine Bedenken bezüglich des Standardvorschlags hier:
http://www.rf1000.de/viewtopic.php?f=74&t=1302#p15139
noch nicht ausräumen konnte und in den letzten Tagen komische Fehler auftraten.
- Mir drängt sich nun auf, dass die Kommunikation mit Wert 127 nicht sauber läuft.
- Dass die USB-Verbindung mit dem Raspberry PI ansich nicht sauber läuft.
- Oder dass der Drucker bei großen Geschwindigkeiten irgendein Problem hat. Doch eigentlich sagt die reine Druckgeschwindigkeit nichts darüber aus, wieviele Befehle pro Sekunde an den Drucker gesendet werden müssen, eher die Bauteilform.
- Oder dass bei Slic3r mit speziellen Speedsettings irgendwas falsch läuft.
- Oder dass irgendwie wegen einem anderen Overflow (???) die Firmware mist baut.
- Dass mein Board bei höherer Leistung instabil ist.

Da ich mir wegen dem Eingangspuffer / der Empfänger Cache-Größe nicht sicher war, will ich erstmal dieses Thema angehen.
Nun habe ich von 127bytes auf 63bytes umgestellt.
Ich werde genau beobachten, ob mit 63 Bytes solche Probleme zukünftig nicht mehr vorhanden sind, doch wenn jemand den besten theoretischen Wert für den Cache weiß, ist das unter Umständen sehr hilfreich.

Um auszuschließen, dass mit dem Drucker selbst etwas nicht stimmt, versuch doch mal von der SD-Karte zu drucken. Da kann es ja kein Kommunikations-Problem geben. (Ich drucke nur noch so, da sonst gelegentlich der Druck stockt, was zu hässlichen Knubbeln auf der Oberfläche führen kann - hab es aber lang nicht mehr probiert, war vielleicht ein Problem mit der alten Default-Baud-Rate.)

mhier hat geschrieben:, da sonst gelegentlich der Druck stockt, was zu hässlichen Knubbeln auf der Oberfläche führen kann

Das ist hochinteressant. Das werde ich beobachten.

Solche Knubbel? Oder eher Welligkeit in der ersten Lage / beim Toplayer? (Auch ich hatte mal sowas gesehen und durch Verlangsamung lösen können. Es hat sich hier aber um komische Geschwindigkeitseinstellungen gehandelt - )

Zum SD-Test:
Mir ist eingefallen, dass ich den G-Code nicht versehentlich gelöscht habe, weil er noch auf der SD-Karte lag!
Also hatte ich das im Stress getestet! (Ausschluss, dass es am Repetierserver lag)
Und es hat auch davon nicht funktioniert.

Ergo ist nicht zwingend der Eingangspuffer schuld.
Wenn mein Druck fertig ist, teste ich das nochmal und sollte der Drucker anhalten, lade ich den G-Code hier hoch.

Das mit dem Druck hat sich eben erledigt.
Ich saß neben dem Drucker, dann war auf einmal Ruhe.
Fast an derselben Stelle, oder ein paar Layer daneben hat der Druck gestoppt. So wie wohl heute Nacht.

Sofort Kamera ausgepackt ...
https://www.youtube.com/watch?v=8MjBQ1T ... e=youtu.be

Ich glaube, der Drucker war ganz einfach abgeschmiert.

Während dem Video wurde mir klar, dass der Drucker das Heizbett bis 171°C (Siehe Log-Tab nach Reset) aufgeheizt hatte. Auf dem Display stand vor dem USBinduzierten-Reset dauerhaft 59/55°C (Minute 3).
Beim "Aua" habe ich mir gehörig die Finger verbrannt, der Stepper war aktiv, ich konnte das Heizbett nicht zurückschieben (Y).
Als ich das gemerkt hatte, war aber wohl durch den Reset durch USB abziehen die Temperatur schon wieder gefallen.
Man sieht das schon vorher an den Logs.

15:07:48.536: Warning: Communication timeout - resetting communication buffer.
15:07:48.536: Connection status: Buffered:62, Manual Commands: 2, Job Commands: 5000
15:07:48.537: Buffer used:62 Enforced free byte:19 lines stored:4
15:08:19.539: Warning: Communication timeout - resetting communication buffer.
15:08:19.539: Connection status: Buffered:56, Manual Commands: 2, Job Commands: 5000
15:08:19.539: Buffer used:56 Enforced free byte:19 lines stored:4
15:08:50.541: Warning: Communication timeout - resetting communication buffer.
15:08:50.541: Connection status: Buffered:56, Manual Commands: 2, Job Commands: 5000
15:08:50.541: Buffer used:56 Enforced free byte:19 lines stored:4
15:08:50.541: N343835 M117 ETA 17:02:23 day 8
15:08:50.541: N343836 M105
15:08:50.542: N343837 M105
15:08:50.542: N343838 G1 X84.482 Y156.801 E10.2465
[...]

Kann irgendwer mit dem, was man in der Log und dem Video sieht, was anfangen? Diagnose?

Test der ersten Datei (schneller Druck)
von SD_Karte: Fail!
Edit: Auch ohne angestecktes USB gehts nicht. Stop an derselben Stelle.


https://youtu.be/FduvCaxhk04
Im Anhang wäre der G-Code.

Ich bin über jede Hilfe ziemlich dankbar, weil gerade kaum noch was funktioniert und ich den Grund nicht begreife.

Stürzt mein RF2000-Board ab, weil es defekt ist oder überlastet wird??
Sind dort G-Codes in der angehängten Datei die keinen Sinn machen?

Nibbels hat geschrieben:https://youtu.be/FduvCaxhk04

This video is private...

Nibbels hat geschrieben:Solche Knubbel?

Ja genau! Vielleicht waren sie bei mir nicht ganz so häufig, aber damals hab ich auch viel mit ABS gedruckt (weniger oozing).

Ein kurzer Blick auf deinen G-Code zeigt mir nichts Auffälliges, aber bei 150000 Zeilen ist das natürlich schwer zu sagen... Wenn er aber mittendrin abbricht, würde ich vermuten, dass es nichts mit dem G-Code zu tun hat (da kommt ja immer nur "G1..." und zwischendurch "G92 E0", das dürfte bei jedem so aussehen). In jedem Fall sollte der Drucker nicht abstürzen, egal welchen G-Code du ihm schickst.

Ich dachte eigentlich immer, der Drucker hat einen Watchdog, d.h. er wird hardwareseitig resettet, wenn er sich aufhängt (sprich, wenn die Software zu lange den Watchdog-Timer nicht zurückgesetzt hat). Wenn selbst das nicht funktioniert, würde ich auf ein defektes Board tippen. Nimm doch mal Kontakt mit dem Conrad-Support auf. Da es ein RF2000 ist, musst du ja noch Garantie haben

mhier hat geschrieben:

Nibbels hat geschrieben:https://youtu.be/FduvCaxhk04

This video is private...

-> Jetzt nicht mehr. Ich hatte nicht auf Publish geklickt



Also mir ist jetzt völlig klar. Dieser Fehler ist kein Fehler, der sich festnageln lässt.
Da liegt eine Instabilität vor, die ich durch Ausführen des angehängten Gcodes provozieren kann. Es kommt mir so vor wie eine Überlastungsreaktion. So nach "Energielevel überschritten = Error"

Sobald der Fehler "da ist" spinnt der Drucker.
Dann macht er die wildesten Sachen.

Da piept er nur noch:
https://www.youtube.com/watch?v=dOWgNSP ... e=youtu.be
(Ich kurz nach dem Error eine Taste gedrückt, dann hat er angefangen zu piepen)

Da wird klar: Der bricht nicht exakt an derselben Stelle ab. Und zwar inmitten eines geradlinigen Gcode-Befehls.
https://youtu.be/S6hdpHT1phk

Ich glaube, ich brauche Support, da hast recht.

LG

Er hängt sich ja auch nicht komplett auf, die Anzeige aktualisiert sich noch. Deswegen greift der Watchdog nicht Kommst du noch ins Menü? Zeigt er was besonderes im Log? Welche Firmware verwendest du?

Es ist die Firmware 1.33 (Keine Mod)
Welche Log meinst du? Die im Repetierserver oder die im Repetierhost. Gibts noch eine?

Meist startet der neu. Für mich würde das heißen, der Watchdog greift.
Heißt: Flackern (teilweise gehen die LEDs aus und wieder an) und ich sehe die Firmwareversion aufblinken. Dann ist er "wieder im Menü".

Selten gibts so verrückte Sachen wie "bleibt stecken", Heizt ungebremst, Piept dauernd.

Das ist irgendwie so, als hätte man ein Laptop, das beim zocken oder bei belastenden Programmen abstürzt, sonst aber läuft.
Drucke ich sehr gemütlich, funktioniert er.

LG

Bezogen auf:
ERROR_PLA_LINKS_LAYER1_3840_3.RAR -> ERROR_PLA_LINKS_LAYER1_3840_3.GCO

Speed-Multiply: 80% -> läuft durch.
Speed-Multiply: 90% -> läuft durch.
Speed-Multiply: 95% -> läuft durch.
Speed-Multiply: 98% -> läuft durch.
Speed-Multiply: 99% -> läuft durch.
Speed-Multiply: 100% -> Fail!
Speed-Multiply: 99% -> läuft durch.
Speed-Multiply: 100% -> Fail!
Speed-Multiply: 101% -> läuft durch. ??
Speed-Multiply: 100% -> Fail!
Speed-Multiply: 120% -> läuft durch. ??
Speed-Multiply: 150% -> läuft durch. ??

Speed-Multiply: 100% -> Fail!
Speed-Multiply: 203% -> läuft durch. ??


Also an der Leistungselektronik wird das nicht liegen, das ist irgendwas mit der Software.