Klipper mit dem RF1000

[af0815]

Ich sage ja.

Für mich ist die Extrusionskraft ein wesentlicher Faktor um das Drucken zu optimieren. Auch wenn ich es nicht automatisch habe, sondern es manuell mir ansehe. liege ich mit den Werten nieder, so ist die Abstandsänderung zu beherrschen. Natürlich verwende ich auch die DMS für den HBS. Nur für den HBS allein gibt es auch andere Lösungen.

[mhier]

Hmja, meine Aussage war, für die Probe ist das nicht zwingend. Von daher kann ja jeder selbst entscheiden, ob er die Extrusionskraft messen möchte, oder nicht. Ich schaue da inzwischen selten bis gar nicht drauf, weil zu hohe Extrusions-Kräfte für mich ohnehin offensichtlich sind (z.B. durch Abrieb am Ritzel etc.). Für mich würden inzwischen die Vorteile eines kompakten Extruders überwiegen.

Inzwischen habe ich auch einen Pull Request gestellt:
https://github.com/Klipper3d/klipper/pull/4738

Mal sehen, was da für Korrekturanfragen kommen - ich erwarte, das wird ein paar Iterationen brauchen, bis der angenommen wird

Achja: Es wäre gut, wenn RF2000 und RF2000v2 Nutzer sich mal um passende Konfigurations-Dateien kümmern könnten. Ich habe die Datei für den RF1000 angepasst (mit den neuen Macros etc.), aber noch nicht die für den RF2000v2-single. Für den RF2000 (ohne v2, aber single und dual) sowie für den RF2000v2-dual fehlen Konfigurations-Dateien noch komplett. Wäre gut, wenn die jemand in den nächsten Wochen beisteuern könnte. Es wird sicher noch eine Weile dauern, bis die gemerged werden können (da muss ich erst noch unser SPI-Problem für den Stepper-Treiber richtig lösen), aber es wäre schade, wenn die am Ende fehlen würden. Ich möchte da ungerne ungetestete Dateien einsenden, daher kann ich die schlecht machen...

[af0815]

BTW:

Later this week we are planning to move the main github Klipper repository. The plan is to move it from https://github.com/KevinOConnor/klipper.git to https://github.com/Klipper3d/klipper.git

Ich habe einen Hinweis zum SPI Problem von Kevin selbst bereits bekommen. Siehe https://klipper.discourse.group/t/inver ... ters/300/4

Ich werde erst Ende Oktober wieder Zeit finden mich um die Software im Drucker zu kümmern. Aktuell druckt der ohne Probleme mit dem alten Stand.

[mhier]

BTW:

Later this week we are planning to move the main github Klipper repository. The plan is to move it from https://github.com/KevinOConnor/klipper.git to https://github.com/Klipper3d/klipper.git

Ja, das ist schon passiert, habe ich gestern festgestellt. Der alte Link leitet einen einfach auf den neuen weiter. Wer das Upstream-Repo irgendwo direkt benutzt, sollte die URL aber besser anpassen, ich weiß nicht wie lange die Weiterleitung funktioniert.

Ich habe einen Hinweis zum SPI Problem von Kevin selbst bereits bekommen. Siehe https://klipper.discourse.group/t/inver ... ters/300/4

Das ist ehrlich gesagt nichts Neues für mich, genau so wollte ich es ohnehin implementieren

Ich werde erst Ende Oktober wieder Zeit finden mich um die Software im Drucker zu kümmern. Aktuell druckt der ohne Probleme mit dem alten Stand.

Vielleicht gibt es ja noch andere, die Klipper mal ausprobieren wollen. Ich meine eigentlich, man kann damit nicht mehr viel falsch machen.

[mhier]

Achja, ich hab gerade mal das Wiki geupdated, das hatte ich irgendwie ganz vergessen: wiki/index.php/Klipper

[mhier]

Sieht gut aus. MainsailOS kannte ich vorher noch nicht, danke für den Tipp! Magst du deine Anleitung im Wiki als zustätzliche Installations-Möglichkeit reinschreiben? Also ich meine auf dieser Seite hier:

wiki/index.php/Klipper

Die existierende Anleitung setzt ein bereits laufendes Linux auf dem Raspberry Pi vorraus. Da manche damit starten, wäre es gut, die zu behalten und einfach beide Möglichkeiten zu erklären.

Der Fehler in der printer.cfg ist bereits im Repo korrigiert.

Btw: Updaten von Klipper ist sehr einfach:
git pull
sudo service klipper restart

In den meisten Fällen genügt das. Manchmal muss man noch von Hand neu den Microcontroller flashen, einfach mit dem gleichen "make flash" Befehl aus der Original-Anleitung.

[mhier]

Ich denke, das ist auch ein bisschen Geschmacksache. Aber das ist das schöne bei Klipper, sowas lässt sich sehr einfach individuell einstellen. Einfach folgendes in deine printer.cfg schreiben (unter das include der printer-rf1000.cfg):

Code: Alles auswählen

[printer]
max_z_velocity: 25

[stepper_z]
homing_speed: 3.5

Das sollte die maximale Z-Geschwindigkeit sowie die Z-Homing-Geschwindigkeit halbieren.

Ich weiß nicht, wie hier die Original-Werte aus der Repetier-Firmware sind. Ich glaube, ich habe diese Werte (also 50 und 7) damals so pi mal Daumen eingestellt, dass es in etwa passt. Vielleicht sollte man mal die Original-Werte übernehmen, falls die anders sind.

PS: Sorry, übersehen, dass da noch ne Seite kam Ich empfehle, nie die printer-rf1000.cfg direkt zu editieren, sondern immer eigene Änderungen nach dem Include zu überschreiben. Das spart Ärger bei Updates...

[mhier]

Mein Pull-Request auf Github (https://github.com/Klipper3d/klipper/pull/4738) hängt leider schon ziemlich lange, habe ihn am 29.9. reingestellt und seitdem ist nichts passiert außer einem Kommentar, dass es länger dauern könnte... Vielleicht kann mal jemand dort kommentieren, dass er auf das Feature wartet? Nicht unbedingt alle auf einmal, aber ruhig mit gewissem Abstand der eine oder andere. Vielleicht hilft das, die Priorität etwas hoch zu bekommen

Das dürfte der größte Pull Request sein, zumindest von den wichtigen Änderungen für unseren Drucker. Ich hoffe daher, dass der Rest dann später schneller geht. Ich möchte aber auch nicht alles auf einmal einstellen, sondern erstmal ein Gefühl dafür bekommen, welcher Style gefragt ist etc. Das vermeidet unnötige Korrekturen...

[zero K]

"Danke für die Information - es wird dauern, bis da mal ´drauf geguckt wird"
Zur Kenntnis genommen ...
Da wird wohl nix kommen - ich verstehe allerdings auch das System Pull-Request nicht.
Wenn ich mir die Liste der fleißig aktualisierten Druckerkonfigurationen auf der Klipperseite anschaue, sehe ich eigentlich keine Perspektive und auch keinerlei Interesse, (von Klipperseite) ernsthaft an Schnittstellen zu arbeiten, die eine im 3D-Druck eher exotische Sensortechnik ermöglicht.
Ganz davon ab, dass von den vielleicht hundert Tausend RFs noch eine Handvoll leben - vielleicht etwas extrem formuliert.
Gruß, zero K

[mhier]

Da wird wohl nix kommen - ich verstehe allerdings auch das System Pull-Request nicht.

Nein, so würde ich das nicht unbedingt interpretieren. Kevin, der Maintainer von Klipper, war eigentlich immer sehr hilfsbereit, und es gab ja auch einiges an hilfreicher Diskussion im zugehörigen Ticket (https://github.com/Klipper3d/klipper/issues/3496). Aber für ihn ist das eben auch nur ein Hobby-Projekt, und es gibt 91 offene Pull-Requests die er und evtl. ein Helfer (so genau weiß ich nicht, wie das Projekt organisiert ist) abarbeiten müssen.

Mit Pull-Requests kann im Prinzip jeder Code-Änderungen vorschlagen, die der Maintainer des Projekts reviewen kann und ggf. am Ende integrieren (nach möglichen Korrekturen). Eigentlich alle Open-Source-Projekte funktionieren nach dem Prinzip. Dadurch kann im Prinzip jeder etwas zum Projekt beitragen, ein kleines Team wacht aber darüber, dass nichts aus dem Ruder läuft und kein Blödsinn im Projekt landet.

Wenn ich mir die Liste der fleißig aktualisierten Druckerkonfigurationen auf der Klipperseite anschaue, sehe ich eigentlich keine Perspektive und auch keinerlei Interesse, (von Klipperseite) ernsthaft an Schnittstellen zu arbeiten, die eine im 3D-Druck eher exotische Sensortechnik ermöglicht.

Naja, exotisch heißt ja immer, dass es wenige Nutzer gibt. Dementsprechend gibt es auch wenige Entwickler, die sich der Sache annehmen können. Es wird nirgends so etwas geben, dass jemand ein (halbwegs komplexes) Feature bei einem Projekt anfragt, und "die Entwickler" des Projekts implementieren das einfach, ohne dass sie selbst auch nur die passende Hardware dazu hätten. Das kann ja nicht funktionieren. (Zumal "die Entwickler" ja gar keine klar definierte Personengruppe ist, s.o.)

Die Wägezellen sind aber ja gar nicht auf unseren RFx000 beschränkt. Bei Prusa gibt's das ja inzwischen auch. Auch gab es bei Klipper noch eine ähnliche Idee, ein Accelerometer als Probe zu benutzen (https://github.com/Klipper3d/klipper/issues/3741). Die Idee ist noch nicht tot, aber auch noch nicht ausgereift. Es kann also durchaus da einiges passieren, aber es braucht eben grundsätzlich einen aktiven Entwickler, der das implementiert. Den gibt es mit mir, daher ist die größte Hürde eigentlich genommen.

So oder so: Falls diese komplexen Teile nicht integriert werden, ist das dennoch eigentlich kein Beinbruch. Mein nächster Versuch wäre dann, die SPI-Kommunikation (mit dem invertierten chip select Signal) für unseren Stepper-Treiber-Chip ordentlich zu implementieren und das integriert zu bekommen. Das wird sicherlich schneller durchgehen. Evtl. würde ich weitere kleinere Änderungen versuchen integriert zu bekommen, so dass wirklich nur vollständig separate Module (als unabhängige und eigene Dateien) übrig bleiben. In dem Zustand ließe sich das auch langfristig gut warten.

Das gute an Klipper ist nämlich, dass sie sich sehr viele Gedanken über (Software-)Schnittstellen gemacht haben, wodurch Klipper unglaublich erweiterbar ist.