Warning: Communication timeout - resetting communication buffer
in Bug Reports
Hallo zusammen,
Ich habe ein Problem mit ständigen Verbindungsabbrüchen.
Normalerweise habe ich einen Rasperry PI4 im Einsatz seit ca. 3 Jahren.
Hat am Anfang Problemlos Funktioniert. Ich hatte am Anfang Repetier-Server-Image_0_93_1_v20 im Einsatz.
Habe dann ein Update auf 1.x.x gemacht. Welche Version es war weiss ich nach all denen Versuchen nicht mehr.
Von da an nur noch Probleme. Druck bleibt einfach stehen, Verbindungsabbrüche.
Ich habe nun Versucht meinen Drucker über Repetier Server mit Windows10 zu betreiben.
Das gleiche Resultat. Ich habe Gedacht es liegt eventuell am Raspy.
Momentan benutze ich die neuste Version. Keine Ahnung was ich noch tun könnte.
Über SD Karte kein Problem beim Ultimaker 2+ Extended. Da geht alles einwandfrei.
Verschiedene USB Kabel versucht. Kein Erfolg.
Verschiedene Kommunikationseinstellungen. Kein Erfolg.
Auf dem Drucker mehrere Firmwares versucht. Kein Erfolg.
Ich hoffe jemand kann mir noch einenTipp geben.
Viele Grüße
Peter
Comments
Recv:15:47:44.163: ok
Send:15:47:44.164: N3526 G1 F1570.7 X124.234 Y165.48 E20.38101
Recv:15:47:44.205: ok
Send:15:47:44.205: N3527 G1 F1562.5 X123.567 Y165.832 E20.38869
Recv:15:47:44.233: ok
Send:15:47:44.233: N3528 M105
Recv:15:47:44.258: ok T:250.2 /250.0 B:89.6 /90.0 @:58 B@:127
Send:15:47:44.258: N3529 M73 P77 R2 Q77 S2
Recv:15:47:44.262: ok
Send:15:47:44.262: N3530 G1 F1566.6 X123.025 Y166.071 E20.39471
Recv:15:47:44.266: ok
Send:15:47:44.266: N3531 G1 F1578.9 X122.124 Y166.388 E20.40434
Recv:15:47:44.278: ok
Send:15:47:44.278: N3532 G1 F1583.1 X121.271 Y166.582 E20.41315
Recv:15:47:44.315: ok
Send:15:47:44.315: N3533 G1 F1570.7 X120.698 Y166.669 E20.41902
Recv:15:47:44.335: ok
Send:15:47:44.335: N3534 G1 F1562.5 X120.115 Y166.721 E20.42498
Mesg:15:47:55.339: Warning: Communication timeout - resetting communication buffer.
Mesg:15:47:55.339: This means that a expected firmware response was not seen within the expected time.
Mesg:15:47:55.339: The typical reason is a communication error and print should continue after the communication reset.
Mesg:15:47:55.339: Connection status: Buffered:48, Manual Commands: 1, Job Commands: 5000
Mesg:15:47:55.339: Buffer used:48 Enforced free byte:0 lines stored:1
Send:15:47:55.339: N3535 M105
Recv:15:47:55.347: ok T:249.8 /250.0 B:89.3 /90.0 @:61 B@:0
Send:15:47:55.347: N3536 M105
Recv:15:47:55.354: ok T:249.8 /250.0 B:89.3 /90.0 @:61 B@:0
Send:15:47:55.354: N3537 G1 F1570.7 X119.258 Y166.739 E20.43366
Recv:15:47:55.358: ok
Send:15:47:55.358: N3538 G1 F1562.5 X118.44 Y166.667 E20.44203
Recv:15:47:55.366: ok
Send:15:47:55.366: N3539 G1 F1558.5 X117.867 Y166.574 E20.44795
Recv:15:47:55.370: ok
Send:15:47:55.370: N3540 G1 F1566.6 X117.257 Y166.438 E20.4543
Recv:15:47:55.378: ok
Send:15:47:55.379: N3541 G1 X116.411 Y166.174 E20.4633
Recv:15:47:55.383: ok
Send:15:47:55.383: N3542 G1 F1554.4 X115.721 Y165.892 E20.47092
Mesg:15:47:55.339: Warning: Communication timeout - resetting communication buffer.
zeigt klar das nach dem move kein ok mehr kam. Auch später nicht da das nächste ok klar vom M105 kommt. Ist kein Spannungsproblem die Zeile Kam einfach nicht an. Eher ungeewöhnlich, normal fehlt nur ein Buchstabe. Das ist aber genau wofür der Timeout gedacht ist um so was zu erkennen und trotzdem weiter zu drucken. Ohne ping-pong würde er erst mal weiter machen und erst später beim 2. auftreten ein timeout bekommen. Da es ein altes Marlin zu sein scheint kannst du leider den timeout auch nicht einfach zu weit runter schrauben sonst kann eine langsame Bewegung ihn auch fälschlich triggern.
Aus dem hub log:
Da scheint der hub nicht glücklich zu sein über das Ausmaß der Störungen vom Drucker und klemmt gleich mal usb kurz ab. Ist er beim pi eigentlich am usb 2 oder 3 Port. Manchmal denke ich da susb 3 empfindlicher ist, auch wenn er eh auf usb 2 runterdrosselt da der Drucker nicht mehr kann. Aber Grundproblem scheinen wohl die Stösspannungen zu sein vom Drucker(nicht Netzteil). Dein Windows Port scheint etwas unempfindlicher zu sein wenn er keine Probleme hat.
Mesg:16:49:12.664: Warning: Communication timeout - resetting communication buffer.
Mesg:16:49:12.664: This means that a expected firmware response was not seen within the expected time.
Mesg:16:49:12.664: The typical reason is a communication error and print should continue after the communication reset.
Mesg:16:49:12.664: Connection status: Buffered:35, Manual Commands: 1, Job Commands: 3191
Mesg:16:49:12.664: Buffer used:35 Enforced free byte:0 lines stored:1
Send:16:49:12.664: N8456 M105
Recv:16:49:12.673: ok T:249.7 /250.0 B:89.7 /90.0 @:70 B@:127
Send:16:49:12.673: N8457 M105
Recv:16:49:12.680: ok T:249.7 /250.0 B:89.7 /90.0 @:70 B@:127
Send:16:49:12.680: N8458 G1 F1350 X98.347 Y100.136 E100.0382
Recv:16:49:12.684: ok
Send:16:49:12.684: N8459 G0 F10800 X98.784 Y100.195
Recv:16:49:12.688: ok
Send:16:49:12.688: N8460 G1 F1350 X100.96 Y98.019 E100.06353
Recv:16:49:12.696: ok
Send:16:49:12.696: N8461 M73 P83 R5 Q83 S5
Recv:16:49:12.700: ok
Send:16:49:12.700: N8462 G0 F10800 X101.374 Y98.1
Recv:16:49:12.704: ok
Send:16:49:12.705: N8463 G1 F1350 X99.226 Y100.247 E100.08852
Recv:16:49:12.709: ok
Ist ping pong aktiviert?
Ich sehe hier G28 bekommt nach 2s sein ok was eher schnell ist, wenn ping pong aktiv ist. Wenn nicht würde in in ping pong gehen aber in dem Wechsel gab es zu 1.4.9 eine korrektur. Für mich sieht es aus als ob homing länger dauert aber kann ich nicht wissen, must du sagen. Da würde dann das timeout von kommen weil er es nicht mehr als langsamen Befehl sieht wenn du 1.4.8 hast.
Dann hängt er wirklich bei M114 auch wenn er sonst direkt antwortet. Und wenn er nicht lange braucht ist es wirklich abhanden gekommen.
Recv:17:02:41.889: ok
Send:17:02:41.889: N37447 G1 F1380 X91.35 Y131.634 E178.96041
Recv:17:02:42.118: ok
Send:17:02:42.119: N37448 G0 F10800 X91 Y131.634
Recv:17:02:42.131: ok
Send:17:02:42.131: N37449 G1 F1380 X91 Y126.376 E179.00368
Recv:17:02:42.360: ok
Send:17:02:42.360: N37450 M105
Recv:17:02:42.373: ok T:248.8 /250.0 B:88.7 /90.0 @:82 B@:127
Send:17:02:42.373: N37451 M73 P93 R2 Q93 S2
Recv:17:02:42.377: ok
Send:17:02:42.377: N37452 G0 F10800 X90.65 Y126.376
Recv:17:02:42.381: ok
Send:17:02:42.381: N37453 G1 F1380 X90.65 Y131.634 E179.04695
Recv:17:02:42.602: ok
Send:17:02:42.602: N37454 G0 F10800 X90.3 Y131.634
Recv:17:02:42.614: ok
Send:17:02:42.614: N37455 G1 F1380 X90.3 Y126.376 E179.09022
Recv:17:02:42.844: ok
Send:17:02:42.844: N37456 G0 F10800 X89.95 Y126.376
Recv:17:02:42.856: ok
Send:17:02:42.856: N37457 G1 F1380 X89.95 Y131.634 E179.13349
Recv:17:02:43.085: ok
Send:17:02:43.085: N37458 G0 F10800 X89.6 Y131.634
Recv:17:02:43.097: ok
Send:17:02:43.098: N37459 G1 F1380 X89.6 Y126.376 E179.17676
Recv:17:02:43.327: ok
Send:17:02:43.327: N37460 M105
Recv:17:02:43.344: ok T:250.2 /250.0 B:89.6 /90.0 @:67 B@:127
Send:17:02:43.344: N37461 G0 F10800 X89.25 Y126.376
Recv:17:02:43.347: ok
Send:17:02:43.348: N37462 G1 F1380 X89.25 Y131.634 E179.22004
Recv:17:02:43.569: ok
Send:17:02:43.569: N37463 G0 F10800 X88.9 Y131.634
Recv:17:02:43.581: ok
Send:17:02:43.581: N37464 G1 F1380 X88.9 Y126.376 E179.26331
Mesg:17:03:04.583: Warning: Communication timeout - resetting communication buffer.
Mesg:17:03:04.583: This means that a expected firmware response was not seen within the expected time.
Mesg:17:03:04.583: The typical reason is a communication error and print should continue after the communication reset.
Mesg:17:03:04.583: Connection status: Buffered:45, Manual Commands: 1, Job Commands: 667
Mesg:17:03:04.583: Buffer used:45 Enforced free byte:0 lines stored:1
Send:17:03:04.583: N37465 M105
Recv:17:03:04.590: 9.3 /90.0 @:64 B@:127
Mesg:17:03:25.585: Warning: Communication timeout - resetting communication buffer.
Mesg:17:03:25.585: This means that a expected firmware response was not seen within the expected time.
Mesg:17:03:25.585: The typical reason is a communication error and print should continue after the communication reset.
Mesg:17:03:25.585: Connection status: Buffered:15, Manual Commands: 1, Job Commands: 667
Mesg:17:03:25.585: Buffer used:15 Enforced free byte:0 lines stored:1
Send:17:03:25.585: N37466 M105
Recv:17:03:25.593: ok T:250.5 /250.0 B:89.6 /90.0 @:63 B@:0
Send:17:03:25.593: N37467 M105
Recv:17:03:25.599: ok T:250.5 /250.0 B:89.6 /90.0 @:63 B@:0
Send:17:03:25.599: N37468 G0 F10800 X88.55 Y126.376
Recv:17:03:25.603: ok
Send:17:03:25.603: N37469 G1 F1380 X88.55 Y131.634 E179.30658
Recv:17:03:25.611: ok
Send:17:03:25.611: N37470 G0 F10800 X88.2 Y131.634
Recv:17:03:25.615: ok
Send:17:03:25.615: N37471 G1 F1380 X88.2 Y126.376 E179.34985
Antwort kommt sofort aber da fehlt der Anfang
daher fürchte ich das die fehlenden ok aus dem gleichen Grund abhanden kommen. Wir sehen nur was uns das Betriebssystem schickt. Denke die Firmware selbst schickt es noch aber irgendwo wird dann ein Datenblock beim senden ignoriert (wegen übertragungsfehler ) und kommt nicht an.
Ohne diese Tricks kannst du ping pong deaktivieren und sehen wie viel Puffer geht, denke aber mehr als 140 ist gefährlich. Dann wird es dennoch weiter passieren aber seltener deswegen auf ein Timeout warten.
Da ich hier aber auch trennungen mit emi warnung gesehen hab, scheint da eine Störung zu sein, die sich gelegentlich bemerkbar macht. Mehr als das grade oben beschriebene kann man nicht machen es sei den man weiß was die Störung verursacht.