Ich habe aktuell das Problem das ich Klipper am RF2000V2 nicht zum laufen bringe.

Die Software läuft auf RasPi 3B+ oder RasPi4 (4GB) selbst zusammen mit Oktoprint klaglos. Da gibt es kein Problem. Ich verwende das angehängte File als Konfiguration für den RF2000V2. Dabei habe ich die Endung cfg durch txt ersetzt, um es hier herauf laden zu können.

Die Datei lässt sich auch ohne Probleme kompilieren und flashen. Anschliessend bekommt Klipper kurz Verbindung mit dem RF2000, die Verbindung bricht aber nach einigen Versuchen ab. Das sieht man wenn man sich das ganze im Oktoprint mit STATUS ansieht. Geht man tiefer in den RasPi und dieht sich die Logdatei von Klippy an, so sieht man, das die Verbindung kurz stehen zu scheint und dann wieder abbricht.

Bin für alle Ideen offen. Vielleicht sieht wer einen groben Fehler in der Config, weil langsam werde ich Betriebsblind.

Danke

BTW: Zurück zum Communitymod ist auch nur ein kleiner Flash + HBS. Also keine große Sache zu wechseln.

Hallo af0815,
ich habe es geahnt!

Deine Baudrate steht auf 250 000.
Heute fahren wir mit 115 200.

Nachtrag:
Kann seine das es so auch richtig ist.

Normalerweise wird der FAN PWM mit 255 angegeben.
Ich kenne natürlich diesen Dialekt nicht.

Bei dir steht bei: fan_speed: 1.0
Hat das so seine Richtigkeit?

LG AtlonXP

250 000 ist Standard bei Klipper. Es geht aber auch nicht mit 115 200. Das habe ich bereits getestet. Hier ist die Speed zwischen Klipper und dem RF2000 (=mcu) gemeint und nicht zwischen Octoprint und Klipper.

Fanspeed ist aktuell eigentlich egal aktuell, ich habe jetzt gerade keinen angebaut, da ich gerade an einer Aufhängung arbeite aufgrund des Umbaus auf E3D.

Eine Baudrate von 250000 sollte ok sein, funktioniert jedenfalls mit meinem RF1000 und Klipper wunderbar. Die Limitierung auf 115200 bisher lag vielleicht einfach an Problemen mit der Repetier-Firmware...?

Kannst du mal die Log-Dateien posten, jedenfalls Ausschnitte mit den relevanten Teilen?

An dem Log soll es nicht scheitern.

Danke falls du einen Blick hineinwirfst. Ich habe versucht anhand der Pinconfiguration aus der Communitysoftware aus einem RF1000 configfile eines für den RF2000V2 zu machen. Ich bin mir sicher das ich alles richtig gemacht habe, nur der Teufel schläft nicht.

Danke

Unable to open port: [Errno 2] could not open port /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A906KK9M-if00-port0: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A906KK9M-if00-port0'

Heißt auf deutsch, er kann auf den USB-Port nicht zugreifen, weil das angegebene Device nicht existiert.

Entweder ist das Kabel nicht richtig angeschlossen, oder das Device heißt aus irgend einem Grunde anders. Ich weiß nicht, wo du den Device-Namen ursprünglich her hast. Am einfachsten schaust du mal mit der Kommandozeile per "ls /dev/serial/by-id" nach, welche seriellen Geräte dein Linux kennt. Wenn du keine anderen USB-Serial-Adapter angeschlossen hast, wird dort genau ein Gerät vorhanden sein.

genau von serial/by-id. Das ist der exakte Wortlaut. Nur es es ist scheinbar das letzte Log. Ich habe den dumpfen Verdacht, das das Log überschrieben wird, wenn man den RasPi nochmals startet um das Log abzuspeichern. Weil zu dem Zeitpunkt war der Drucker abgedreht. Ok, auch eine Erkenntnis.

Ich habe mir gerade die Wiki von Klipper durchgelesen und werde das ganze nochmals anders angehen. Bessere Testplanung, ich fange mit einem absoluten Minimumconfig an. Nicht das ich mir selbst in der config etwas mache, das einen Reset oder ähnliches auslöst.

Ja, man soll im Homeoffice, nicht schnell mal ...... Sorry das das so durchgerutscht ist.

Kein Problem Das Log landet in /tmp, wenn ich das gerade richtig im Kopf habe, das ist typischerweise ein tmpfs, was komplett im RAM liegt. Ein Reboot löscht das dann natürlich. Dafür wird die SD-Karte nicht mit dem Schreiben des Logs beschäftigt, was für die Performance und Lebensdauer nicht so gut wäre...

Was mir gerade noch einfällt: Octoprint ist per default so eingestellt, dass es bei jedem Fehler, den es von der Firmware mitgeteilt bekommt, ein M112 (emergency stop) schickt und die Verbindung zur Firmware (also Octoprint <-> Klipper meine ich) trennt. Das kann man in den Einstellungen (Schraubenschlüssel oben, dann "Serial Connection" / "Behaviour" / "What to do on a firmware error") konfigurieren. Mich hat das unglaublich genervt, weil man bei jedem Pups erstmal Octoprint neu verbinden, dann "firmware_restart" in der Console eingeben und ein paar Sekunden warten muss. Evtl. grätscht dir das im Moment auch einfach rein und versteckt den eigentlichen Fehler. Die Log-Datei wird dann nämlich auch gerne mit ein paar Seiten Meldungen vollgespammt. Das passiert ohnehin schon gerne mal, also es lohnt sich, weit hoch zu scrollen, bis man was bekanntes findet (halt das, was im Log steht bevor man die Verbindung herstellt), und dann wieder runter bis zum ersten Fehler. Alles nach dem ersten Fehler kannst du in 99.9% der Fälle ignorieren.

Das sollte mehr oder weniger auch das Einzige sein, wieso die Verbindung wegen eines Konfigurationsfehlers getrennt werden kann. Selbst wenn du die Pin-Konfiguration komplett vermasselst, sollte die Firmware sich verbinden und dann einfach nicht das richtige tun.

Allerdings könnte ich natürlich Fehler in den neuen Modulen eingebaut haben, die evtl. die Verbindung stören, wenn sie nicht richtig mit der Hardware (Stepper Treiber bzw. ADC für die DMS) kommunizieren können. Das müsste ich aber schnell an der Log-Datei sehen können Du kannst natürlich auch erstmal diese Module deaktivieren in der Konfig, dann gehen aber natürlich die Stepper nicht (weil sie nicht initialisiert sind).

wird nix in /var/log bzw /var/log/messages oder über dmesg ausgegeben?

Gruß zero K

Nein, die interessanten Meldungen gehen in ein eigenes Log. dmesg ist ohnehin nur für den Linux Kernel da. /var/log/messages bzw. neuerdings /var/log/syslog ist auch eher für das System reserviert, da steht höchstens drin, wenn Klipper neu gestartet wird (denn Klipper ist ein System-Dienst). Den ganzen Output von allen Diensten da reinzudumpen wäre doch arg unübersichtlich... Den Ort der Log-Datei von Klipper kann man sicher irgendwo konfigurieren, per default ist er "/tmp/klippy.log". Außerdem ist es wie gesagt keine blöde Idee, solche recht umfangreichen Log-Dateien nicht auf die recht lahme SD-Karte eines Raspberry Pi zu schreiben...