1 von 2 Druckern stoppt (Communication timeout)
Hi,
vielleicht hat hier jemand ja eine Idee...
ich habe an meinem Raspberry Pi3b einen Anycubic i3 Mega und seit vorgestern einen Sunlu S8 mit repetier zu laufen.
Der Anycubic druckt einwandfrei (seit Monaten) nur der Sunlu S8 stoppt immer wieder beim Druck und im Log ist dann ein Communication Timeout) zu sehen.
Hier mal ein Beispiel aus dem Log:
Send:22:28:14.479: N129041 G1 X156.961 Y119.31 E1721.56295
vielleicht hat hier jemand ja eine Idee...
ich habe an meinem Raspberry Pi3b einen Anycubic i3 Mega und seit vorgestern einen Sunlu S8 mit repetier zu laufen.
Der Anycubic druckt einwandfrei (seit Monaten) nur der Sunlu S8 stoppt immer wieder beim Druck und im Log ist dann ein Communication Timeout) zu sehen.
Hier mal ein Beispiel aus dem Log:
Send:22:28:14.479: N129041 G1 X156.961 Y119.31 E1721.56295
Recv:22:28:14.486: ok
Send:22:28:14.486: N129042 G1 X156.821 Y119.021 E1721.57363
Recv:22:28:14.500: o- ok
Mesg:22:28:18.505: Warning: Communication timeout - resetting communication buffer.
Mesg:22:28:18.505: Connection status: Buffered:88, Manual Commands: 0, Job Commands: 5000
Mesg:22:28:18.505: Buffer used:88 Enforced free byte:45 lines stored:2
Send:22:28:18.505: N129043 G1 X156.719 Y118.721 E1721.58417
Send:22:28:18.506: N129044 G1 X156.654 Y118.407 E1721.59484
Hat jemand eine Idee woran das liegen könnte?
Gruß vom verzweifelten Christian
Hat jemand eine Idee woran das liegen könnte?
Gruß vom verzweifelten Christian
Comments
when it stopps printing in the log i see an Communication Timeout.
part of logfile:
i tried with input buffer size 127 and 63, with and without ping pong, timeout up to 8 seconds, rts "low to high" and also "low" but the Sunlu still stopps several times.
Is there any idea to solve my problem?
best regards,
Christian
Recv:22:28:14.500: o- ok
Das sollte wohl "ok" heißen wurde aber bei der Übermittling verstümmelt. Jetzt wartet der server aber auf das "ok" und wenn es nicht kommt nimmt er an es wurde verstümmelt und gibt die timeout Meldung aus und macht weiter.
Frage ist wo werden warum die Daten manipuliert. Normal is das nur "o" oder "k" ankommt. Das da 3 Zeichen davor sind ist eher ungewöhnlich.
Du solltest die drucke loggen und sehen ob da immer der gleiche falsche text kommt. Dann kannst du dem Server das als "ok" beibringen. Wenn es zufällig ist was er draus macht ist es schwieriger.
Auch prüfe mal ob du resend anweisungen findest. Das kommt wenn die Prüfziffer wegen Übertragungsfehler nicht stimmt. Dann ware die Kommunikation einfach gestört und du solltest usb kabel tauschen und evtl im Drucker gucken wie die Kabel liegen das da falsche signale kommen. Wobei das eigentlich alles auf der Platine geschieht aber wenn die Heizleitungen zum beispiel zu nah kommen könnten die stören.
<response type="ok" value="-1">^ok\s*N?:?(\d*+)?</response>
Das ist was als "ok" interpretiert wird. Die Regel kann man anpassen oder neue hinzufügen wenn es ein muster gibt. Nach einem neustart des servers werden die dann genutzt und auch als "ok" gewertet. Nehme hier an das die Firmware Marlin ist auf dem Drucker.
Könntest du mir eine entsprechende Zeile machen die ich einfügen kann? Ich es läuft gerade ein druck, da kann ich dann im Anschluss schauen obs immer gleich ist.
Recv:21:34:18.036: o- T:210.04 /210.00 B:49.85 /50.00 @:60 B@:0
b)
c)
gruß christian
<response type="ok" value="-1">^o-</response>
Sollte also hier iene deutliche Verbesserung bringen.
ich habe es jetzt mal eingetragen und werde gleich testen und rückmeldung geben.
Gruß und Danke,
Christian
ich hatte jetzt noch zwei timeouts:
und
da ist ja theoretisch das ok, aber augenscheinlich leider nicht an der passenden stelle. hab ich da noch irgendeine chance etwas gegen zu machen?
Hätte die 2 auch abgefangen. Aber jede anntwort die mit "...ok" aufhört wird dann auch als ok gewertet was dann evtl zu einem com fehler führt, der aber schneller repariert wird. Außerdem ist es eher unwahrscheinlich das eine Zeile so aufhört, wenn auch nicht unmöglich.
Du solltest mal in Konsole ack aktivieren und
G4 S20
senden. Wenn du dann busy: ... siehst kannst du noch dein timeout auf 3 Sekunden reduzieren. Dann ist die Pause im Falle eines Falles immerhin minimal und richtet auch keinen Schaden an.
Vielleicht kann ich dir ja mal ein logfile schicken? Habe gerade ein relativ kleines wo er schon beim skirt mehrfach stoppt.
Habe mittlerweile auch das 3. USB Kabel verwendet und es ändert sich leider nichts. Auch das funktionierende vom i3 Mega habe ich verwendet, jedoch ohne Veränderung.
Gruß Christian
Aber er scheint ja grundsätzlich häufig Fehler zu produzieren was natürlich auch andere Fehler provozieren kann.
Log mal und suche auch nach Resend - das passiert wenn die Firmware merkt das was nicht stimmt. Ist normal recht schnell wieder befüllt aber wenn sich das mal aufschaukelt.
man sieht halt manchmal nur, dass es da irgendwie ne Sekunde dauert bis die antwort kommt.
z.b.
Recv:22:16:36.351: ok
oder
oder
und das sind, zumindest in den logs wo ich jetzt geschaut habe, auch immer die stellen wo dann "ok T:199.94 /200.00 B:60.29 /60.00 @:56 B@:0" die antwort ist, bei allen anderen ists dann immer "ok" oder ähnlich
ist die antwort auf M105 - sieht also aus als ob kein autoreport funktioniert.
Das sind aber wie ich sehe nicht unbedingt Fehler. Wenn ein G1 move länger dauert blockieren die auch bis ein früherer Move ausgeführt wurde. Wenn also der move auf den die Firmware wartet länger als eine Sekunde braucht dauert das senden des nächsten Befehls auch.
Zur analyse braucht du normal auch mehr Zeilen weil die firmware meist 16 moves buffert aber nur 1-2 Befehle in der Warteschlange stehen. Kompliziert zu erklären aber pausen können ihre Ursache ein ganzes stück weiter oben schon haben.
Wichtig ist eigentlich nur wo der Drucker wirklich stehen bleibt und kurze Pausen wegen Filament retract zählen da nicht.
Ich kann ja hier nicht einfach über 100 Zeilen Log posten, oder?
Gruß Christian