Ein Shutdown vom Button der Bedienoberfläche geht durch! Eine erneute Prüfung der Verbindung brachte nichts. Weil keine Verbindung zustande kam. Den Drucker aus und wieder eingeschaltet. Verbindung ist vorhanden. Das Ganze ist etwas nervig. Und das bei nur 2 Druckern!
Ich kriege die Krätze! Ich will schnell ein kleines Teil drucken, welches ich brauche und nichts geht! Das ist doch abartig! In Verbindungseinstellungen den gleichen Port neu angewählt, Test durchgeführt , gespeichert , geht. Warum klappt das nicht von selbst?
Bin ja schon auf der suche aber schwer, da ich immer nur unvollständige infos (logs) bekomme. Beim letzten der wäre super wenn ich ihn als log hätte, aber der Anfang fehlt und ack wurde gefiltert. Was ich sehe ist das er da die resends nicht ausführt - frage ist warum und wie ist es dazu gekommen. Fragt firmware nach resend und bekommts nicht oder fragt firmware nicht und ich sehe daher kein "Resend: 2" im log. Dann wäre es ein Fehler in der Drucker firmware. Ich arbeite also im dunkeln solange bir der fehler nicht passiert.
Also wie gesagt loog für connected.log aktivieren und wenn der wieder das Verbindungsproblem hat genau das connected.log zeigen. Da steht alles drin und dann seh ich was schief geht.
Wie du siehst stehen hier resends worauf der Code neu gesendet wird. Die sind auch ohne ACK sichtbar. Frage ist also warum fehlen die bei dir.
Ich glaube fast du hast beide konfigurationen mit einem USB Port verbunden.
Gibt es die gleichen Probleme auch wenn nur ein Drucker verbunden ist mit dem Rechner? Oder alternativ im dashboard alle Drucker bis auf einen deaktiviert sind (also grauer rahmen)?
Recv:17:21:50.300: Error:Line Number is not Last Line Number+1, Last Line: 16
Recv:17:21:51.660: T:223.12 /211.00 (73.62) B:30.0Error:Line Number is not Last Li3 /110.00 (965.44) @:0 B@:127
Recv:17:21:54.274: Error:Line Number is not Last Li T:221.92 /211.00 (75.31) B:30.3Error:Line Number is not Last Line Number+1, Last Line: 16
Recv:17:21:58.661: T:221.61 /211.00 (75.75) B:30.4Error:Line Number is not Last Li T:220.94 /211.00 (76.69) B:30.6 T:220.09 /211.00 (77.87) B:31.4 T:219.27 /211.00 (78.87) B:31.81 /110.00 (963.81) @:0 B@:127
Recv:17:21:59.272: Error:Line Number is not Last Line Number+1, Last Line: 16
Recv:17:21:59.275: echo:Unknown command: "0 M105"
Recv:17:21:59.276: ok
Recv:17:22:02.256: T:217.03 /211.00 (81.56) B:31.4Error:Line Number is not Last Li T:216.35 /211.00 (82.37) B:31.7Error:Line Number is not Last Line Number+1, Last Line: 16
Recv:17:22:59.160: Error:Line Number is not Last Line Number+1, Last Line: 16
Recv:17:23:01.157: echo T:210.74 /211.00 (90.81) B:41.0ne Number+1, Last Line: 16
Recv:17:23:09.140: T:211.05 /211.00 (90.31) B:41.3Error:Line Number is not Last Li T:210.74 /211.00 (90.81) B:41.8 T:210.62 /211.00 (91.00) B:42.4 T:210.86 /211.00 (90.62) B:42.0Error:Line Number is not Last Line Number+1, Last Line: 16
Recv:17:23:09.143: ok T:210.78 /211.00 (90.75) B:42.22 /110.00 (931.44) @:36 B@:127
Recv:17:23:48.680: Error:Line Number is not Last LiError:Line Number is not Last LiError:Line Number is not Last Li T:210.23 /211.00 (91.62) B:47.68 /110.00 (911.81) @:40 B@:127
Recv:17:23:49.068: Error:Line Number is not Last Line Number+1, Last Line: 16
Recv:17:25:18.658: r:Line Number is not Last Line N.21 /211.00 (90.06) B:59.34 /110.34 /110.00 (860.19) @:35 B@:127.34 /110.00 (860.19) @:35 B@:127.34 /110.00 (859.00) @:35 B@:127
Recv:17:25:41.695: T:210.90 /211.00 (90.56) B:62.5ok T:210.90 /211.00 (90.56) B:62Error:Line Number is not Last Li T:211.05 /211.00 (90.31) B:62.11 /110.00 (845.62) @:37 B@:127
Recv:17:25:43.726: ok T:211.09 /211.00 (90.25) B:62.64 /110.00 (842.75) @:36 B@:127
Kann die Baudrate zu hoch sein? Werde mal auf 115200 runtergehen. Mit einer höheren Rate hatte ich Probleme (allerdings mit einem 5m langem Kabel). Am Raspi ist nur ein 1m Kabel verbaut. Habe auch ein neues Druckerboard bestellt. Nicht, daß da der Wurm drin ist.
Da fehlen in diesem Fall sehr eindeutig teile der Antwort. Das so was den Server durcheinander bringt ist klar. Das passiert wenn beide Server Instanzen mit dem gleichen Drucker reden. Oder hast du sonst noch was wie Octoprint laufen das sich auch noch parallel verbindet. Das sind keine Kommunikationsfehler das sind mit ziemlicher sicherheit mehrere Instanzen am gleichen Port was einfach nicht klappen kann.
WICHTIG: ALLE Druckerkonfiguratione müssen Port /dev/serial/by-path/... haben und sich unterscheiden. Nicht nur einer, das gibt sonst mal Müll und mal klappt es je nachdem in welcher Reihenfolge die Drucker eingeschaltet werden.
Zur Zeit habe ich nur 1 Drucker angeschlossen. Ist es von Vorteil, wenn 2 laufen? Ich habe jetzt auch ein neues Board besorgt und eingebaut. Ich benutze das Original- Image von Repetier-Server. Ich wähle im Menü "/dev/serial/by-path" aus. Die Nummern unterscheiden sich (3,4,5). Ich schliesse testweise den Drucker über "Pronterface" an. Die USB- Schnittstelle des Boards ist in Ordnung. Repetier Server bekommt mit diesen Schnittstelleinstellungen keine Verbindung.
Habe jetzt probehalber auf einem anderen Raspi "Octoprint" eingerichtet. Funktioniert auf Anhieb. Das Board muß in Ordnung sein (ist ja auch neu). Edit: die Drohung mit der Octoprint-Keule hat gewirkt! Wie bei meinen Obstbäumen- zeige ich denen die Kettensäge, tragen Sie für ein Jahr! Der Drucker hat sich wieder mal verbunden (wie lange funktioniert es ???). Müssen immer beide angeschlossenen Drucker eingeschaltet sein? USB Kabel dran- Drucker aus - ist das vielleicht ein Problem?
Bei vielen Druckern wird das Board auch über USB bestromt und läuft daher. Sieht man wenn beide aktiv sind obwohl hauptstom an ist. Dann ziehen die auch am Pi strom was zu undervoltage führen kann. Andere Drucker haben eine Diode die das verhindert aktiviert. Etliche boards können dies mit einem Switch ändern.
Es muss nur der Drucker dran sein, den du starten willst. Das Problem ist das für jeden Drucker bis zu 3 Dateien existieren. /dev/ttyACME... was das wirkliche Gerät ist, /sev/serial/by-id/... was ein link zur echten ist und /dev/serial/by-path/... was auch ein Link zum echten Drucker ist. Das ist warum ich darauf rumreite. Nur weil der Problemdrucker by-path nutzt heist das ja nicht das der andere nicht die gleiche Schnittstelle nutzt, nur weil sie anders heist. Nur wenn in ALLEN anderen Konfiguration by-path mit anderem Namen steht überlappen sie sich nicht. Und dann kann immer noch ein anderes Program wie octoprint oder pronterface oder ModemManager (ist bei älteren images drauf und verbindet sich sobald er eine schnittstelle sieht bis er merkt das es kein modem ist).
Über ssh kannst du sehen ob andere die Schnittstelle gerade benutzen: sudo fuser -n file /dev/ttyACM0 Das gibt die Liste der PID zurück - hier sollte nur die Prozess-ID vom Repetier-Server erscheinen.
Bei neuen Probleme, alle Drucker deaktivieren im Kontext menu und dann nur einen aktivieren und sehen ob es klappt. Da kann von unserer seite ja keiner mehr stören und mit dem aktivieren startet er verbinden neu. Dann den anderen Drucker aktivieren. Wenn es dann zu problemen kommt teilen die sich einene SChnittstelle, ansonsten eher nicht.
Danke für die Mühe! Ich habe unterschiedliche Namen in By-Path angegeben. Es geht mal und mal nicht. Gilt für beide Drucker. Jetzt habe ich beide Drucker einzeln direkt mit dem PC verbunden. Ein Drucker macht Probleme. Die USB Schnittstelle wird mal erkannt und mal nicht. Das war nicht so, als der Drucke neu war. Die Brücke für die Stromversorgung über USB ist nicht gesteckt. Das Board dieses Druckers habe ich getauscht (lange Lieferzeit). Dieser Drucker störte möglicherweise die gesamte USB- Kommunikation. Auch nach mehrmaligem Ein- und Ausschalten funktioniert jetzt die Kommunikation beider Drucker. Allerdings: wenn ich das USB Kabel abziehe und wieder anstecke, kommt keine Verbindung zustande. Ist das so gewollt? EDIT: Jetzt funktioniert wieder nur ein Drucker..... und nach dem deaktivieren/ Aktivieren keiner mehr.
USB Kabel abziehen und neu einstecken ist eigentlich kein Problem. Kann ich bei meinen Druckern problemlos. Einzig wenn beim Druck innerhalb von sekunden zurück gestöpselt wird versucht der server ohne reset zu verbinden um den Druck fortzusetzen- Für die Drucker die gelegentlich von Linux getrennt werden.
Möglicherweise ist das auch teil deines Problems. Log mal parallel per ssh ein und gib tail -f /var/log/syslog | grep usb ein. Damit siehst du alle aktionen von Linux bezüglich usb. Also ob er die Verbindung wegen EMF/Strom trennt oder Treiberprobleme hat. Wenn auch Windows da Probleme bekommt ist das schon verdächtig und der Pi ist was USB angeht etwas empfindlich. Stell sicher das im server "USB neu verbinden bei Timeout" deaktiviert ist. Dann sind alle Meldungen von linux verursacht bzw wegen einflüsse. Selbst wenn du den Drucker im server trennst wird er nicht den usb trennen. Vielleicht gibt das ja neue Einblicke, denn normal ist das nicht. Andere haben 15 Drucker an einem pi und es läuft Problemlos.
Nov 13 12:26:29 RepetierServer kernel: [ 1446.045976] usb 1-1.5: USB disconnect, device number 9
Das ist ein Treiberfehler der zum disconnect führt. Oder hast du da Kabel gezogen?
ch341-uart converter now attached to ttyUSB0
Das sind üble chips bzw die Treiber dazu. Demnächst kommt ein neues image basierend auf Debianbullseye mit neuerem Kernel und hoffentlich auch verbesserten Treibern. Die funktionieren solange gut bis es zu Kommunikationsproblemen kommt hab ich das Gefühl. Also kurze USB kabel, gut geschirmt.
Hast du die 5V Leitungen der Drucker abgeklemmt, damit kein Strom über 5V gezogen wird? Könnte eventuell helfen.
Ich habe keinen Schaltplan der Boards. Es gibt aber einen Jumper, über den man die Boardversorgung über USB ein- und ausschalten kann. Der ist aus (keine Versorgung über USB). Das Image über die Repetier- Seite?
Ja genau, sobald ich 1.2.1 fertig habe mache ich ein neues image das auf Bullseye mit neuerem Linux Kernel basiert. Ob es was ändern wird kann ich aber nicht sagen.
Wollte eigentlich auf die neue Version warten. Aber ich muß etwas drucken... Verbindung nur bei 1 eingeschalteten Drucker über by-id Jetzt fehlt mir die Möglichkeit, die Temperaturen einzustellen. Referenzieren geht aber. Die Seite "Drucker einrichten ist total leer"... Ich mußte ein neues Heizbett hinzufügen wo ist denn das "Alte"hin? Connected.log:
Mesg:18:17:29.446: Dtr: true Rts: true
Mesg:18:17:29.461: Connection started
Mesg:18:17:29.461: Printer reset requested false
Mesg:18:17:29.461: Dtr: false Rts: false
Mesg:18:17:29.482: Dtr: true Rts: true
Recv:18:17:32.488: Send init commands because we had no signal from a reset, assuming reset not available.
Send:18:17:32.489: N1 M110
Send:18:17:32.489: N2 M105
Send:18:17:32.490: N3 M115 ; Get firmware capabilities and info
> Jetzt fehlt mir die Möglichkeit, die Temperaturen einzustellen. Referenzieren geht aber. Die Seite "Drucker einrichten ist total leer"... Ich mußte ein neues Heizbett hinzufügen wo ist denn das "Alte"hin?
Was heist leer? Screenshot? Deutet auf einen Datenfehler hin aber ohne es gesehen zu haben schwer zu sagen. Evtl wegen defekt auf sd karte? Wobei bei einem echten syntaxfehler in xml die Konfiguration durchs backup ersetzt wird.
Interessant:
Send:16:50:33.673: N22 M105
Recv:16:50:33.685: Error:Line Number is not Last Line Number+1, Last Line: 2
Send:16:50:34.672: N23 M105
Recv:16:50:34.679: Error:Line Number is not Last Line Number+1, Last Line: 2
Send:16:50:35.664: N24 M105
Recv:16:50:35.670: Error:Line Number is not Last Line Number+1, Last Line: 2
Send:16:50:36.659: N25 M105
Hier fehlen die Resend Meldungen der Firmware, weshalb der server nicht korrigieren kann. Nach dem versuchten reset steht da aber:
Send:16:53:44.882: N10 G21 ; Use mm as unit
Recv:16:53:44.884: Error:Line Number is not Last Line Number+1, Last Line: 2
Recv:16:53:44.886: Resend: 3
Recv:16:53:44.888: Ignore due to resend: ok
Plötzlich weiß die Firmware wie man resend anfragt und der server macht es korrekt und alles geht.
Wenn ich "Steuerung" anwähle, erscheint Bewegen...Temperaturen... -- eben diese Zeile war nicht vorhanden. Hatte ich noch nie, ist jetzt auch nicht mehr in Erscheinung getreten. Was kann ich in der Firmware überprüfen? Warum funktioniert die Firmware mal und mal nicht? Und warum gerade bei mir nicht. Ich bin doch nicht der einzige Marlin- Anwender... Die Verbindung mit der Auswahl by-id war heute weg. Nach Anwahl by-path war sie da. Ich muß immer wieder wechseln, damit die Verbindung da ist. Ist da kein System zu erkennen?
> Die Verbindung mit der Auswahl by-id war heute weg. Das wird von Linux gesteuert, darauf haben wir keinen Einfluß. Aber by-id willst du ja eh nicht nutzen sondern by-path. Eigentlich dürfen beide nur verschwinden, wenn der Drucker nicht da ist.
> Was kann ich in der Firmware überprüfen? Hab da so eine Vermutung das es an der Version liegen könnte. Insbesondere wenn der Drucker ein Touch display mit eigenem Prozessor hat, das per serieller Kommunikation mit Marlin redet, könnte es sein das Marlin da durcheinander kommt und teile zur falschen seriellen Schnittstelle sendet. Ich meine das ich da was gesehen hab was problematisch war und mittlerweile in Marlin 2.x behoben wurde. Hatte schon mal jemanden der meine sobald das Display abgestöselt war hätte es bei ihm geklappt. Vielleicht gibt es ja für deinen Drucker ein Firmware-Update mit neuerem Marlin.
Wer generiert diese Fehlermeldung? Marlin oder Repetier Server? So, wie ich lese, Marlin. Was genau soll die Meldung bedeuten? Ich habe die neueste Marlin Version 2.0.2 für dieses Board. Ist aber auch 2 Jahre alt. Das Board tut alles, was ich brauche. Ohne einen einzigen Aussetzer. Es hat ein Touch- Display angeschlossen. Das abzustöpseln ist keine Lösung! Brauche ich zur Bedienung. Ich weiß nicht, wieviele Tausend solcher Boards weltweit laufen. Warum lese ich so wenig von Problemen? Im Extremfall könnte ich die Originalsoftware draufspielen (ist aber älter als die jetztige) Wenn ich das Board entsorge und ein Anderes einsetze, fange ich wieder bei Null an. Welche Fehler dann kommen, weiß Niemand.
Alle Meldungen die mit Recv: anfangen kommen vom Drucker.
Das alter des Boards ist nicht das Problem, eher die Marlin version. Touch display ist keine Lösung ok, aber zum testen wäre es der einfachste weg, wobei das keine garantie ist abe rich meine dem User mit dem Bug hätte es schon geholfen weil marlin da nicht rein senden musste, bin aber nicht 100% sicher. Wenn es dann alles klappt müsstest du dann Marlin auf eine aktuelle Version ohne dem Problem aktualisieren. Dann sollte es auch wieder mit Display klappen. Wenn du die alte Konfiguration noch hast sollte der Aufwand überschaubar sein, parameter heißen ja weiter gleich für gewöhnlich. Sind nur meist neue hinzu gekommen, die man aber meist auf default lassen kann.
Die 2 Jahre bezogen sich nicht auf das Board, sondern auf die Marlin Version (2years ago). Für die Version mit dem Touch Display habe ich einfach nichts Neueres gefunden. Ich kann natürlich nur ein neues Marlin installiern. Ohne Display. Nur zum Testen. Wie soll es dann weitergehen? Es funktioniert 25 mal ohne Display. Dann wider nicht. Vielleicht, oder auch nicht. Bis dahin sind wieder 3 Wochen vergangen. Eine endlose Geschichte. "Marlin sendet zur falschen Schnittstelle". Warum soll Marlin einmal dahin senden und dann wieder wo ganz anders hin? Einfach so?
> Warum soll Marlin einmal dahin senden und dann wieder wo ganz anders hin? Einfach so? Weil es ein bug ist. Wenn man mit mehreren Schnittstellen redet muss jede auch die Antwort auf die Frage bekommen, manchmal aber auch alle eine Meldung.
> Für die Version mit dem Touch Display habe ich einfach nichts Neueres gefunden. Ist das nicht das normale Marlin? Das kann ja 2 schnittstellen und die Firmware auf dem Display ist doch unabhängig, muss nur die Antworten verstehen.
Comments
Eine erneute Prüfung der Verbindung brachte nichts. Weil keine Verbindung zustande kam.
Den Drucker aus und wieder eingeschaltet. Verbindung ist vorhanden.
Das Ganze ist etwas nervig. Und das bei nur 2 Druckern!
Ich will schnell ein kleines Teil drucken, welches ich brauche und nichts geht! Das ist doch abartig!
In Verbindungseinstellungen den gleichen Port neu angewählt, Test durchgeführt , gespeichert , geht. Warum klappt das nicht von selbst?
Also wie gesagt loog für connected.log aktivieren und wenn der wieder das Verbindungsproblem hat genau das connected.log zeigen. Da steht alles drin und dann seh ich was schief geht.
Wie du siehst stehen hier resends worauf der Code neu gesendet wird. Die sind auch ohne ACK sichtbar. Frage ist also warum fehlen die bei dir.
Ich glaube fast du hast beide konfigurationen mit einem USB Port verbunden.
Gibt es die gleichen Probleme auch wenn nur ein Drucker verbunden ist mit dem Rechner? Oder alternativ im dashboard alle Drucker bis auf einen deaktiviert sind (also grauer rahmen)?
Habe auch ein neues Druckerboard bestellt. Nicht, daß da der Wurm drin ist.
Da fehlen in diesem Fall sehr eindeutig teile der Antwort. Das so was den Server durcheinander bringt ist klar. Das passiert wenn beide Server Instanzen mit dem gleichen Drucker reden. Oder hast du sonst noch was wie Octoprint laufen das sich auch noch parallel verbindet. Das sind keine Kommunikationsfehler das sind mit ziemlicher sicherheit mehrere Instanzen am gleichen Port was einfach nicht klappen kann.
WICHTIG: ALLE Druckerkonfiguratione müssen Port /dev/serial/by-path/... haben und sich unterscheiden. Nicht nur einer, das gibt sonst mal Müll und mal klappt es je nachdem in welcher Reihenfolge die Drucker eingeschaltet werden.
Ich benutze das Original- Image von Repetier-Server. Ich wähle im Menü "/dev/serial/by-path" aus. Die Nummern unterscheiden sich (3,4,5).
Ich schliesse testweise den Drucker über "Pronterface" an. Die USB- Schnittstelle des Boards ist in Ordnung.
Repetier Server bekommt mit diesen Schnittstelleinstellungen keine Verbindung.
Edit: die Drohung mit der Octoprint-Keule hat gewirkt! Wie bei meinen Obstbäumen- zeige ich denen die Kettensäge, tragen Sie für ein Jahr! Der Drucker hat sich wieder mal verbunden (wie lange funktioniert es ???). Müssen immer beide angeschlossenen Drucker eingeschaltet sein? USB Kabel dran- Drucker aus - ist das vielleicht ein Problem?
Es muss nur der Drucker dran sein, den du starten willst. Das Problem ist das für jeden Drucker bis zu 3 Dateien existieren. /dev/ttyACME... was das wirkliche Gerät ist, /sev/serial/by-id/... was ein link zur echten ist und /dev/serial/by-path/... was auch ein Link zum echten Drucker ist. Das ist warum ich darauf rumreite. Nur weil der Problemdrucker by-path nutzt heist das ja nicht das der andere nicht die gleiche Schnittstelle nutzt, nur weil sie anders heist. Nur wenn in ALLEN anderen Konfiguration by-path mit anderem Namen steht überlappen sie sich nicht. Und dann kann immer noch ein anderes Program wie octoprint oder pronterface oder ModemManager (ist bei älteren images drauf und verbindet sich sobald er eine schnittstelle sieht bis er merkt das es kein modem ist).
Über ssh kannst du sehen ob andere die Schnittstelle gerade benutzen:
sudo fuser -n file /dev/ttyACM0
Das gibt die Liste der PID zurück - hier sollte nur die Prozess-ID vom Repetier-Server erscheinen.
Bei neuen Probleme, alle Drucker deaktivieren im Kontext menu und dann nur einen aktivieren und sehen ob es klappt. Da kann von unserer seite ja keiner mehr stören und mit dem aktivieren startet er verbinden neu. Dann den anderen Drucker aktivieren. Wenn es dann zu problemen kommt teilen die sich einene SChnittstelle, ansonsten eher nicht.
Ich habe unterschiedliche Namen in By-Path angegeben. Es geht mal und mal nicht. Gilt für beide Drucker. Jetzt habe ich beide Drucker einzeln direkt mit dem PC verbunden. Ein Drucker macht Probleme. Die USB Schnittstelle wird mal erkannt und mal nicht. Das war nicht so, als der Drucke neu war. Die Brücke für die Stromversorgung über USB ist nicht gesteckt.
Das Board dieses Druckers habe ich getauscht (lange Lieferzeit). Dieser Drucker störte möglicherweise die gesamte USB- Kommunikation.
Auch nach mehrmaligem Ein- und Ausschalten funktioniert jetzt die Kommunikation beider Drucker.
Allerdings: wenn ich das USB Kabel abziehe und wieder anstecke, kommt keine Verbindung zustande. Ist das so gewollt?
EDIT: Jetzt funktioniert wieder nur ein Drucker.....
und nach dem deaktivieren/ Aktivieren keiner mehr.
Alles ausgeschaltet. Eine Weile gewartet. Eingeschaltet (2 Drucker) Funktioniert. Kann das nicht immer funktionieren?
Möglicherweise ist das auch teil deines Problems. Log mal parallel per ssh ein und gib
tail -f /var/log/syslog | grep usb
ein. Damit siehst du alle aktionen von Linux bezüglich usb. Also ob er die Verbindung wegen EMF/Strom trennt oder Treiberprobleme hat. Wenn auch Windows da Probleme bekommt ist das schon verdächtig und der Pi ist was USB angeht etwas empfindlich. Stell sicher das im server "USB neu verbinden bei Timeout" deaktiviert ist. Dann sind alle Meldungen von linux verursacht bzw wegen einflüsse. Selbst wenn du den Drucker im server trennst wird er nicht den usb trennen. Vielleicht gibt das ja neue Einblicke, denn normal ist das nicht. Andere haben 15 Drucker an einem pi und es läuft Problemlos.
tail -f /var/log/syslog | grep usb
der 2. Drucker (ca 3 Sekunden getrennt, keine Wiederverbindung):
Das ist ein Treiberfehler der zum disconnect führt. Oder hast du da Kabel gezogen?
ch341-uart converter now attached to ttyUSB0
Das sind üble chips bzw die Treiber dazu. Demnächst kommt ein neues image basierend auf Debianbullseye mit neuerem Kernel und hoffentlich auch verbesserten Treibern. Die funktionieren solange gut bis es zu Kommunikationsproblemen kommt hab ich das Gefühl. Also kurze USB kabel, gut geschirmt.
Hast du die 5V Leitungen der Drucker abgeklemmt, damit kein Strom über 5V gezogen wird? Könnte eventuell helfen.
Verbindung nur bei 1 eingeschalteten Drucker über by-id
Jetzt fehlt mir die Möglichkeit, die Temperaturen einzustellen. Referenzieren geht aber. Die Seite "Drucker einrichten ist total leer"...
Ich mußte ein neues Heizbett hinzufügen wo ist denn das "Alte"hin?
Connected.log:
Ich mußte ein neues Heizbett hinzufügen wo ist denn das "Alte"hin?
Was heist leer? Screenshot? Deutet auf einen Datenfehler hin aber ohne es gesehen zu haben schwer zu sagen. Evtl wegen defekt auf sd karte? Wobei bei einem echten syntaxfehler in xml die Konfiguration durchs backup ersetzt wird.
Interessant:
Hier fehlen die Resend Meldungen der Firmware, weshalb der server nicht korrigieren kann. Nach dem versuchten reset steht da aber:
Plötzlich weiß die Firmware wie man resend anfragt und der server macht es korrekt und alles geht.
Was kann ich in der Firmware überprüfen? Warum funktioniert die Firmware mal und mal nicht? Und warum gerade bei mir nicht. Ich bin doch nicht der einzige Marlin- Anwender...
Die Verbindung mit der Auswahl by-id war heute weg. Nach Anwahl by-path war sie da. Ich muß immer wieder wechseln, damit die Verbindung da ist. Ist da kein System zu erkennen?
Das wird von Linux gesteuert, darauf haben wir keinen Einfluß. Aber by-id willst du ja eh nicht nutzen sondern by-path. Eigentlich dürfen beide nur verschwinden, wenn der Drucker nicht da ist.
> Was kann ich in der Firmware überprüfen?
Hab da so eine Vermutung das es an der Version liegen könnte. Insbesondere wenn der Drucker ein Touch display mit eigenem Prozessor hat, das per serieller Kommunikation mit Marlin redet, könnte es sein das Marlin da durcheinander kommt und teile zur falschen seriellen Schnittstelle sendet. Ich meine das ich da was gesehen hab was problematisch war und mittlerweile in Marlin 2.x behoben wurde. Hatte schon mal jemanden der meine sobald das Display abgestöselt war hätte es bei ihm geklappt. Vielleicht gibt es ja für deinen Drucker ein Firmware-Update mit neuerem Marlin.
Es wird M105 gesendet in die andere Zeile ist die Antwort der Firmware Recv:) , also ist eine Verbindung da.
Ich weiß nicht, wieviele Tausend solcher Boards weltweit laufen. Warum lese ich so wenig von Problemen? Im Extremfall könnte ich die Originalsoftware draufspielen (ist aber älter als die jetztige)
Wenn ich das Board entsorge und ein Anderes einsetze, fange ich wieder bei Null an. Welche Fehler dann kommen, weiß Niemand.
Das alter des Boards ist nicht das Problem, eher die Marlin version. Touch display ist keine Lösung ok, aber zum testen wäre es der einfachste weg, wobei das keine garantie ist abe rich meine dem User mit dem Bug hätte es schon geholfen weil marlin da nicht rein senden musste, bin aber nicht 100% sicher. Wenn es dann alles klappt müsstest du dann Marlin auf eine aktuelle Version ohne dem Problem aktualisieren. Dann sollte es auch wieder mit Display klappen. Wenn du die alte Konfiguration noch hast sollte der Aufwand überschaubar sein, parameter heißen ja weiter gleich für gewöhnlich. Sind nur meist neue hinzu gekommen, die man aber meist auf default lassen kann.
Weil es ein bug ist. Wenn man mit mehreren Schnittstellen redet muss jede auch die Antwort auf die Frage bekommen, manchmal aber auch alle eine Meldung.
> Für die Version mit dem Touch Display habe ich einfach nichts Neueres gefunden.
Ist das nicht das normale Marlin? Das kann ja 2 schnittstellen und die Firmware auf dem Display ist doch unabhängig, muss nur die Antworten verstehen.