› ›

Drucker bleibt immer wieder kurz stehen und fährt in Null-Position

Legion23Legion23
in General
Hallo, zusammen

Ich habe mal wieder ein Problem mit meinem neuesten Drucker.
Das Problem stellt sich wie folgt dar: Mitten im Druck bleibt der Drucker plötzlich stehen (meistens nur sehr kurz, max. wenige Sekunden), dann fährt er entweder direkt weiter oder fährt erst in die X - Y - Nullposition (G0 X0 Y0) und fährt dann direkt wieder weiter. Das führt dann dazu, dass sich an der entsprechenden Stelle auf dem Druckteil ein Klecks aus ausgelaufenem geschmolzenen Filament bildet.
Das Problem tritt bei dem selben Druckteil beim wiederholten Drucken an unterschiedlicher Stelle auf, es ist also kein Problem mit dem G-Code. Der selbe G-Code wird von anderen Drucker mit indentischer Hard - und Software auch fehlerfrei ausgeführt.

Die Steuerung besteht aus einem Arduino Due mit einem RADDS-Shield. Zurzeit nutze ich ein Raspberry Pi 4 als Host. Zuvor hatte ich mit einem Windows 10 - Tablet als Host das selben Problemen.
Firmware-Version ist 1.0.4., Server-Version ist 1.3
Ich habe bereits den Arduino ausgetauscht, mehrere Repetier-Server-Versionen getestet, mehrere USB-Kabel getestet (zurzeit ein sehr kurzes 0,5m-Kabel, verschiedene Verbindungseinstellungen getestet (Baudrate 250000 und 115200), Cache auf 127, 63 und aktuell auf Ping-Pong, laut Verbindungstest 0,0% Fehlerrate im Ping-Pong.
Bei dem USB-Kabel zum Arduino habe ich den V+-Kontakt abgeklebt, damit der sich den Strom nicht über die USB-Schnittstelle zieht, sondern vom RADDS.
Mit dem Windows 10 Tablet hatte ich außerdem einige Male das Problem, dass sich die Steuerung komplett aufgehangen hat. Der Drucker stand dann in X0 Y0 und die Kommunikation funktioniert nicht mehr. In diesen Fällen musste ich Repetier Server neu starten. Mit dem Raspberry Pi ist das bisher noch nicht passiert.
Die Verbindungsqualität wird immer als sehr gut angezeigt, unter Verbindungsqualität beträgt der Fehler weit unter 0,1%

Der Fehler tritt scheinbar gehäuft bei Rundungen auf, bei langen Geraden ist er mir noch nicht aufgefallen.
Die Anzahl der Segmente bei den Rundungen auch nicht so extrem, dass die Verbindung deswegen stocken könnte.

In der Konsole steht nichts auffälliges: Anfangs kommt häufig ein

DebugLevel:6
Info: Continue from fatal State
Rescue_State: OFF

Außerdem habe ich bemerkt, dass bei sehr langen Geraden häufig "communication Timeout" gesendet wird, was dann aber keine weiteren Konsequenzen hat, der Druck läuft dann trotzdem ohne Störung weiter.

Das sieht dann so aus:
Warning: Comunkcation timeout - resetting communication buffer
Connection Status: Buffered:19, Manual Commands: 1, job Commands: 5000
Buffer Used:19 Enforced Free Byte:0 lines stored:1

Ich bin mit meiner Fachkenntnis langsam am Ende. Die einzige Alternativen, die ich jetzt noch testen könnte wäre jetzt eine komplett andere Steuerung oder eine andere Firmware.

Hat jemand eine Idee, woher das Problem kommen kann?

Comments

  • RepetierRepetier
    Firmware ist repetier nehme ich an? Das ganze ist erst mal ein Kommunikationsproblem. Kurven sind nicht eher betroffen, aber weil bei kurven viele segemente anfallen ist der look ahead kleiner und es fällt auf. Bei langen bewegungen kann es ja sein das er noch 7 Sekunden nachläuft bei timeout 3 sekunden (nehme an du hast ihn auf 3s).

    Wichtig ist erst mal ping pong modus aus, das erkennt die meisten Kommunikationsfehler on the fly. In deinem Text ist nur Befehl gepuffert daher denke ich ping pong ist an.

    Beim due gibt es außerdem 2 Ports. Du kannst die Firmware so konfigurieren das beide klappen, damit kannst du auch testweise wechseln. Der native port ist schneller und nutzt keine serielle verbindung. Einziger nachteil is das er den Drucker nicht resettet beim verbinden, kann aber auch ein Vorteil sein.

    Aktuell nehme ich an das alles timeouts waren. Sieh aber mal im server.log nach ob der drucker unerwaretet verbunden wurde. Insbesondere beim pi wenn er im Blitz Menü anzeigt das mal unterspannung war, könnte das auch ein Grund sein.
  • Legion23Legion23
    Die Firmware ist natürlich Repetier, Version 1.0.4.
    Bis jetzt war der Arduino Due am Programming port angeschlossen.

    Jetzt habe ich ihn am Native Port angeschlossen und die Verbindung von Pingpong auf Buffered mit 63 Byte umgestellt.
    Der Fehler ist immer noch da, dieses mal direkt am Anfang kurz nach dem Start des Drucks.
    Zum Zeitpunkt des Fehlers gab es keine Meldung wegen Unterspannung und CPU-Drosselung, allerdings wurde das 4 Minuten später gemeldet.

    Ich habe Ausschnitte der Log-Dateien angehangen. Der Fehler trat beim Zeitstempel 20:30:15.000 auf, die Unterspannungsmeldung erschien beim Zeitstempel 20:36:2. Kann das trotzdem zusammenhängen?
    Der Fehler trat in der selben Form auch mit dem Windows 10 Tablet auf, daher denke ich, dass es nicht am Raspberry liegt.
    Beim Zeitstempel 20:30:15.000 gibt es sonst keine Fehlermeldungen.
    Laut den Verbindungsdaten gab es keine Fehler oder Timeouts, es sind auch keine Systemfehler hinterlegt.
    Die CPU-Temperatur liegt bei 49°C

    Im Log sieht das ganze so aus:

    Server-Log:

    2022-03-10 20:23:45: Reset printer MOAP remastered
    2022-03-10 20:29:36: Job created: /var/lib/Repetier-Server/printer/MOAP_remastered/jobs/00000001_6x--original(3).u
    2022-03-10 20:29:37: finish job creation /var/lib/Repetier-Server/printer/MOAP_remastered/jobs/00000001_6x--original(3).u
    2022-03-10 20:29:37: start printjob 6x--original(3) on printer MOAP remastered
    2022-03-10 20:29:38: Updating info for /var/lib/Repetier-Server/printer/MOAP_remastered/jobs/00000001_6x--original(3).g printer MOAP_remastered
    2022-03-10 20:29:44: Time analysing /var/lib/Repetier-Server/printer/MOAP_remastered/jobs/00000001_6x--original(3).g:5895571 us
    2022-03-10 20:30:23: Websocket opened
    2022-03-10 20:32:30: Websocket opened
    2022-03-10 20:32:33: Websocket opened
    2022-03-10 20:32:37: Websocket opened
    2022-03-10 20:32:40: MainRequestHandler::handleRequest:Assertion violation: !_pStream in file "/builds/repetier/repetier-server/Repetier-Server/Poco/Net/src/HTTPServerResponseImpl.cpp", line 69
    2022-03-10 20:32:41: Websocket opened

    Syslog:

    Mar 10 20:30:00 RepetierServer dbus-daemon[406]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.65' (uid=0 pid=4556 comm="timedatectl ")
    Mar 10 20:30:00 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 10 20:30:00 RepetierServer dbus-daemon[406]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 10 20:30:00 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 10 20:30:30 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 10 20:31:04 RepetierServer dbus-daemon[406]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.67' (uid=0 pid=4703 comm="timedatectl ")
    Mar 10 20:31:04 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 10 20:31:04 RepetierServer dbus-daemon[406]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 10 20:31:04 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 10 20:31:34 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 10 20:32:08 RepetierServer dbus-daemon[406]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.69' (uid=0 pid=4838 comm="timedatectl ")
    Mar 10 20:32:08 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 10 20:32:08 RepetierServer dbus-daemon[406]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 10 20:32:08 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 10 20:32:38 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 10 20:33:12 RepetierServer dbus-daemon[406]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.71' (uid=0 pid=4972 comm="timedatectl ")
    Mar 10 20:33:12 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 10 20:33:12 RepetierServer dbus-daemon[406]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 10 20:33:12 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 10 20:33:42 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 10 20:34:16 RepetierServer dbus-daemon[406]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.73' (uid=0 pid=5115 comm="timedatectl ")
    Mar 10 20:34:16 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 10 20:34:16 RepetierServer dbus-daemon[406]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 10 20:34:16 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 10 20:34:46 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 10 20:35:20 RepetierServer dbus-daemon[406]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.75' (uid=0 pid=5259 comm="timedatectl ")
    Mar 10 20:35:20 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 10 20:35:21 RepetierServer dbus-daemon[406]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 10 20:35:21 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 10 20:35:51 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 10 20:36:25 RepetierServer dbus-daemon[406]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.77' (uid=0 pid=5394 comm="timedatectl ")
    Mar 10 20:36:25 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 10 20:36:25 RepetierServer dbus-daemon[406]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 10 20:36:25 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 10 20:36:27 RepetierServer kernel: [ 1468.905420] Under-voltage detected! (0x00050005)
    Mar 10 20:36:31 RepetierServer kernel: [ 1473.065428] Voltage normalised (0x00000000)
    Mar 10 20:36:55 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 10 20:37:29 RepetierServer dbus-daemon[406]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.79' (uid=0 pid=5546 comm="timedatectl ")
    Mar 10 20:37:29 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 10 20:37:29 RepetierServer dbus-daemon[406]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 10 20:37:29 RepetierServer systemd[1]: Started Time & Date Service.

    Print-Log: (zum Zeitpunkt des Fehlers):

    Send:20:30:08.483: N294 G1 X121.896 Y161.493 E19.4368
    Recv:20:30:08.486: ok 293
    Send:20:30:08.487: N295 G1 X121.926 Y161.372 E19.4485
    Recv:20:30:08.525: ok 294
    Send:20:30:08.526: N296 G1 X122.304 Y160.016 E19.5801
    Recv:20:30:08.529: ok 295
    Send:20:30:08.529: N297 G1 X122.341 Y159.897 E19.5918
    Recv:20:30:08.568: ok 296
    Send:20:30:08.568: N298 G1 X122.800 Y158.567 E19.7234
    Recv:20:30:08.572: ok 297
    Send:20:30:08.572: N299 G1 X122.844 Y158.451 E19.7350
    Recv:20:30:08.590: ok 298
    Send:20:30:08.590: N300 G1 X123.383 Y157.151 E19.8667
    Recv:20:30:08.611: ok 299
    Send:20:30:08.611: N301 G1 X123.434 Y157.037 E19.8783
    Recv:20:30:08.614: ok 300
    Send:20:30:08.614: N302 G1 X124.050 Y155.772 E20.0099
    Recv:20:30:14.999: ok 301
    Recv:20:30:14.999: ok 302
    Recv:20:30:15.000: T:224.75 /225 B:62.02 /62 B@:153 @:73
    Mesg:20:30:15.000: Warning: Seems like we missed a ok - continue sending.
    Recv:20:30:15.000: wait
    Recv:20:30:15.000: T:224.25 /225 B:62.02 /62 B@:142 @:77
    Mesg:20:30:15.000: Warning: Seems like we missed a ok - continue sending.
    Recv:20:30:15.000: wait
    Recv:20:30:15.001: T:224.00 /225 B:62.06 /62 B@:129 @:79
    Recv:20:30:15.001: busy:heating
    Recv:20:30:15.001: T:223.75 /225 B:62.06 /62 B@:117 @:82
    Recv:20:30:15.001: wait
    Recv:20:30:15.001: T:223.75 /-225 B:62.02 /62 B@:150 @:0
    Recv:20:30:15.001: wait
    Recv:20:30:15.001: T:223.75 /-225 B:62.02 /62 B@:139 @:0
    Recv:20:30:15.001: wait
    Send:20:30:15.001: N303 G1 X124.108 Y155.662 E20.0216
    Send:20:30:15.002: N304 G1 X124.799 Y154.436 E20.1532
    Recv:20:30:15.002: ok 303
    Send:20:30:15.002: N305 G1 X124.863 Y154.330 E20.1649
    Recv:20:30:15.203: T:223.50 /225 B:62.02 /62 B@:139 @:84
    Recv:20:30:16.274: T:223.50 /225 B:62.02 /62 B@:138 @:78
    Recv:20:30:17.002: busy:heating
    Recv:20:30:17.345: T:223.00 /225 B:62.06 /62 B@:114 @:89
    Recv:20:30:18.415: T:222.75 /225 B:62.06 /62 B@:123 @:92
    Recv:20:30:19.002: busy:heating



  • RepetierRepetier
    Den buffer auf 127 byte erhöhen. Das ist unser standardbuffer. Mit 63 byte könnte es eng werden mit mehreren Befehlen.

    Im log ist keine Trennung des Ports sichtbar, was schon mal gut ist.

    Wenn du die Rescue Funktion in der Firmware implementiert hast geht der Druckkopf zur seite wenn er beim Druck länger keine Daten bekommt. Würde die moves zur Seite erklären zumal da im Log:
    Send:20:30:08.614: N302 G1 X124.050 Y155.772 E20.0099
    Recv:20:30:14.999: ok 301
    Recv:20:30:14.999: ok 302
    Recv:20:30:15.000: T:224.75 /225 B:62.02 /62 B@:153 @:73
    Mesg:20:30:15.000: Warning: Seems like we missed a ok - continue sending.
    Recv:20:30:15.000: wait

    Steht. Das Problem ist das nach dem letzten G1 6 Sekunden vergehen bis die Firmware das ok sendet. Dadurch sendetdie Firmware noch ein wait was zum resend führt. Heist auch das die Firmware denkt sie hat die Zeilen gesendet, sie aber nicht geliefert wurden bzw. wie man sieht verzögert ankamen und dann zum Hänger führten. Da sind nämlich keine Fehlenden Zeilen oder Kommunikationsfehler. Nur eine Verzögerung bei der Auslieferung.

    Die Frage ist daher was blockiert Linux hier 6 Sekunden - machst du grad sd lastige Operationen? Oder hast du eine langsame/kleine sd karte. Oder ist der Prozessor aus anderen gründen überlastet - im syslog ist da grad nichts zu sehen. Aber was für ein Pi ist das? Läuft da die touch oberfläche?
  • Legion23Legion23
    edited March 2022
    Den Buffer hatte ich anfangs auf 127 stehen, als ich noch das Windows 10 Tablet genutzt hatte. Damit trat der Fehler gefühlt noch häufiger auf.
    Bei dem Verbindungstest von Repetier Server wurden mit einem Buffer von 63 weniger Fehler gemeldet als mit einem Buffer von 127, daher hatte ich das umgestellt.

    Auf dem Rapsberry läuft nichts außer Repetier Server, der hängt nicht mal am Internet und außer der SD-Karte des Betriebssystems ist kein Datenträger angeschlossen.
    Ich nutze die Touch-Oberfläche des Servers, es ist ein Raspberry Pi 4 Modell B mit 4 GB Ram.
    Die SD-Karte müsste Class 10 sein mit 32 gb.
    Wird der G-Code während des Drucks denn komplett von der SD-Karte gestreamt oder wird ein Teil im Ram zwischengespeichert? 

    Kann es auch sein, dass der Arduino Due-Controller das Problem verursacht? Vielleicht kommt der Prozessor aus irgendwelchen Gründen ins Stocken. Lässt sich das feststellen?
    Es ist seltsam, dass exakt der gleiche Fehler sowohl mit Windows 10 als auch mit dem Rapsberry auftritt.
  • RepetierRepetier
    Server speichert nur die nächsten 5000 Zeilen im RAM damit er beliebig große Dateien drucken kann ohne den RAM zu füllen.

    Da es ja kein Elektronisches Problem ist und wie du sagst auf 3 systemen auftritt, kann es am due oder der Firmware liegen. Am due hast du 2 Ports. Kannst du die Firmware umstellen, dass sie den anderen Port nutzt und testen ob der weniger Probleme macht. Dabei evtl. die 1.0.5dev nutzen - da hab ich alle bekannten bugs behoben, auch wenn da nichts usb mäßiges dabei war.
Sign In or Register to comment.