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
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

Comments

  • Hi,
    perhaps somebody has an idea...
    i have running repetier-server pro on raspberry pi 3b with an anycubic i3 mega and since two days additonally with an sunlu s8. the i3 mega runs perfect since many months but the sunlu stopps several times while printing.
    when it stopps printing in the log i see an Communication Timeout. 
    part of logfile:
    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

    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
  • Steht ja im log:
    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.
  • Ah ok. Wie kann ich dann gegebenenfalls dem Server das als Ok beibringen?
  • In installationsordner/firmwares/marlin.xml steht
    <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.
  • Hm das ist die Standard Firmware die drauf war, aber soweit ich weiß müsste es marlin sein.
    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.
  • also diese variationen hab ich logfile:
    a)
    Recv:21:34:18.036: o-  T:210.04 /210.00 B:49.85 /50.00 @:60 B@:0
    Recv:21:34:19.036:  T:210.00 /210.00 B:49.69 /50.00 @:61 B@:0
    Recv:21:34:20.035:  T:210.00 /210.00 B:49.65 /50.00 @:61 B@:0
    Recv:21:34:21.035:  T:210.12 /210.00 B:49.67 /50.00 @:58 B@:0
    Recv:21:34:22.035:  T:210.31 /210.00 B:49.75 /50.00 @:53 B@:0
    Recv:21:34:23.036:  T:210.23 /210.00 B:49.82 /50.00 @:56 B@:127
    Recv:21:34:24.034:  T:210.08 /210.00 B:49.70 /50.00 @:60 B@:127
    Recv:21:34:25.035:  T:210.00 /210.00 B:49.52 /50.00 @:63 B@:127
    Recv:21:34:26.034:  T:210.04 /210.00 B:49.49 /50.00 @:62 B@:127
    Mesg:21:34:26.593: Warning: Communication timeout - resetting communication buffer.
    Mesg:21:34:26.593: Connection status: Buffered:84, Manual Commands: 1, Job Commands: 5000
    Mesg:21:34:26.593: Buffer used:84 Enforced free byte:48 lines stored:2
    Send:21:34:26.593: M117 ETE 01:13:29

    b)
    Recv:21:37:13.808: ok
    Recv:21:37:14.187:  T:210.04 /210.00 B:50.72 /50.00 @:64 B@:0
    Recv:21:37:15.187:  T:210.12 /210.00 B:50.71 /50.00 @:62 B@:0
    Recv:21:37:16.185:  T:210.35 /210.00 B:50.M z  r    @:M    0
    Recv:21:37:17.186:  T:210.27 /210.00 B:50.60 /50.00 @:60 B@:0
    Recv:21:37:18.187:  T:210.27 /210.00 B:50.54 /50.00 @:61 B@:0
    Recv:21:37:19.186:  T:210.31 /210.00 B:50.48 /50.00 @:60 B@:0
    Recv:21:37:20.187:  T:210.31 /210.00 B:50.33 /50.00 @:60 B@:0
    Recv:21:37:21.186:  T:210.31 /210.00 B:50.31 /50.00 @:60 B@:0
    Recv:21:37:22.186:  T:210.16 /210.00 B:50.28 /50.00 @:65 B@:0
    Mesg:21:37:22.804: Warning: Communication timeout - resetting communication buffer.
    Mesg:21:37:22.804: Connection status: Buffered:65, Manual Commands: 0, Job Commands: 5000
    Mesg:21:37:22.804: Buffer used:65 Enforced free byte:42 lines stored:2
    Send:21:37:22.804: N46376 G1 X165.387 Y174.531 E564.28271
    Send:21:37:22.805: N46377 G1 X165.515 Y174.533 E564.28697

    c)
    Recv:21:37:28.004: o- ok
    Recv:21:37:28.204:  T:209.88 /210.00 B:49.85 /50.00 @:70 B@:0
    Recv:21:37:29.203:  T:209.77 /210.00 B:49.93 /50.00 @:72 B@:0
    Recv:21:37:30.205:  T:209.88 /210.00 B:49.87 /50.00 @:68 B@:0
    Recv:21:37:31.203:  T:210.00 /210.00 B:49.77 /50.00 @:65 B@:127
    Recv:21:37:32.203:  T:210.00 /210.00 B:49.69 /50.00 @:65 B@:127
    Recv:21:37:33.204:  T:210.16 /210.00 B:49.67 /50.00 @:61 B@:127
    Recv:21:37:34.205:  T:210.12 /210.00 B:49.82 /50.00 @:63 B@:127
    Recv:21:37:35.204:  T:210.23 /210.00 B:49.84 /50.00 @:60 B@:127
    Recv:21:37:36.204:  T:210.20 /210.00 B:49.90 /50.00 @:62 B@:127
    Mesg:21:37:36.934: Warning: Communication timeout - resetting communication buffer.
    Mesg:21:37:36.935: Connection status: Buffered:85, Manual Commands: 1, Job Commands: 5000
    Mesg:21:37:36.935: Buffer used:85 Enforced free byte:43 lines stored:2
    Send:21:37:36.935: M117 ETE 01:10:29
    Send:21:37:36.935: N46663 G1 X179.207 Y157.418 E566.34177
    Recv:21:37:36.940: ok

    gruß christian


  • Nur bei a und c sind falsche ok vorhanden. Die anderen kommen vermutlich frühe rund ein späterer längere gcode blockt dann. Gemeinsam ist "o-" was auch unüblich ist, daher würde ich den Text einfach in einer extra Zeile mit aufnehmen:
    <response type="ok" value="-1">^o-</response>

    Sollte also hier iene deutliche Verbesserung bringen.
  • ok, danke dir!
    ich habe es jetzt mal eingetragen und werde gleich testen und rückmeldung geben.

    Gruß und Danke,
    Christian
  • Läuft bereits viel besser! 
    ich hatte jetzt noch zwei timeouts:
    Send:11:10:13.914: N123199 G1 X173.12 Y143.146 E1646.08356
    Recv:11:10:13.992:  T:200.38 /200.00 B:50.18 /50.00 @:53 B@:Rok
    Recv:11:10:14.986:  T:200.45 /200.00 B:50.14 /50.00 @:53 B@:0
    Recv:11:10:15.986:  T:200.73 /200.00 B:50.07 /50.00 @:46 B@:0
    Recv:11:10:16.987:  T:200.38 /200.00 B:50.11 /50.00 @:57 B@:0
    Recv:11:10:17.987:  T:200.49 /200.00 B:49.97 /50.00 @:55 B@:0
    Recv:11:10:18.986:  T:200.28 /200.00 B:49.92 /50.00 @:60 B@:0
    Recv:11:10:19.986:  T:200.35 /200.00 B:49.82 /50.00 @:58 B@:0
    Recv:11:10:20.986:  T:200.14 /200.00 B:49.87 /50.00 @:63 B@:0
    Recv:11:10:21.987:  T:200.14 /200.00 B:49.77 /50.00 @:62 B@:127
    Mesg:11:10:22.932: Warning: Communication timeout - resetting communication buffer.
    Mesg:11:10:22.932: Connection status: Buffered:43, Manual Commands: 1, Job Commands: 5000
    Mesg:11:10:22.932: Buffer used:43 Enforced free byte:0 lines stored:1
    Send:11:10:22.933: M117 ETE 00:28:08

    und 

    Send:11:37:46.466: N170764 G0 X170.625 Y129.97
    Recv:11:37:46.579:  T:200.42 /200.00 B:49.92 /50.00 @:53 B@ L   ok
    Recv:11:37:47.507:  T:200.24 /200.00 B:50.09 /50.00 @:58 B@:0
    Recv:11:37:48.508:  T:200.17 /200.00 B:50.23 /50.00 @:61 B@:0
    Recv:11:37:49.507:  T:200.24 /200.00 B:50.30 /50.00 @:59 B@:0
    Recv:11:37:50.507:  T:200.24 /200.00 B:50.31 /50.00 @:59 B@:0
    Recv:11:37:51.507:  T:200.28 /200.00 B:50.37 /50.00 @:58 B@:0
    Recv:11:37:52.508:  T:200.24 /200.00 B:50.36 /50.00 @:59 B@:0
    Recv:11:37:53.508:  T:200.28 /200.00 B:50.30 /50.00 @:58 B@:0
    Recv:11:37:54.508:  T:200.00 /200.00 B:50.30 /50.00 @:66 B@:0
    Mesg:11:37:55.485: Warning: Communication timeout - resetting communication buffer.
    Mesg:11:37:55.485: Connection status: Buffered:31, Manual Commands: 1, Job Commands: 5000
    Mesg:11:37:55.485: Buffer used:31 Enforced free byte:0 lines stored:1
    Send:11:37:55.485: M117 ETE 00:00:00

    da ist ja theoretisch das ok, aber augenscheinlich leider nicht an der passenden stelle. hab ich da noch irgendeine chance etwas gegen zu machen? 
  • <response type="ok" value="-1">.ok$</response>

    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.
  • Also er stoppt immer noch, mal mehr mal weniger. Jedoch sind eigenartigerweise keine timeouts mehr im log... 
    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 
  • Ok, keine timeouts hört sich ja schon mal gut an. Dann haben wir seine Varianten ja durch:-)
    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.
  • edited January 2021
    also ein resend ist nicht im Log zu finden. 
    man sieht halt manchmal nur, dass es da irgendwie ne Sekunde dauert bis die antwort kommt.
    z.b. 
    Recv:22:16:36.351: ok
    Send:22:16:36.352: N845 G1 X203.444 Y216.168 E28.33408
    Recv:22:16:36.363: ok
    Send:22:16:36.364: N846 G1 X203.18 Y216.382 E28.34811
    Recv:22:16:37.269: ok  T:199.89 /200.00 B:60.38 /60.00 @:59 B@:0
    Send:22:16:37.270: N847 G1 X203.095 Y216.449 E28.35257
    Recv:22:16:37.279: ok

    oder
    Recv:22:16:37.506: ok
    Send:22:16:37.506: N868 G1 X197.439 Y219.012 E28.61124
    Recv:22:16:38.271: o-  T:199.77 /200.00 B:60.38 /60.00 @:61 B@:0
    Send:22:16:38.271: N869 G1 X196.862 Y219.107 E28.63537
    Recv:22:16:38.280: ok

    oder
    Recv:22:16:38.698: ok
    Send:22:16:38.698: N907 G1 X145.357 Y212.187 E30.80022
    Recv:22:16:39.272: ok  T:199.94 /200.00 B:60.29 /60.00 @:56 B@:0
    Send:22:16:39.272: N908 G1 X142.655 Y212.496 E30.91245
    Recv:22:16:39.284: ok


    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
  • ok  T:199.94 /200.00 B:60.29 /60.00 @:56 B@:0
    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.
  • ok :) nun bin ich raus :) was kann/soll/muss ich tun? :D
  • Nicht nur 5 Zeilen zeigen wo do denkst das das Problem ist sondern die letzten 100. Und du must die stelle finden wo der Drucker wirklich pausiert. Nur weil ein befehl mal eine sekunde brauchte ist das halt keine echte pause wenn der Grund eine längere langsame bewegung war auf deren ende gewartet wurde. Und manchmal sieht etwas wie eine pause aus, ist aber nur ein retract des Extruders. Keine ahnung wie lange die bei dem Drucker brauchen. Eigentlich sind nur bowden hier langsam weil die viel mehr retracten müssen. Aber ohne timeout und resend ist eigentlich keine verzögerung zu erwarten. Aber erwarte auch nicht nach jedem ok sofort einen neuen Befehl. Manchmal müssen auch 2 ok kommen oder da ist ein M105 zwischen die in der Konsole gerne gefiltert werden wodurch du es nur nicht siehst.
  • Ich merke schon, das wird wohl nix werden mit repetier und dem S8 ohne sich komplett in repetier logs einzuarbeiten... schade. Hatte extra die Pro Version gekauft da mit dem i3 Mega alles super lief und ich einen zweiten Drucker zulegen wollte und somit dann auch 2 Kameras... aber das wird, so wie es aussieht, dann nichts werden. 
    Ich kann ja hier nicht einfach über 100 Zeilen Log posten, oder?

    Gruß Christian 
  • 100 Zeilen kann man schon posten aber die Frage ist ob es die richtigen sind. Du hast ja schon bewiesen das es ein Problem mit dem Drucker ist. Die Kommunikation ist buggy und daraus resultieren dann die ganzen Probleme. Die Frage ist daher in erster Linie warum macht der Drucker so viele Kommunikationsfehler. Wenn das abgestellt ist sollte es genau so gut wie der i3 Mega laufen.
Sign In or Register to comment.