RPi CM4 auf Manta M4P - keine Verbindung zum Drucker.

dennis_stratanex

Ich habe zum testen ein Manta M4P Board mit CM4 (CB1 auch schon ausprobiert - gleiches Problem) im Drucker installiert.

Repetier-Server installation funktioniert, eine Klipper config, die mit Mainsail und Fluid zu einem funktionierenden Drucker führt ist auch installiert. Leider sagt mir der Repetier Server leider ständig, dass die Serielle Verbindung zum Drucker nicht hergestellt werden kann -> "Printer not ready".

Gibt es etwas, das ich beachten muss mit dem CM4 und dem Manta M4P?

Repetier

Wichtig firmware klipper auswählen, dann die Klipper installation wie in der Anleitung beschrieben installieren.
Port ist nicht der serielle des Druckers sondern die von klipper. Wird bei der installation korrekt gesetzt.

Danach wie beschrieben deine Klipper Konfigurationsdatei eintragen mit dem korrekten Port for den Drucker.

Beim installieren wichtig die Klipper version wählen die zu deiner Konfig past - 0.10 und master sind nicht zueinander kompatibel da sich etliche klipper Befehle geändert haben! Evtl. must du klipper firmware auch neu übersetzen damit es passt. Sieh dir abe runbedingt die ANleitung zu klipper an.

CM4 hab ich nicht abe rdenke der verhält sich wie ein pi. Denke eher die Konfiguration ist falsch da das bei Klipper ja sehr umständlich ist bis das Grundsystem läuft.

dennis_stratanex

Klipper wurde wie auf allen anderen Klipper Druckern unserer Farm, die mit Pi Zero 2 laufen, installiert. Der Port wurde auch auf den von Repetier erstellten Slug gesetzt. In der config habe ich Slug und realen Serial Port ausprobiert.

Auf MCU und SBC lief die gleiche Version Klipper.

Nach erfolglosen Versuchen Repetier Server zum laufen zu kriegen habe ich kurzerhand ein FluiddPi Image auf den CM4 eMMC geladen. Dieselbe Config hat hier direkt zu einem laufenden Drucker geführt.

Ist der Slug ein virtueller serieller Port, der evtl. für das CM4 vielleicht ein Problem darstellt?

Repetier

> Klipper wurde wie auf allen anderen Klipper Druckern unserer Farm, die mit Pi Zero 2 laufen, installiert.
Das solltest du nicht machen. Normal läuft der als user pi und nicht als repetierserver user. Auch klappen dann unsere Klipperspezifischen zusätze nicht. Das mindeste ist das du ihn als repetierserver laufen läst und einen eindeutigen socket erzeugst den wir als seriellen port nehmen können /dev/ptsX ist zufällig. Dann geht da smit dem Editor im server aber nicht.

Für die Volle funktionalität must die Klipper über die Server Oberfläche installieren. Er vergibt dann auch direkt den serienn port namen und trägt ihn ein. Danach die Konfigurationsdatei für Klipper in den Klipper editor kopieren und ggf. echten seriellen port anpassen, firmware für klippe rerzeugen und aufspielen und fertig. Wenn du aber vorher includes hattest must du die inlude DAteien vorher auch anlegen. Im Editor einfach mit speichern als eine neue Datei machen und den Inhalt einfügen. Die Hauptkonfiguration ist die, die dem slug entspricht.

dennis_stratanex

Habe mich wohl etwas missverständlich ausgedrückt. Alle Drucker unserer Farm laufen bereits mit Repetier-Server.
Klipper wurde in jedem Fall über die Server-Oberfläche installiert. Auf Pi Zero 2, sowie auf CM4.

Repetier

Ok, und wo hakt es da dann genau? Die verbindung zu klipper sollte in dem Fall ja sofort klappen. Problem ist eher das Klipper den Drucker nicht sieht/falsch konfiguriert ist/drucker firmware nicht 100% identisch ist. In 1.4.2 kann man jetzt auch klipper log sehen oder oben auf das warnsymbol klicken um die Fehlermeldung zu sehen. Evtl. zeigt es bereits wo es bei klipper hakt.

dennis_stratanex

Habe das Problem durch etwas ausprobieren gefunden. Ob ich es lösen konnte weiß ich noch nicht sicher.
Der Drucker wurde ja konstant als verbunden aber nicht ready angezeigt. Also habe ich in den Verbindungseinstellungen etwas rumprobiert und festgestellt, dass er mit den Standardeinstellungen für RTS und DTR nur "oberflächlich" mit der MCU verbinden konnte. Denn also ich RTS auf "Tief zu hoch" gestellt habe, kam der Drucker plötzlich ans leben. Nachdem MCU und SBC jetzt miteinander kommunizieren kann ich auch wieder auf "Tief/Tief" zurück und der Drucker bleibt ready verbunden.

Repetier

Bin grade etwas verwirrt. Insbesondere was bei dir MCU und SBC sein soll. Klipper läuft ja so:
Server<->Klipper<->USB<->Druckerboard MCU
Falst du eine PI MCU zusätzlich hast z.b. wegen input shaping ist hier noch Klipper->PI MCU vorhanden.

Wenn server grün anzeigt also verbunden heist das Server->Klipper steht. Diese verbindung erfolgt über eine unix pipe und da hat rts/dtr keinen einfluß. Auch baudrate ist hier egal. Was wichtig ist, ist das klipper service als user repetierserver läuft.

Wenn dann ein warnsymbol kommt gab es eine Fehlermeldung von Klipper weil ab klipper->drucker etwas nicht geklappt hat. Dann muss man normal konfig anpassen der Meldung entsprechend speichern und klipper restart ausführen, was aber direkt aus unserem Klipper Tab möglich ist. In drucker konsole sieht man die meldungen (evtl parallel in 2. fenster öffnen) und ggf halt noch klipper log ansehen ob da was hilfreiches steht.

dennis_stratanex

SBC (Single Board Computer - RPi), MCU (Micro Controller Unit - STM 32 auf Druckermainboard)

Genau - Die grüne Verbindung Repetier <-> Klipper Host wurde angezeigt (im Übrigen teils mit Warnsymbol, teils ohne, teils mit IO Symbol), die Klipper Konsole hat jedoch immer angezeigt "Printer not ready" (Auch hier mit verschiedenen Ursachen: Mal mit MCU und Host nicht die selbe FW, mal mit mit missing mcu option serial (die im übrigen immer angegeben war)).

Daraus schließe ich wie du oben schon, dass eine grundsätzliche Verbindung zum Klipper Host da war - alle Parameter, die die MCU aber regelmäßig an den Host schickt wurden nicht angezeigt (Temperatur usw.). Hier also ein Problem zwischen dem Klipper MCU und Klipper Host bestand.

Irgendwas muss es jedoch mit den Handshakes von RTS/DTR zu tun haben. Nachdem ich einmal mit den neuen Druckereinstellungen (DTR/RTS geändert) in Repetier die Verbindung Repetier <-> Klipper Host neu hergestellt habe, kam auch die Verbindung Klipper Host <-> Klipper MCU ans leben. Seither bringt auch jeder Neustart von jeder Instanz keine Änderung in die Sache. Alles bleibt stabil so wie es sein soll

Wir werden in der nächsten Zeit sicher noch einige Drucker auf M4P und CM4 mit Klipper und Repetier Server umbauen, dann kann ich unter Umständen neue Logs providen falls etwas wirklich tiefgreifendes immer den gleichen Fehler verursacht