Das Thema wurde schon häufiger Diskutiert, bisher hat es aber nie jemand gewagt. Klipper auf dem RF1000 mit original Mainboard.

Hinweis vorweg: Bisher ist es ein Experiment und ich dokumentiere lediglich die Schritte um das mal auszuprobieren.
Das ist noch keine stabil funktionierende Lösung mit guten Ergebnissen und voll umfänglicher Unterstützung des RF1000.

Wie arbeitet klipper?
Klipper ist eine Kombination aus einem Bewegungsrechner (Raspi o.ä.) und einem Hardware Interface (RF1000 Mainboard).
Alle Bewegungen werden von Klipper (python) optimiert und über eine schlanke serielle Kommunikation an das Mainboard übertragen. Das Mainboard ist dabei nur noch eine art Echtzeitschnittstelle zur Hardware. Alle Intelligenz passiert auf dem Raspi.

Ist klipper mit dem RF1000 kompatibel?
Grundsätzlich ja. Es fehlen ein paar kleine Module um unsere Hardwarerichtig einbinden zu können. Diese müssen in Python umgesetzt werden und die vorgesehenen Ansteuerungsmöglichkeiten des "klipper Hardware Interfaces" nutzen. Keine Angst, es ist fast alles vorgesehen, GPOI, I²C, SPI etc. ist alles da und muss nur richtig konfiguriert werden.

Welche Änderungen an der Firmware sind nötig um den RF1000 betreiben zu können?
Schrittmotortreiber: Die DRV8711 vom RF1000 Mainboard werden über eine SPI ähnliche Schnittstelle konfiguriert. Das muss einmalig beim Start des Druckers passieren, danach wird die Kommunikation nicht zwingen benötigt (nur für Stall Erkennung etc). Die Konfiguration umfasst 8 Register, in denen die Microsteps und max. Strom des jeweiligen Schrittmotors gesetzt werden müssen. Die DRV8711 verwenden dafür ein 16-Bit SPI mit CS active high (normal wäre low). Das ist in klipper (noch) nicht vorgesehen. Da am RF1000 sonst keine weitere SPI Schnittstelle benötigt wird (SD brauchen wir nicht), ist das einfachste im C Code für den ATMega die Polarität des Signals zu ändern (2x 0 und 1 tauschen). Das sollte man im Hinterkopf behalten und als saubere Lösung mal ein eigenes Modul dafür schreiben.
Krafmesszelle: Die Loadcell vom Druckkopf hängt an einem I²C ADC mit fester Adresse.
Hier ist noch todos. Die Einbindung von Probes erfolgt als "endstop", diese sind direkt im Microcontroller auf einen Stepper gemappt (was latzenztechnisch Sinn macht). Zudem ist das i2c lesen "shutdown("i2c_read not supported on avr");".
hier muss also ein "ADC endstop" modul auf dem microcontroller erstellt werden, dass über die Konfiguration angelegt werden kann (so wie eine SPI Verbindung etc. initialisiert wird) und dann als ein virtueller endstop eingebunden wird. Dazu muss ich mich erst noch etwas umschauen.
Es sollte jedoch machbar sein, die Kraftmesszelle zumindest als Sensor zur Matrixscan zu verwenden.

notwendige Modifikationen:
Die Konfigurationsdatei von klipper (printer.cfg) muss durch die für den RF1000 ersetzt werden. Darin sind bereits alle Standardeinstellungen (Pins, Motorstrom, Schrittweiten, Microsteps, Fahrwege vom RF1000 eingearbeitet.
Hinweis zu microsteps: Diese muss man selbst mit skalieren. Wer da spielt bitte die mm/Step korrigieren.

Vor dem SPI transfer setzen wir CS high (statt low), danach wieder low (statt high)
87: 95:: Für die SPI Konfiguration die drv8711.py datei in klippy/extras/ kopieren.

Die Dateien stelle ich demnächst zu Verfügung! Ich optimiere nur vorher noch etwas

Ich will das auch mal probieren!
Benötigte Hardware:
* Raspi, anderer SBC oder alter Laptop mit Linux (Raspian, Ubuntu, Debian)
* Internetzugriff
* USB Kabel zum RF1000

Notwendige Schritte:
* Octoprint installieren (Octopi müsste auch gehen, nicht getestet)
* Klipper installieren (genau nach Anleitung)
* Configuration kopieren und Modifikationen in Klipper Firmware einarbeiten
* AtMega2560 (RF1000 Mainboard) flashen
* Testen

Weitere Hinweise: Ich biete keinen Support für die Klipper Installation etc., bitte selbst googlen.
Auch sonst ist die Funktionsweise von Klipper eher spärlich dokumentiert, das meiste muss man sich selbst aus dem Code erarbeiten.

Meine Meinung zu Klipper:
Die Idee der Voranalyse und Optimierung der Bewegungen ist eine coolse Sache, zeigt sich ja auch in den Ergebnissen und Zeitersparnis. Ob das Verfahren einer Verteilung auf Linux und Microcontroller System dazu wirklich geeignet ist, bleibt offen. in klipper wird sehr viel Aufwand in die Zeiteinhaltung das Ausführung (Scheduling) gesteckt, das serielle Protokoll dazwischen ist solide aufgebaut, lässt aber längst nicht alles auf einfachstem weg zu. Je mehr man sich davon anschaut, desto verkorxter wirkt das alles.
Ein schneller multicore Mikrocontroller würde das auch hinbekommen. Oder man erfindet mal was besseres als G-Code, um hardwarenah Maschinen zu steuern (das serielle Protokoll zum Microcontroller ist ja im Grunde genau das, aber halt nicht einheitlich. Man müsste als die Hardware-Konfiguration mit auf den Microcontroller packen und nur den voroptimierten G-Code abarbeiten lassen.).

Danke zenox,
ich habe die Hoffnung, dass dieses Projekt ähnlich gut wird,
wie unsere bestehende Community FW.

Meine weitere Hoffnung ist, dass noch weiter Leute die sich mit dem Programmieren auskennen,
bei der Entwicklung, hilfreich etwas dazu beitragen können.

Ganz klar, es braucht einfach seine Zeit.

Hier noch ein Link zurück, wo alles begann:
http://www.rf1000.de/viewtopic.php?p=27019#p27019

LG AtlonXP

Hallo zenox,

die Idee finde ich großartig, ich möchte mich auch gerne daran beteiligen.
Ich entwickle gerade ohnehin ein Python-basiertes "Temperaturmanagementsystem" aus 2-Kreis-Wasserkühlung mit Peltier-Rückkühler, Bauraumheizung und Filament-Konditionierung, das hardwareseitig über ein paar Arduinos umgesetzt wird. Auf den ersten Blick scheint mir eine Einbindung in Klipper deutlich weniger aufwändig, als ein komplett autarkes System für das User Interface, wie ich es bisher geplant hatte.

Mich interessiert an dem Klipper-Projekt hauptsächlich die Möglichkeit, ein zusätzliches (schnelles) Board mit 'leiseren' Stepper-Controllern einsetzen zu können, aber wenn durch die Bewegungsoptimierung ein weiterer Lautstärke- und Geschwindigkeitsvorteil entsteht, nehme ich das gerne mit.

Wenn ich dich richtig verstehe, müsste 'nur' für die Einbindung der DMS ein bisschen C/C++ Code für den AVR geschrieben werden, um einen der vorhandenen Leveling-Sensoren zu emulieren?


Läuft Klipper eigentlich nur zusammen mit Octoprint?
Edit: Da install-scripts für centos & ubuntu vorhanden sind, sollte das nicht so sein. Glück gehabt!


Viele Grüße
Timo

Hallo Timo,
wenn Klipper mit unserem Board umgehen kann und es zufriedener weise funktioniert,
dann steht noch einiges an Arbeit an.

In meiner obigen Antwort ist ein Link.
Dort sind einige Funktionen von unserer Community FW genannt,
auf die wir später nicht verzichten sollten.
Du kommst direkt darauf zu.

LG AtlonXP

Hallo AtlonXP,
den Thread kenne ich, darüber bin ich auch auf das Thema aufmerksam geworden.
Die Spezialfunktionen der Community-FW zu implementieren, würde ich als nachfolgenden Schritt sehen, wenn die Grundfunktionen stehen.

Das dürfte allerdings ein ordentliches Brett werden.

Man könnte wohl verschiedene Wege gehen:
- Alle Z-Compensation Features bleiben komplett auf dem RF und Klipper bekommt davon nichts mit
--> Entsprechende Passagen der RF Firmware müssten in die Klipper Mega2560 FW eingebaut werden
---> Kaum zu warten und ziemlicher Aufwand bei jedem Update
---> Nur der (sehr kleine) Kreis der RFx000 Nutzer profitiert, entwickelt - und testet!

- Der RF sendet Daten der DMS und Klipper verarbeitet diese
--> Schwierig, da Klipper wohl schon die Bewegungsdaten für X+n Steps an die Aktorboards gesendet haben dürfte, wenn die DMS Daten für Step X vorliegen. Dadurch müsste das ganze Kommunikationsprotokoll ggf. so angepasst werden, dass asynchrone Korrekturdaten mitgesendet werden können, die auf die unmittelbar folgenden Steps angewandt werden. Anderenfalls hätte man immer eine relativ zickige Latenz zwischen Kraftmessung und Reaktion, die - rein vom Bauchgefühl - sehr feinfühlig gedämpft werden muss, damit das System nicht wild schwingt.

- Z-Compensation Features werden offiziell in Klipper integriert
--> Ein große Nutzerbasis könnte davon profitieren, da geeignete Hardware prinzipiell in die meisten Drucker eingebaut werden könnte. Dementsprechend gäbe es mehr Entwickler und Tester
---> Hat Conrad Schutzrechte auf, die dagegen sprechen? - betrifft nur den offiziellen Teil
---> Sind alle beteiligten Entwickler aus der RF Community (und von Conrad) damit einverstanden? Ich denke, man kann niemandem einen Vorwurf machen, der damit nicht einverstanden wäre
---> Hat die Klipper-Community überhaupt Interesse daran?
---> Die Konstruktionshoheit wird (höchstwahrscheinlich) aus der Hand gegeben
--> Werden die Kraftwerte an den Host kommuniziert? Wenn ja, was wird damit gemacht? (ganz weit voraus gesponnen: theoretisch könnte man eine Kaskade von neuronalen Netzen in die Bahn- und Extrusionsplanung einhängen, die den eigenen Drucker, das Filament und ggf. die Umgebungsbedingungen, etc. mit berücksichtigen. Mit einer ausreichend großen, vergleichbaren Datenbasis wäre das machbar.)

Ich persönlich bin ein Fan der dritten Variante, aber trivial wird das alles nicht.

Hallo Timo,
da hast du mir aber viel Text serviert.
Ich kann natürlich nicht für andere sprechen.
Deinen technischen Schilderungen kann ich folgen, muss aber gestehen, ich bin kein Programmierer.
Wir sind hier erst am Anfang, Kontakt gibt es keinen zu der Klipper Gemeinde.
Der maßgebliche Programmierer für die Community FW, neben ein paar anderen, ist Nibbels.

Wie es sich rechtlich verhält, da kann ich ohne Gewähr nur ein paar Hinweise geben.
So lange alles sich auf die RFX000 Drucker bezieht, dürfte es keine Probleme geben.
Unsere Drucker sollten nach den GNU Bestimmungen verkauft worden sein.
Ich meine die Bestimmungen sind bei Repetier Host einzusehen.
Jedoch hat meines Wissens Conrad ein Patent auf die DMS.
Bei dem Siliconschaum Heiz Bett, muss Conrad auch irgendwie den Daumen drauf haben.
Hier könnte es bei kommerzieller fremder Nutzung, Ärger geben.
Der noch hier manchmal zu treffende Vertreter von Conrad ist der User RF1000 (Programmierer).
Seine letzte Aktivität: Sa. Mär. 30. 2019 1:07 pm.

Timo hat geschrieben: Werden die Kraftwerte an den Host kommuniziert?

Meines Wissens nicht, vielleicht könnte das Nibbels einrichten (Systemzeit)?
Ich schätze, wir brauchen später noch mehr Werte aus der FW.

Leider hat sich Nibbels momentan aus privaten Gründen etwas zurückgezogen.
Es ist noch nicht sicher, aber ich hoffe, dass wir uns zum Stammtisch in Neuenstadt sehen.
Vielleicht schreibt er hierzu etwas.

LG AtlonXP

Guten Abend

Zuerst mal Danke für das Klipper-Engagement.
Dass die Drucker mit Klipper "einmal einwandfrei funktionieren" war für mich der große Wunsch, als mir klar war, wo die Flaschenhälse der RFx000 liegen. Aber ich habe das nie angefangen, weil das in meinem Fall schon etwas irre gewesen wäre damit auch noch anzufangen.
Wir können mit Klipper saubere und sehr hohe Stepraten erreichen und theoretisch beliebige Beschleunigungs-Strategien nutzen - weil die Rechenpower reicht. (Nicht nur Trapezbeschleunigung sondern auch Spline etc.)
(Und eigentlich funktioniert die Community-Firmware zumindest für mich inzwischen absolut zuverlässig. Aber eben nicht in allen Punkten ideal.)

Kopiert also an Mod-Features was ihr könnt und wollt, völlig klar!

Z-Kompensation:
Wenn Klipper bereits eine Kompensationsmethode integriert hat ist das spitze, denn die haben bestimmt vom Anfang an daran gedacht, dass man sowas braucht. Bei der Repetier-Firmware der RFx000 wurde das erst nachträglich in ein vorhandenes Drive-System mit eingebaut.
Rein zum Scannen müsste man die DMS quasi als "Schalter"-Funktion verfügbar machen und vermutlich in die vorhandene Abtastroutine einklinken(?). Funktionen die alles sauber einstellen und das Tasten ersetzen wird man aber brauchen, denn ganz trivial ist das mit den DMS nicht. SenseOffset:
Diese Funktion funktioniert in meinen Augen spitze und die würde ich übernehmen.
Diese Digits-Regelung die zu SenseOffset führt ist garnicht so supergenau und nicht präzise, sondern teilwiese extrem träge.

Digit-Flow-CMP:
Auch genial. Man kann damit extrem viele Drucke retten. Der Drucker druckt einfach langsamer/etwas weniger, wenn das Hotend die Förderung nicht packt oder der Spalt in den das Material gepumpt werden soll zu klein ist. (Simplify macht sowas manchmal im Infill?) .. Oder wenn schlicht die Aufschmelzzeit nicht so ganz reicht.
Auch hier reicht es völlig, wenn die Regelung träge nachläuft. Ich hab mehrere Counter benutzt, die sich langsam auf- und abbauen - immer mit mehrfach gemittelten Messwerten.

Andere Features sind heute meist per Default in den Firmwares. Diese zwei jedoch eher nicht, weil nur die RFx000 und die 3DGence die DMS-Sensoren in dieser Art und Weise verbaut haben.

LG

Hallo zusammen und danke Nibbels.
Ich glaube das meiste ist für den Anfang geschwätzt.

Hier möchte ich nur noch ein paar Kommunikationswege vorstellen.
Es gibt in diesem Forum zwei Ecken zum Schreiben die etwas ruhiger sind.

• - Der Diskrete Bereich.
  Hier kann jeder angemeldete Forum- User lesen und schreiben, die Bots und andere haben keinen Zugriff.
  
  - Die Entwickler Ecke.
  Hier haben nur die Developer Lese- und Schreibrechte.
  Dazu muss bei unserem Admin, der Developer Status beantragt werden.

• - Dann haben wir noch den fast nie benutzten Forum Chat.

• - TeamSpeak

Jünni hatte uns vor längerer Zeit, einen Kanal in TeamSpeak zur Verfügung gestellt.
Es ist ganz praktisch für Konferenzschaltungen.

@Jünni, besteht das Angebot noch und möchtest du dazu etwas schreiben?

• - Zu erwähnen gilt natürlich noch, des Telefon und die Persönliche Nachricht.

LG AtlonXP

Ich grab mal diesen alten Thread hier aus: gab es da jemals zumindest kleine Erfolge? Ich überlege nämlich gerade, ob ich in der Richtung einen Versuch starten sollte. Wenn es schon was gibt, muss ich die Arbeit ja nicht doppelt machen...

Mir ist klar, dass das ganze kein geringer Aufwand wird. Aber all zu riesig sollte das auch nicht werden: Klipper unterstützt die meisten Features schon, die wir haben. Der HBS-Scan heißt dann Mesh Bed Leveling. Unsere Wägezellen werde nicht unterstützt, aber das lässt sich ja ändern. Der Riesenvorteil wäre, dass alles in Python auf dem Host-System implementiert wird. Die beschränkten Möglichkeiten des ATMega und die endlos langen Firmware-Uploads für jeden Versuch machen mich langsam wahnsinnig

Hallo auch,
Ja es gab damals kleine Erfolge.
AtlonXP, Nibbels, usw.waren schon mal im TS.
Leider hab ich jetzt erst gesehen, dass ich wegen dem TeamSpeak noch mal angesprochen wurde.
Natürlich steht das Angebot noch, diesen zu nutzen.

Die TeamSpeak Adresse lautet :
46.20.46.68:10238
ohne Passwort

TeamSpeak kann man sich überall, wie z.B. Chip runterladen.

Hoffe das ihr alle bis jetzt gut durch die Pandemie gekommen seid.
schönen Abend
Jünni