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.
Sign In or Register to comment.