Repetier-Server 1.0.0. oder 1.0.1 mit der MMU2S im Single Modus

Repetier-Server 1.0.0. oder 1.0.1 mit der MMU2S im Single Modus. Ich bekomme keine Extruderauswahl mehr. Das heisst ich muss immer den g-code anpassen ansonsten nimmt er einfach den 5.! Was aber blöd ist da ich Teile öfter mal mit anderen Farben Drucke und nun immer wieder daran denken muss den Code anzupassen.

Comments

  • Problem ist das Tx kein echter GCode Befehl ist. Daraus wird daher T x und das versteht der prusa wieder nicht. Wenn du die Zeile im start gcode als
    #Tx

    schreibst wird sie 1:1 gesendet und es funktioniert wie du es dir vorstellst. Werd das für 1.0.2 korrigieren das er das auch so erkennt. 
  • Repetier-Server 1.0.0. oder 1.0.1 mit der MMU2S im Single Modus. Ich bekomme keine Extruderauswahl mehr. Das heisst ich muss immer den g-code anpassen ansonsten nimmt er einfach den 5.! Was aber blöd ist da ich Teile öfter mal mit anderen Farben Drucke und nun immer wieder daran denken muss den Code anzupassen.
    After upgrade i have same problems as 3D_Drehzahl73
  • edited January 2
    Repetier said:
    Problem ist das Tx kein echter GCode Befehl ist. Daraus wird daher T x und das versteht der prusa wieder nicht. Wenn du die Zeile im start gcode als
    #Tx

    schreibst wird sie 1:1 gesendet und es funktioniert wie du es dir vorstellst. Werd das für 1.0.2 korrigieren das er das auch so erkennt. 
    Habe das selbe Problem seit dem Update aber mit #Tx klappt es. Man muss aber auch noch ein # bei Tc machen.. sonst fängt er gleich mit der Purge Line an ohne den Blob an Anfang den es ja braucht um den nötigen Materialfluß zu gewährleisten!
    Also bitte bei 1.0.2 #Tc auch noch korrigieren!
    Vielen Dank schonmal!
  • Selbes Problem besteht beim GCode T? also bitte auch korrigieren. Danke
  • Tc sollte in 1.0.1 schon klappen. Für 1.0.2 hab ich T? auch noch aufgenommen.
  • Repetier said:
    Tc sollte in 1.0.1 schon klappen. Für 1.0.2 hab ich T? auch noch aufgenommen.
    Vielen Dank!

    Zur Info, in der MK3/S/+ Firmware gibt es folgenden Hinweis in dem File "Marlin_main.cpp", evtl. hilft es etwas, alle aktuellen T-Cmd. zu berücksichtigen. Aber wer weis, was später noch folgt.

    //!  For MMU_V2:
    //! @n T<n> Gcode to extrude at least 38.10 mm at feedrate 19.02 mm/s must follow immediately to load to extruder wheels. <n> = 0...5
    //! @n T? Gcode to extrude shouldn't have to follow, load to extruder wheels is done automatically
    //! @n Tx Same as T?, except nozzle doesn't have to be preheated. Tc must be placed after extruder nozzle is preheated to finish filament load.
    //! @n Tc Load to nozzle after filament was prepared by Tc and extruder nozzle is already heated.

    Beste Grüße und gutes, erfolgreiches Neues Jahr @all

  • Stimmt irgendwas ist noch schief, bei mir hat er im MMU Modus mitten drin die falsche Farbe gezogen, also wieder T4 statt das ausgewählte.
    Bei den PI Images kann man nur das neuste herunter laden, da ich so schnell nicht mit dem Update rechne, wie komme ich ans alte IMG?

    Gruss und Dank und frohes Neues
  • T0 - T4 sind normale Befehle und werden korrekt gesendet. Das mit der falschen Farbe passiert mir allerdings auch manchmal und ich frage mich warum er das macht. Hab ich aber auch schon mit 0.9x gehabt. Möglicherweise wenn er Probleme beim einzug hat, dann geht er zum letzten Filament zurück. Ist aber nur eine Vermutung. Muss ich unbedingt noch mal mit logging wiederholen.

    Grundsätzlich kannst du bei neuem image auch alte versionen des servers drüber installieren.
  • Ok, habe leider gerade festgestellt das ich das Gehäuse vom Philipp gedruckt habe und man dort nicht einfach die Karte entfernen kann. Daher switche ich erstmal wieder zum Octoprint testen mit einem anderen PI.
    Ich sehe ja wenn die 1.0.2 da ist. 2 PI Mit Repetier macht kein Sinn.
    Ja das mit dem Farbwechsel mag ja stimmen, bei mir ging er aber zu einem Slot wo nichts drin war und gar nicht zu dem Objekt gehört hat. Jetzt beim letzten druckt hat er wieder fertig gedruckt aber der Repetier steht bei 98% nicht fertig.
    Hoffe die neue Version ist dann stable.
  • Funktioniert wieder, danke fürs Update 1.0.2
  • Hallo, danke für das Update 1.0.2!
    Es gibt bei mir jedoch noch immer ein Problem mit der MMU2 und dem GCode "T?".
    Die V1.0.2 funktioniert bei Anschluss des Raspi 3B+ an das Einsy-Board per USB Verbindung ohne Probleme.
    Meine Drucker sind jedoch normalerweise alle per GPIO-Port mit dem Einsy verbunden und nicht per USB.
    Dabei sehe ich folgenden Protokollfehler im Vergleich zur Vorgängerversion 0.94.3, die problemlos funktioniert.
    Zu Beginn der Zeile mit dem GCode "T?" fehlt bei der V1.0.2 die typische Zeilennummer "Nxxx", was in der Folge zum Abbruch des Drucks führt. Hier eine Kopie von der Ausgabe auf der Konsole in beiden Versionen zum Vergleich:

    V1.0.2:
    Send:17:04:12.027: N294 G1 Z0.4 F1000.0
    Recv:17:04:12.033: MMU <= 'F3 0'
    Recv:17:04:12.158: ok
    Recv:17:04:12.160: MMU <= 'F4 0'
    Recv:17:04:12.282: ok
    Send:17:04:12.283: T? ; select filament # & load filament to extruder // <---- Zeilennummer fehlt (Nxxx)!
    Recv:17:04:12.287: ok (2)
    Send:17:04:12.287: N295 G1 X55.0 E8.0 F2000.0
    Send:17:04:12.461: M117 ETE 00:53:11
    Recv:17:04:12.464: ok
    Send:17:04:12.464: N296 M73 P0 R53 Q0 S53
    Recv:17:04:12.465: Slow command added:M400 ; Wait for current moves to finish
    Send:17:04:12.465: N297 M400 ; Wait for current moves to finish
    Recv:17:04:12.473: Error:Line Number is not Last Line Number+1, Last Line: 294
    Recv:17:04:12.474: Resend: 295
    Recv:17:04:12.474: Ignore due to resend: ok
    Send:17:04:12.566: Resend: N295 G1 X55.0 E8.0 F2000.0

    V0.94.3:
    Send:17:51:32.155: N124 G1 Z0.4 F1000.0
    Send:17:51:32.160: N125 T? ; select filament # & load filament to extruder // <---- Zeilennummer vorhanden (N125)!
    Recv:17:51:32.161: MMU <= 'F3 0'
    Recv:17:51:32.286: ok
    Recv:17:51:32.287: MMU <= 'F4 0'
    Recv:17:51:32.410: ok
    Send:17:51:32.411: N126 G1 X55.0 E8.0 F2000.0
    Recv:17:51:32.411: ok
    Send:17:51:32.412: N127 M73 P0 R53 Q0 S53
    Recv:17:51:32.414: ok
    Recv:17:51:32.415: Slow command added:M400 ; Wait for current moves to finish
    Send:17:51:32.415: N128 M400 ; Wait for current moves to finish
    Recv:17:51:44.981: echo:busy: paused for user (6)
    Recv:17:51:45.792: mmu_get_response - begin move: T-code
    Recv:17:51:45.843: MMU <= 'T0'
    Recv:17:51:45.894: Unloading finished 2
    Recv:17:51:47.226: echo:busy: processing
    Recv:17:51:47.933: mmu_get_response - begin move: load
    Recv:17:52:10.083: echo:busy: processing (11)
    Recv:17:52:10.230: MMU <= 'A'
    Recv:17:52:10.807: MMU => 'ok'
    Recv:17:52:10.861: mmu_get_response() returning: 1
    Recv:17:52:16.390: echo:busy: processing (3)
    Recv:17:52:18.194: MMU can_load:
    Recv:17:52:18.462: OOOOOOOOOOOOecho:busy: processing
    Recv:17:52:18.817: OOOOOOOOOOOOOOOOOO succeeded.
    Recv:17:52:22.600: echo:busy: processing (2)
    Recv:17:52:23.404: ok

    Der GCode ist in beiden Fällen aus der gleichen Datei, also das selbes Objekt.
    Es macht auf mich den Eindruck, als wenn die Kommunikation zwischen R-Server und Drucker (Einsy-Board FW 3.8.1) nicht synchron arbeiten, da der R-Server wie es aussieht das "ok" vom Drucker nicht abwartet und bereits ohne die Antwort vom Drucker abzuwarten schon den nächsten GCode sendet. Oder ist die Ausgabe der Konsole zeitlich nicht korrekt?

    Danke, SIE-Maker
  • Noch eine kleine Frage, sorry, konnte nirgends eine Antwort darauf finden, gibt es eine Anleitung, zu einem downgrade der R-Server Firmware ohne die SD-Karte für den Raspi neu flashen zu müssen? Ein Update funktioniert ja auch automatsch.

    Danke, SIE-Maker  :)
  • Das T? ohne Zeilennumme rgesendet wird ist absicht, da es kein gültiger g-code ist. Solche Zeilen senden wir einfach 1:1. In anderen Firmwaren gibt es davon noch viel mehr. Es ist aber eigentlich kein Problem.

    Send: 9:25:53.893: N423378 G1 Y-3.0 F1000.0
    Recv: 9:25:53.900: ok
    Send: 9:25:53.900: N423379 G1 Z0.4 F1000.0
    Recv: 9:25:53.908: ok
    Send: 9:25:53.908: Tc
    Recv: 9:25:53.982: Additional load attempt nr. 0
    Recv: 9:25:53.983: mmu_get_response - begin move: load
    Recv: 9:25:53.986: MMU <= 'C0'
    Recv: 9:25:54.154: MMU <= 'A'
    Recv: 9:25:55.100: MMU => 'ok'
    Recv: 9:25:55.104: mmu_get_response() returning: 1
    Recv: 9:25:56.165: echo:busy: processing
    Recv: 9:25:58.262: echo:busy: processing
    Recv: 9:26:00.359: echo:busy: processing
    Recv: 9:26:01.036: MMU can_load:
    Recv: 9:26:01.638: OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO succeeded.
    Recv: 9:26:02.456: echo:busy: processing
    Recv: 9:26:04.563: echo:busy: processing
    Recv: 9:26:05.533: ok
    Send: 9:26:05.534: M117 Layer 0/150
    Recv: 9:26:05.537: ok
    Send: 9:26:05.538: N423380 M105
    Recv: 9:26:05.556: ok T:214.6 /215.0 B:61.1 /60.0 T0:214.6 /215.0 @:33 B@:38 P:28.0 A:33.5
    Send: 9:26:05.557: N423381 M105
    Recv: 9:26:05.573: ok T:214.6 /215.0 B:61.1 /60.0 T0:214.6 /215.0 @:33 B@:38 P:28.0 A:33.5
    Send: 9:26:05.573: N423382 G1 X55.0 F2000.0
    Recv: 9:26:05.587: ok

    Hab auch mal T? an meinen Prusa gesendet und er hat sich auch nicht beschwert und nach dem Filament gefragt. Nutze aktuell die neueste Prusa Firmware.

    Schon mal testweise im Terminal einfach T? gesendet? Bei mir gehts wie gesagt ohne probleme. Wie man oben sieht senden wir auch bei M117 keine Zeilennummern weil einige alte Marlin Varianten das nicht mögen.

    Für Downgrade kann man prinizipiell einfach mit sudo dpkg wie im Manual beschrieben eine alte Version drüber bügeln. Kann aber dazu führen das in Konfigurationen etwas fehlt, falls wir grad etwas geändert haben bzw. das die neuen Daten dann beim nächsten speichern abhanden kommen da die alte Firmware sie nicht kennt und schriebt. Abgesehen davon sollte das normal klappen.
  • @Repetier So mit 1.0.3 spinnt das Teil schon wieder, meistens kommt die Abfrage aber ab und zu bei dem gleichen Bauteil nimmt er mal 5 dann mal die 2! Nebenbei macht er ganz andere komische Dinge, Gelb ist über den Repetier gedruckt (angefangen) grün über die SD (gleiches STL). Eine Idee? Ich muss nun zwangsweise den Repetier abschalten, da es so kein Sinn macht. (das sind keine fäden die er gezogen hat, sondern sauber 1. Layer Ebene. Neues Drucker Profil hab ich schon angelegt.
  • Das ist verrückt. Wegen einiger großer Projekte ist mein Prusa im Dauereinsatz und macht keine Probelme.MMU ist zwar jetzt aus weil mir das Filament immer gerissen ist aber die extra Linien sind ja auch keine Filamentwechsel.

    Ist beides der gleiche G-Code?

    Bei Tx, Tc, T? füg ich wieder Zeilennummer und checksumme an, sollte also nicht übersehen werden.
    Wie wählst du das Bauteil das er mal 5 mal 2 nimmt? Ich druck ja meist single on mmu und da musste ich am prusa das Filament wechseln und dort hat er auch gefragt. In dem Fall hat man keinen einfluß. Ansonsten würde er doch T2 oder T5 schreiben und den Extruder vorgeben? Oder hab ich was übersehen.

    Apropo neue sDruckerprofil - alten auch deaktiviert? Nicht das beide gleichzeitig reden das gibt immer Fehler.
  • Hoi ja der alte ist deaktiviert, ja es ist das gleiche STL. Hatte den Slicer im Verdacht und noch mal neu, gleiches Spiel.
    Ich lade den g-Code via Repetier Monitor hoch. Wähle es dann entweder am 7" oder über den Webbrowser aus. Also einfach auf drucken drücken. Selbst wenn ich schon ein Filament vorlade wirft er es raus und nimmt einfach ein anderes. Manchmal behält er es auch ist immer etwas Lotterie.
    Ich glaube ich muss den repetier doch mal ganz neu machen. Leider muss ich dazu alles zerlegen um an die Karte zu kommen, mein 2. Pi ist ein 3+ und der aktuelle ein 4er
  • Repetier said:

    Bei Tx, Tc, T? füg ich wieder Zeilennummer und checksumme an,
    Danke! Damit funktionieren dann auch wieder Kommentartrenner ";" mit Kommentaren innerhalb der MMU2 T-Cmd-Zeile.  ;)
    Die T-Cmd's sind übrigens schon seit langem offizielle Marlin GCodes und keine Prusa Spezialitäten mehr.
    Marlin schreibt außerdem die Zeilennummer mit Checksumme explizit für jede GCode Zeile bei der seriellen Übertragung vor, ebenso das Abwarten der Quittung "ok", sonst kann es bei unerwarteten Fehlerbedingungen im Drucker zu einem "Full Rx Buffer" kommen. Einem Überlauf des Empfangsbuffer und damit zu Protokollfehlern. 

    @3D_Drehzahl73 ;
    Probiere mal die PRUSA FW 3.9.2 aus, die aktuelle FW 3.9.3 funktioniert mit dem R-Server derzeit nicht fehlerfrei. Es ist allerdings nicht jeder MK3 betroffen, derzeit wird an dem Problem auch bei PRUSA gearbeitet. Octoprint hält die Marlin Spezifikation soweit ein und funktioniert, soweit bekannt, auch mit der FW 3.9.3.

    "leptun commented 2 days ago
    I know the symptoms are different, but the thing is that nothing changed in that part of the code between 3.9.2 and 3.9.3. There still is no idea as to why 3.9.3 has random issues all over the place, so even something as unrelated as this could be caused by the mystery issue.
    There have been reports of garbled menus in 3.9.3, so having a crash during the SD menu isn't that far fetched considering that the SD menu is notorious for being weirdly implemented."

    https://github.com/prusa3d/Prusa-Firmware/issues/2989

    https://github.com/prusa3d/Prusa-Firmware/issues/2954

  • Zum Glück ist Prusa in Marlin drin so dass es auch bei Marlin klappen sollte:-)

    Das mit der Checksumme ist mir neu. Ein Problem war das bei alten Marlin checksumme und M117 nicht klappten. Daher werden die ohne Zeilennummer gesendet. Denn bei Zeilennummer wird auch Checksum glaube ich erwartet.

    >ebenso das Abwarten der Quittung "ok", sonst kann es bei unerwarteten Fehlerbedingungen im Drucker zu einem "Full Rx Buffer" kommen. Einem Überlauf des Empfangsbuffer und damit zu Protokollfehlern. 
    Hast du dazu eine Referenz? Wir machen das ja Grundsätzlich um schneller zu kommunizieren und den Puffer nicht leer laufen zu lassen. Bei emergency befehlen muss man es sogar machen. Und marlin hat ja auch noch einen Buffer um 4 Befehle zu speichern, auch wenn sich der Dummerweise auf alle Eingänge verteilt weshalb man nicht davon ausgehen kann. Was wir aber machen ist den zulauf begrenzen und auf ok warten bevor der Serielle Eingangsbuffer voll ist. Ging auch bisher immer. Aber hab auch schon von "Full RX Buffer" gehört aber noch nicht gefunden wann das genau ausgelöst wird.
  • Ja, wenn eine Zeilennummer (Nnnn) gesendet wird, muss auch eine Checksumme (*nnn) am Ende folgen. Jedoch wird eine solche Zeile nur bis zum Auftreten des Kommentartrenners ";" in die Marlin cmd-queue weitergeleitet.
    Eine Zeile ohne Zeilennummer und Checksumme darf keinen Kommentar enthalten, ansonsten wird die kmpl. Zeile bei Auftreten eines ";" verworfen.
    Euer Algorithmus zum handeln der "ok" Meldung schlägt in dem Moment fehl wenn der Drucker mehr als diese 4 Befehle in eine bestehende queue einfügen muss, z. B. beim "crash-detect", "power-panic", Filament-Sensor oder spez. MMU Befehle, evtl. auch schon beim M600/601/602/603. Also überall dort wo die Firmware von sich aus eigene GCodes in die queue einfügen möchte/muss und dabei die aktuell freie Kapazität im Buffer überschreitet. Dabei wird der Buffer dann überladen und mit "Full Rx Buffer" quittiert, ein Verlust von bereits gesendeten Gcodes ist dann unvermeidlich, ein "flush buffer" ist die Folge. Wenn man auf der sicheren Seite sein will, weil man nicht genau wissen kann wie viele Befehle die Firmware von sich aus zu dem Zeitpunkt einfügen will/muss, bleibt nur das strikte Abwarten auf das nächste "ok", auch auf die Gefahr hin dabei Zeit zu verlieren. Sonst droht ein kmpl. Druck verloren zu gehen!
    Die Quelle für diese Infos findet sich im jeweiligen Source-Code der Firmware vom Drucker. Weil das recht schwierig  ist, einfach strikt die Quittung abwarten und nicht versuchen den Buffer im Voraus zu füllen.
    Solange keine besonderen Ereignisse am Drucker auftreten, mag das auch auf Eure Weise recht lange funktionieren.

    Danke, SIE-Maker  :)
  • Ok, danke für die Info. Ping-Pong modus an ist ja genau dieser langsame Kommunikationsmodus. Ist ja nicht so als ob wir es nicht können:-) Aber der Geschwindigkeitsunterschied ist schon ordentlich und oft der Grund warum es bei uns nicht stottert wo andere hosts schon stottern.

    Werd mir das mal genauer ansehen. Vielleicht einführen das einige Befehle zu einem nur 1 Befehl in der Warteschlange führen. Dann kann man die Geschwindigkeit behalten und die Problematischen Befehle entlasten. Wobei ja auch die eigentlich aufpassen sollten ob ein buffer frei ist.
  • Sorry vielleicht liege ich auch falsch. Aber ein Buffer ist ja nichts anderes als ein Schieberegister. Was zuerst reingeht kommt zuerst heraus. Also FIFO, first in first out. Wenn du den Buffer vollschreibst, bevor die Firmware das kann, dann löst du doch Ereignisse aus, die du gar nicht willst?
  • Ja ist ein FIFO buffer. Aber die Firmware entscheidet ja wann sie liest. Ich darf halt nur so viel reinschreiben das er garantiert nicht überläuft und daher ist der buffer size im server im Grunde die länge dieses FIFO buffers. Unabhängig von den 4 Befehlsbuffern die Marlin noch zusätzlich hat.
  • Also ich habe jetzt noch einige male getestet. Neuen Drucker eingerichtet, neuen Drucker entfernt. Egal was ich mache er lädt wieder nur sporadisch ein Filament und aussuchen welches kann ich nur ab und zu. Von der SD Karte bekomme ich jedes Mal die Aufforderung den Extruder zu wählen. Spannend war ja das der 2. Drucker die drucke immer beendet hat und der Ursprüngliche meistens aber nicht immer obwohl der Drucker schon fertig ist. Ich mache nun den aller letzten versuch und baue das 7" Display Gehäuse auseinander und flashe die Karte neu da so das Teil nicht brauchbar ist. Nach dem Update dachte ich es ist gelöst, aber das waren wohl nur sporadische korrekte Funktionen.
  • Aktiviere in der Konsole echo
    M111 S7

    Dann wiederholt prusa die Befehle die gesendet werden. Versuch die Problematischen Befehle und siehe ob sie korrekt vom Drucker wiederholt werden oder verfälscht wurden.

    Hast du letzte prusa firmware 3.9.1 denke ich drauf?

  • 3.9.3 ist die aktuelle. 
    Meine ist von Bondtech bzgl. den Steps
  • edited February 3
    Repetier said:
    Aktiviere in der Konsole echo
    M111 S7

    Dann wiederholt prusa die Befehle die gesendet werden. Versuch die Problematischen Befehle und siehe ob sie korrekt vom Drucker wiederholt werden oder verfälscht wurden.

    Hast du letzte prusa firmware 3.9.1 denke ich drauf?

    Wenn ich in der Konsole M111 S7 eingebe kommt Unknown M code: $4586 M111 S7

    Ich gebe es nun eh auf, habe mal ein komplett neuen Repetier erstellt und der kann sich zwar mit dem Drucker verbinden aber die Druckstart Symbol fehlt. 
    Der alte Repetier mit 2 Druckern macht der eine ursprünglich eingerichtete am wenigsten Fehler ausser das ich das Filament im G-Code vorgeben muss und der Server es nicht schnallt das der Drucker fertig ist.

    Lustig wenn ich den deaktiviere und den 2 mit exakt den gleichen Einstellungen nutzen druckt der nur misst, also jede 2-4 Linie kein Filament. 
    Der andere Druckt gleiches Modell sauber. 

    Ach ja wenn ich vor dem TC wieder die RRaute setze geht das Filament auswählen, heisst der Bock von 1.0.1 der mit 1.0.2 weg war ist bei 1.0.3 wieder drin. 
    Schade das, das Backuptoll nicht die Server Version mit sichert, dann hätte ich noch ne alte 93er gehabt.
  • 3D_Drehzahl73 Du hast recht. Konnte es jetzt nachvollziehen. Bei diesem Sonderfall konnte es passiert das der Befehl als Kommentar markiert war weil das Feld nicht explizit gesetzt wurde. In dem Fall wurde der Befehl einfach nicht gesendet und fehlt dann in der Ausgabe. Aktuell reicht es # davor zu stellen, ab 1.0.4 wird er sie korrekt als gcode melden und damit auch durch Prüfsumme die Ausführung sicherstellen.
  • Hoi @Repetier
    habe gerade 1.0.4 installiert, jop funktioniert wieder, thx
Sign In or Register to comment.