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
#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.
Also bitte bei 1.0.2 #Tc auch noch korrigieren!
Vielen Dank schonmal!
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:
Beste Grüße und gutes, erfolgreiches Neues Jahr @all
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
Grundsätzlich kannst du bei neuem image auch alte versionen des servers drüber installieren.
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.
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:
V0.94.3:
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
Danke, SIE-Maker
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.
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.
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
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
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.
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
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.
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?
Meine ist von Bondtech bzgl. den Steps
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.
habe gerade 1.0.4 installiert, jop funktioniert wieder, thx