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

3D_Drehzahl73

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.

Repetier

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.

Andrea

<a rel="nofollow" target="blank">3D_Drehzahl73</a> said:

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 <a rel="nofollow" target="_blank" title="Link: null">3D_Drehzahl73</a>

Stony

Repetier wrote
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!

SIEMaker

Selbes Problem besteht beim GCode T? also bitte auch korrigieren. Danke

Repetier

Tc sollte in 1.0.1 schon klappen. Für 1.0.2 hab ich T? auch noch aufgenommen.

SIEMaker

Repetier wrote
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

3D_Drehzahl73

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

Repetier

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.

3D_Drehzahl73

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.

3D_Drehzahl73

Funktioniert wieder, danke fürs Update 1.0.2

SIEMaker

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

SIEMaker

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 :)

Repetier

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.

3D_Drehzahl73

@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.

Repetier

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.

3D_Drehzahl73

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

SIEMaker

<a rel="nofollow" target="blank">Repetier</a> 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

Repetier

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.

SIEMaker

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 :)