›

Fehler M1 Stop - Drucker blockiert oder Kommunikationspuffer voll

DaniSoBDaniSoB
edited April 2022 in Repetier-Server
Guten Tag zusammen,

ich hab das Problem, das mir Repetier Server diesen Fehler anzeigt:

Message from your Printer:
M1 Stop
Hinweis: Wenn der Drucker blockiert ist und die Kommunikationspuffer voll sind, werden die Anworten möglicherweise nicht ausgeführt.

Der Fehler tritt nur beim drucken längerer Druckaufträge auf.

In der Console steht folgendes dazu:

Mesg:9:56:57.745: Warning: Communication timeout - resetting communication buffer.
Mesg:9:56:57.745: Connection status: Buffered:47, Manual Commands: 1, Job Commands: 5000
Mesg:9:56:57.745: Buffer used:47 Enforced free byte:0 lines stored:1

Hab jetzt schon alle möglichen größen des Eingangspuffers getestet, aber Egal ob ich auf 63 oder 255 gehe, der Fehler kommt immer bei größeren Drucken.

Drucker ist ein Anycubic i3 Mega S.

Ich hab an dem gleichen Server noch einen Ender 3V2 dran und bei diesem tritt der Fehler nicht auf.

mfg Daniel

Comments

  • RepetierRepetier
    Wo kommt das M1 Stop her? Laut dokumentation
    https://marlinfw.org/docs/gcode/M000-M001.html

    Stoppt das den Drucker. Erst das senden von M108 wenn emergency parser aktiv ist gibt den Drucker wieder frei. Oder halt den ok Knopf am Drucker drücken.

    Hat also erst mal nicht mit Kommunikationspuffern zu tun - liegt nur daran was M1 macht.

    Wenn du nicht siehst wo es herkommt aktiviere mal logging für den Druck. Möglicherweise gibt es ja ein Problem weshalb er mit M1 warten will - evtl Filament sensor getriggert- wobei das neu wäre. Mein Anycubic I3 hat nicht mal eine Meldung gemacht. Oder hast du eine alternative Firmware aufgespielt?
  • DaniSoBDaniSoB
    edited April 2022
    Sobald ich am Raspberry Bildschirm die M1 Nachricht bestätige, geht der Druck ganz normal weiter und ein paar Minuten später kommt der gleiche Fehler wieder und das Spiel geht dann so lange, bis der Druck fertig ist oder ich „Linien“ zum drucken kleiner werden.

    Beim nächsten Druck füge ich das Log an.

    Firmware ist von „Knutwurst“ die 1.4.3
    Filament Sensor nehm ich nicht her, der ist mit einem Stück Filament immer belegt.
  • RepetierRepetier
    Ja die Firmware vom Knutwurst hatte ich auch drauf, nur ohne dem M1 Problem. Hoffentlich löst es sich dann mit dem Log wo es herkommt. Kannst du beim hänger möglicherweise auch in der Konsole schon sehen.
    Aber gut zu wissen das wir offenbar den Unblock schon direkt mit senden und das klappt. So soll M1 ja auch sein. Nur wenn du keine pausen im g-code eingebaut hast ist das natürlich unschön.
  • DaniSoBDaniSoB
    edited May 2022
    so hab jetzt heute nochmal einen Druck gestartet und das Log + Bilder gemacht.

    Der erste M1 Stop kommt um 22:53 und dann alle paar Minuten.


    Log:
    https://1drv.ms/u/s!AjJ3oVT4j1Wig5Y6_8JrHCg4fuxzeA?e=IyryJk

    Bild vom Server Display:
    https://1drv.ms/u/s!AjJ3oVT4j1Wig5Y8JJe74l7ir2PGBw?e=4gParL

    Mfg Daniel
  • RepetierRepetier
    Probleme scheinen aber schon hier anzufangen:
    Mesg:22:49:24.180: Warning: Communication timeout - resetting communication buffer.
    Kontext:
    Send:22:49:20.171: N10101 M205 X10 Y10
    Recv:22:49:21.048:  T:200.03 /200.00 B:60.00 /60.00 @:61 B@:43
    Recv:22:49:22.048:  T:200.03 /200.00 B:60.00 /60.00 @:61 B@:43
    Recv:22:49:23.049:  T:200.00 /200.00 B:60.00 /60.00 @:62 B@:43
    Recv:22:49:24.049:  T:200.00 /200.00 B:60.00 /60.00 @:62 B@:43
    Mesg:22:49:24.180: Warning: Communication timeout - resetting communication buffer.
    Mesg:22:49:24.180: Connection status: Buffered:23, Manual Commands: 1, Job Commands: 5000
    Mesg:22:49:24.180: Buffer used:23 Enforced free byte:17 lines stored:1
    Send:22:49:24.181: M117 Layer 6/136
    Recv:22:49:25.049:  T:200.00 /200.00 B:60.00 /60.00 @:62 B@:43
    Recv:22:49:25.174: echo:busy: processing
    Recv:22:49:25.501: ok

    Nach dem M205 4 Sekunden keine Antwort was timeout triggert. Leider ist Marlin kompiliert ohne Zeilennummern in "ok" zu antworten was die Zuordnung schwer macht. Wenn du die Quellen hast bitte in configuration_adv.h aktivieren und am besten wait gleich mit aktivieren. Ist stabiler in der Kommunikation mit diesen informationen zu arbeiten.

    Ich sehe das passiert auch an anderen stellen. Grund scheint das busy nicht nach 2 sekunden gesendet wird wie es defaultmäßig passiert. Scheint als ob die Firmware hier mit 5s kompiliert wurde. Dann must du im server 6s wählen damit es nicht zu falschen timeouts kommt. Ist halt in der Firmware offenbar zu langsam eingestellt.

    Dein M1 ist nichts was wir senden, mehr ein internes:
    Recv:22:53:18.156:  T:200.00 /200.00 B:60.00 /60.00 @:61 B@:43
    Recv:22:53:19.156:  T:200.00 /200.00 B:60.00 /60.00 @:61 B@:43
    Recv:22:53:20.157:  T:200.00 /200.00 B:60.00 /60.00 @:61 B@:43
    Mesg:22:53:20.258: Warning: Communication timeout - resetting communication buffer.
    Mesg:22:53:20.258: Connection status: Buffered:23, Manual Commands: 0, Job Commands: 5000
    Mesg:22:53:20.258: Buffer used:23 Enforced free byte:0 lines stored:1
    Send:22:53:20.258: Resend: N10266 G0 F6000 X77.575 Y44.2
    Recv:22:53:21.157:  T:199.97 /200.00 B:60.00 /60.00 @:62 B@:43
    Recv:22:53:21.256: echo:busy: processing
    Recv:22:53:21.804: ok
    Send:22:53:21.804: Resend: N10267 M205 X8 Y8
    Recv:22:53:21.805: ok
    Send:22:53:21.805: Resend: N10268 G1 F1500 X177.631 Y144.256 E746.62395
    Recv:22:53:22.005: ok
    Send:22:53:22.006: Resend: N10269 M205 X10 Y10
    Recv:22:53:22.158:  T:199.97 /200.00 B:60.00 /60.00 @:62 B@:43
    Recv:22:53:23.157:  T:199.91 /200.00 B:59.99 /60.00 @:63 B@:44
    Recv:22:53:24.158:  T:199.86 /200.00 B:60.00 /60.00 @:64 B@:43
    Recv:22:53:24.845: //action:prompt_end
    Recv:22:53:24.845: //action:prompt_begin M1 Stop
    Recv:22:53:24.845: //action:prompt_button Continue
    Recv:22:53:24.845: //action:prompt_show

    Was du im server siehst ist aufgrund der //action anfrage von Marlin. Da es aber umringt ist von vielen timeouts nehme ich an, da gibt es einen Zusammenhang. Das passiert vermutlich wenn du viele lange moves hast und sich das Timeout Problem nicht schnell genug normalisiert.

    Versuch wie gesagt erst mal timeout im server höher zu setzen, damit die Timeouts verschwinden. Vermutlich erledigt sich das M1 problem damit auch. Eine Begründung ist hier nicht zu sehen.

  • DaniSoBDaniSoB
    Timeout habe ich nun auf 6 Sekunden gestellt und seitdem klappt's ohne Probleme.
    Wenn ich mal mehr Zeit hab, schau ich mir das mal nochmal genauer an.
    aber fürn Anfang, Danke für deine Hilfe.

    Mfg Daniel
Sign In or Register to comment.