Klipper mit dem RF1000

[mhier]

also mal zur Info. Ich habe von Anfang an geschrieben das ich damit kein Geld verdienen möchte.

Dann hör endlich auf, Preise zu nennen, und stell die Quell-Dateien öffentlich, so dass man die Sachen a) selbst beim Hersteller der Wahl bestellen kann und b) sie auch modifizieren kann. Solange du das nicht tust, sind das unehrliche Lippenbekenntnisse.

Das mit dem HX711 habe ich auch umgesetzt und von dir kam bei der Planung Sofort so wie ich das angehe ist das Müll.

Müll war die ursprüngliche Umsetzung mit dem statischen Schwellwert. Das habe ich detailliert und mehrfach begründet, du bist auf keine Begründung auch nur Ansatzweise eingegangen. Stattdessen hast du fortwährend behauptet, deine Lösung würde funktionieren - deine Ergebnisse haben aber eine andere Sprache gesprochen. Auch auf diese Argumentation bist du nicht im Geringsten eingegangen.

Deine jetzige Umsetzung ist besser, aber mit der Brechstange durchgezogen. Ich habe genau begründet, warum ich persönlich diesen Weg nicht gehen möchte, sondern eine andere. Eine Zusammenarbeit bei derartig kleinen Projekten wie der "Emulation" ist ohenhin nicht möglich, das sind doch nur ein paar Zeilen Code (sonst hast du was falsch gemacht). Ich möchte eine native Anbindung des HX711 an Klipper, und ich hab das auch genau begründet (Akzeptanz in Klipper Upstream). Deine Wahrnehmung ist einfach sehr selektiv, du gehst auf viele meiner Punkte überhaupt nicht ein und ignorierst sie komplett. Das macht die Kommunikation mit dir ziemlich schwer.

Hinzu kommt, dass man nie so genau weiß, was man dir eigentlich glauben soll. Du hast schon mehrfach höchstwahrscheinlich bewusst widersprüchliche Angaben gemacht. Auch jetzt wieder sagst du, dass du kein Geld verdienen willst, was im eklatanten Widerspruch dazu steht, dass du deine Produkte zum Verkauf anbietest. Auch wenn du damit am Ende nur 2 Euro pro Verkauf verdienst, ist das ja trotzdem nicht kein Geld. Dein Verhalten widerspricht einfach dem Grundgedanken jeder Community. Du hast zwar schon einmal Besserung gelobt, im Grunde stellst du dich jetzt aber eigentlich nur etwas geschickter an.

Ich schreibe das hier auch deswegen öffentlich, weil ich zunehmend das Gefühl habe, meine "latente" Ablehnung auch gegenüber anderen Forums-Mitgliedern rechtfertigen zu müssen. Hoffentlich versteht ihr, warum mir gewisse Vorgänge hier sauer aufstoßen.

[mhier]

Welches Problem möchtest du damit denn lösen?

[mhier]

Das das Leveling nicht so lange dauert.

Und wie soll das gehen?

[mhier]

Achso, du meinst weil die Abtastrate höher ist. Ich hatte schon ein paar Mal erwähnt, dass das nicht unbedingt der Flaschenhals ist. Das bringt also wenig.

[mhier]

Das Frage ich ja dich, ich habe das ja im Klipper nicht implementiert.

Ich hab das recht ausführlich dokumentiert:
https://github.com/RF1000community/klip ... llProbe.md

Ich sehe nur das er ich glaube 7-8 mal pro Punkt abtastet und dann einen Mittelwert daraus Bildet. Jetzt kommt aber noch das 3mal vom HX711 dazu. Das heist wir haben einen Mittelwert aus 8x3=24 daraus Mittelwert. Wenn wir 3mal pro Punkt anfahren dann 9 Mittelwerte und du nimmst aus den 3 dann den Mittelwert.

Du drückst dich sehr unklar aus. Der Algorithmus mittelt standardmäßig über 2 Werte, das ist konfigurierbar:
https://github.com/RF1000community/klip ... cell_probe

Wenn du noch irgendwelche Mittelwertbildungen in deinem Adapter eingebaut hast, dann kannst du das ja dort entsprechend ändern. Es befindet sich also alles unter deiner Kontrolle.

2-4 Micrometer maximale Differenz halte ich für optimal. Das ist komplett vernachlässigbar gegenüber allen anderen Ungenauigkeiten. Mit der Original-Schaltung kommt man (wenn ich das gerade richtig im Kopf habe) auf das gleiche Ergebnis. (Das Original-Original in der Conrad- bzw. Community-Firmware dürfte schlechter sein und verrichtet dennoch seinen Dienst bei der breiten Mehrheit der RF1000 Besitzer, ohne dass sich jemand über mangelnde Wiederhol-Genauigkeit beschweren würde...)

[mhier]

Das hatten wir doch alles schon diskutiert. Warum muss man das immer wieder neu erklären? Da hab ich jetzt keine Lust mehr zu, sorry.

[Juifen]

Dennis,

In der Doku sind doch die 3 Phasen der Messung erklärt. https://github.com/RF1000community/klip ... e-approach


Und auch die Parameter für die fit Phase.

Code: Alles auswählen

# parameters for fit:
#
fit_points: 5
#   Number of measurement points above fit_threshold used for the fit. Defaults
#   to 5, must be bigger than 2.
fit_step_size: 0.005
#   Step size for the fit measurement in mm. Default is 0.005 (5um)
fit_min_quality: 0.85
#   Minimum acceptable fit quality. Higher values are better fit quality.
#   Default is is 0.85.
fit_threshold: 6
#   Minimum (zero-compensated) measured force for a data point to be taken into
#   account for the fit. Default is 6.

Stell doch mal fit_points auf 3 ( kleiner geht nicht sonst funktioniert der Algorithus nicht) und teste einfach ob dir das hilft.
Kann ja durchaus sein, dass die Mittelwertbildung im EMU kontraproduktiv ist in der Community FW und Klipper da die original Schaltung von Conrad immer direkte Werte liefert.

[Juifen]

Ja so 6-10 mal hab ich schon in der fit Phase. Aber ob das durchschnittlich so ist kann ich nicht sagen, da ich grundsätzliche Probleme habe. Der Fehler mit float division by zero.

Zu deinem Mittelwert, wenn die Messung mit 80sps erfolgt während die Düse statisch aufliegt , sprich der Motor steht, sollte die Kraft sich nicht groß Ändern. Also in einer Messreihen alle Werte sehr nah am Mittelwert sein.

[mhier]

Dennis, das mit der Adapter-Krücke war deine Idee, nicht meine. Du hast logischerweise damit alle Nachteile der Original-Schaltung, obwohl dein HX711 mehr könnte. Darüber kannst du dich schlecht beschweren. Die Lösung dafür ist, das HX711 ordentlich zu integrieren. Ich werde sicher nicht deine spezielle Adapter-Schaltung/Firmware in dem Code berücksichtigen, denn damit wäre endgültig klar, dass der Code es niemals in upstream Klipper schaffen würde. Eine ordentliche HX711-Unterstützung hingegen würde diese Chancen deutlich erhöhen. Aber du hast ja anscheinend kein Interesse an Lösungen, die die Community weiter bringen...

Btw: ein ordentlich integriertes HX711 könnte die Scans ganz massiv beschleunigen. Es ist ohnehin klar, dass der Microcontroller-Code angefasst werden muss. Das wurde auch für das ADXL345 (Beschleunigungssensor) gemacht. Da eine HX711 Unterstützung von der Klipper-Community schon mehrfach angefragt wurde, sehe ich hohe Chancen für eine vernünftige Integration. Die ist halt nicht mal eben gemacht, da muss man sich halt mal etwas gedulden. Dafür sollte es dann möglich sein, ohne immer die volle Round-Trip-Zeit der Kommunikation abzuwarten Messungen synchronisiert zur Bewegung durchzuführen. Realistisch wird es sowas aber eher erst in einem halben Jahr oder so geben - es sei denn, es findet sich jemand, der dabei hilft. Bis dahin kann ja deine Lösung dem Übergang dienen.

PS: Das HX711 hat mit 24 Bit Auflösung schon 8 Bit mehr als das RF1000-Original. Damit ist ein einzelner Messpunkt schon so genau wie der Mittelwert aus >=8 Einzelmessungen. Erfahrungsgemäß bringt die Mittelung aber gar nichts für die Genauigkeit, da die originalen 16 Bit schon ausreichen. Lediglich eine Mittelung über 2 Messwerte ist sinnvoll, um (echte) Schwankungen erkennen zu können - in dem Fall wird die Messung verworfen und wiederholt. Die hohe Geschwindigkeit des HX711 bringt dir also fast gar nichts, denn der Flaschenhals ist die Round-Trip-Zeit. Das schreibe ich jetzt aber wirklich zum letzten mal hier.

PPS: Du kennst diese Konfigurations-Option?
https://github.com/RF1000community/klip ... 0.cfg#L158

[mhier]

Das HX711 wirst du nicht direkt mit der MCU verbinden können

Klar werde ich das können. Warum denn nicht? Alles was nicht in 3 Tagen fertig ist, ist gleich unmöglich?

Und diese Aussage (Adapter-Krücke) kannst du bitte dir sparen.

Warum nimmst du derartige Banalitäten eigentlich persönlich? Natürlich ist das eine Krücke, was denn sonst. Auch du wolltest das HX711 lieber direkt anschließen, das war dir aber zu kompliziert, also hast du dich für diese Lösung entschieden. Sie hat Nachteile, also ist es eine Krücke. Natürlich hat diese Lösung - das habe ich nie bestritten - den klaren Vorteil, dass sie bereits jetzt funktioniert. Natürlich eröffnet das jedem, der Bedarf hat, die RFx000-Klasse mit einem fremdem Mainboard und einem HX711 zu betreiben. Das ist gut, und wer in der Position ist, das machen zu wollen/müssen, wird dir sicher dafür dankbar sein. Du wirst aber doch verstehen, dass es andere gibt (und das dürfte die Mehrheit sein), die einen solchen Schritt für viel zu Aufwändig bei viel zu geringem Nutzen finden, ganz einfach weil sie ein funktionierendes Original-Mainboard haben.

Seit 2019 sieht man hier im Forum schon die Überlegung aber nicht Umsetzung etc mit dem HX711. Das was ich in 14 Tagen geschaffen habe funktioniert und auch mit der jetzigen Klipper Version (Community).

Toll. Du wirst voraussichtlich eine ganze Weile mehr oder weniger der einzige Nutzer dieser Lösung bleiben. Die meisten haben eine funktionierende Lösung seit 2016 oder so, nämlich das Original-Mainboard, und daher gar keinen Bedarf an einem HX711. Deshalb passiert da auch nichts. Warum sollte diese Community eine Lösung entwickeln, die quasi niemand braucht? Jetzt scheint es mit dir einen ernsthaft interessierten Nutzer zu geben, also hast du erstmal für dich das entwickelt. Deswegen liegt dir aber hier nicht gleich die ganze Community zu Füßen, weil du sie endlich mit einer Lösung beglückt hättest, auf die alle seit 2019 warten. Wenn das so wäre, gäbe es die schon längst, denn es gibt genügend Leute hier, die ebenfalls in der Lage sind, fertige Hardware- und Software-Module zusammenzustöpseln, damit eine solche Krücke erstmal funktioniert.

Und wenn darin halt die alte Logik ist dann gehts halt nicht schneller und liegt nicht an mir.

Es geht doch hier nicht um Schuldzuweisungen. Es liegt aber schon eindeutig am Design deiner Lösung. Und das Design wurde von dir so gewählt, weil es schnell realisierbar ist. Ist doch alles gut soweit? Man wird aber ja trotzdem mal anmerken dürfen, dass deine Lösung eben wohl nicht die endgültige ist, weil sich eben diese Probleme nicht vernünftig lösen lassen.

Interesse habe ich schon und habe die Lösung gezeigt und offen gelegt die sofort funktioniert und den Leuten den es nicht stört das das Leveling halt bei Klipper Länger dauert als bei anderen Firmwares.

Man merkt, dass du dich mit dem Original-Drucker gar nicht beschäftigt hast. Klar ist eine Probe mit einem einfachen Microschalter schneller, das interessiert hier aber niemanden. Die entscheidende Frage ist doch, ob es länger dauert, als mit der Original-Firmware. Die Antwort darauf ist: Wenn man die Zahl der Scan-Punkte reduziert, bekommt man bei gleicher Genauigkeit ungefähr die gleiche Geschwindigkeit. Weniger Scan-Punkte sind akzeptabel, weil Klipper nicht nur bilinear interpoliert.

Stichwort "offen legen": Das hast du nur *sehr* widerwillig getan und auch jetzt nur partiell so viel ich weiß. Ich denke nicht, dass sich jemand deine Lösung aktuell so nachbauen kann, ohne weitere Informationen von dir zu erfragen (oder gar Teile bei dir zu kaufen, was ja offensichtlich irgendwie immer noch dein Wunschtraum ist) *und* ohne selbst das nötige Handwerkszeug mitzubringen, die Lösung mal eben selbst zu entwickeln.


Eine vernünftige Integration des HX711 ist übrigens schon alleine deswegen sinnvoll, weil sich damit die Chancen erhöhen, dass unsere Load Cell Probe insgesamt in Klipper integriert wird und von anderen mit ganz anderen Drucker-Typen genutzt werden kann. Das ist für mich im Moment die *einzige* Motivation, in Richtung HX711 irgend etwas zu machen.