Klipper mit dem RF1000

[af0815]

Die Schaltung ist nicht so schwer zu verstehen. Mit den REF2940 und dem REF2920 hat man exakte Referenzspannungen, damit die Spannungen selbst nicht driften. Der 100nF parallel zum 1µF ist eine typische Blockung von Nieder- und Hochfrequenzen Störungen. Wobei ich davon ausgehe, das der 100nF ein keramischer, Induktionarmer Typ ist.

Messbrücken als solches, arbeiten immer im +/- Bereich. Damit kann man nicht einfach einen A/D Wandler daran anschließen, der muss schon Differentialeingang haben. Der ADS1100 kann das lauf Datenblatt, zusätzlich ist der selbstkalibierend.

Der INA333 mit dem Präzisionswiderstand adjustiert nur den Messbereich und macht gleichzeitig eine Impedanzanpassung für den ADS110 über den 3,3k Widerstand, die LC Glieder vorher blocken die Spitzen.

Nachdem der MF-6324843 auch den ADS1100 beinhaltet, sollte es also nur auf die richtige Vorbeschaltung hinauslaufen, damit das zusammenspielt.

[mhier]

Von meiner Kiste weiß ich nur, dass 1000 Digits 6,48 N entsprechen - zwei parallele Vollbrücken.

IIRC sind die DMS mit 5kg spezifiziert (siehe Aufkleber auf der Stirnfläche), macht 10kg sofern die Last gleichmäßig verteilt ist (mit tut's zwar immer weh, Kräfte in kg anzugeben, aber wurscht ). Das sind also 100N. Bei 6.5N/1000 Digits sind das also ca. 15000 Digits.

Irgend einer sagte mal, dass unsere Lastzellen ab 12000 Digits Schaden nehmen.

Passt also. Etwas Sicherheitsabstand schadet sicher nicht

Die Schaltung ist nicht so schwer zu verstehen.

Stimmt, es ist aber deutlich schwerer sie zu verändern, ohne dass sie unbrauchbar wird. Ich sage ja auch gar nicht, dass das alles unglaublich kompliziert ist. Man sollte aber schon entsprechende Elektronik-Kenntnisse haben. Wer die Schaltung aus dem Schaltplan nicht nachbauen kann, der wird sicher keinen Erfolg haben, wenn er da irgendwelche fertigen Boards/Module zusammenstöpselt.

Der INA333 mit dem Präzisionswiderstand adjustiert nur den Messbereich und macht gleichzeitig eine Impedanzanpassung für den ADS110 über den 3,3k Widerstand, die LC Glieder vorher blocken die Spitzen.

Nicht "nur". Das ist der wichtige Teil der Schaltung. Wenn der nicht passt, mögen vielleicht in Tests sogar halbwegs vernünftige Werte rauskommen. Wenn dann die Stepper nebendran aktiv werden, kann aber beliebiger Unsinn rauskommen.

Uns reichen schon wenige Digits Schwankungen, um unsere Messungen so zu verfälschen, dass sie unbrauchbar werden. Ein Digit ist 4,096V/65536 = 62uV, wenn ich mich gerade nicht ganz täusche. Die meisten bezahlbaren Oszilloskope können das nicht mehr vernünftig messen (1mV/div - da ist das bestenfalls noch ein Pixel). Dies nur zur Einordnung. Das ist alles kein Hexenwerk, aber auch nichts, was man ohne konkrete Kenntnisse zuverlässig hinbekommt.

Nachdem der MF-6324843 auch den ADS1100 beinhaltet, sollte es also nur auf die richtige Vorbeschaltung hinauslaufen, damit das zusammenspielt.

Eben nicht. Das MF-6324843 scheint einen 12V Messbereich zu haben und hat vermutlich eine interne Spannungsregelung. Damit ist die Original-Schaltung nicht mehr realisierbar.

[AtlonXP]

Danke mhier,
das ist eine kompetente Erklärung.

Mein HAMEG Oszi sollte das Messen können.

Zur Not gibt es noch Tastenspitzen mit Verstärker.
Wenn man dann auch mehr Störungen mit misst.

LG AtlonXP

[af0815]

Die Doku zum MF-6324843 hat nicht die Detail hergegeben, nur habe ich nicht bis ins letze dannach gesucht. Die Schaltung von Conrad ist grundsolide, fast eine Referenz.

[mhier]

Naja, wer es schafft, Code zu schreiben, dass der Nano ein ADS simuliert, der kann auch gleich das Python Modul für das HX711 schreiben

Btw: Um das HX711 direkt an das Drucker-Mainboard anzuschließen, braucht man lediglich 2 freie GPIO-Pins. SPI kann problemlos in Software realisiert werden. 2 Pins genügen, da das HX711 nur Daten sendet, also braucht man eine Datenleitung (MISO) und eine Clock-Leitung (SCK). Evtl. braucht man einen dritten Pin, um MOSI zuzuweisen, ohne dass er verbunden wird - ich weiß nicht wie Klipper das genau verlangt.

[Juifen]

Hallo Martín, Dennis,

Klipper unterstützt ja mehrere MCU. Ich hab ein HX711 Modul and einem 3 EUR RP2040. Den könnte man ja über eigenes py Modul ansprechen so wie das ADS1100.py
Nur läuft grad Klipper und RF1000community Klipper bei der RP2040 Unterstützung auseinander.

@mhier welch Sample rate ist denn optimal? Wenn ich die ADS1100 richtig lese kann ich wählen zw. 8, 16, 32, or 128 samples per second.
Der HX711 kann 10. und 80 sps.

Welche Sample Rate sollt man Anpeilen ? Beim bed_mesh (HBS) scan eher unkritisch oder? Wie ist es beim Drucken mit höheren Geschwindigkeiten

Gruß
Juifen

[mhier]

Nur läuft grad Klipper und RF1000community Klipper bei der RP2040 Unterstützung auseinander.

Ja sorry, ich muss mal wieder synchronisieren. Ich will danach aber immer gerne wenigstens grundlegende Tests durchführen, deswegen komme ich da nur selten zu. Ich werde das die Tage aber mal angehen.

Wie gesagt kann man das HX711 grundsätzlich immer auch direkt an der Hauptplatine anschließen, man braucht nur 2 (oder 3?) freie GPIO-Pins - das sollten doch die meisten vernünftigen Hauptplatinen wohl irgendwie anbieten. Am Ende ist es aber tatsächlich komplett egal, ob man das HX711 direkt an der Hauptplatine oder mit einem anderen Microcontroller (RP2040 oder irgend ein Arduino) anschließt. Es macht also Sinn, hier den einfachsten Weg zu wählen, wie auch immer der gerade aussieht

@mhier welch Sample rate ist denn optimal? Wenn ich die ADS1100 richtig lese kann ich wählen zw. 8, 16, 32, or 128 samples per second.
Der HX711 kann 10. und 80 sps.

Beim ADS1100 verliert man mit jedem Faktor 2 in der Sampling Rate ein Bit an Auflösung. Da die maximale Auflösung schon etwas knapp ist,hat man da wenig Spielraum. Ich benutze dennoch eine Rate von 16 Hz und mittele über zwei Samples. Das hat verschiedene Vorteile. Zum einen ist es immer gut, mitteln zu können, denn dann kann man Inkonsistenzen erkennen (wenn z.B. jemand gegen den Drucker stößt) - in dem Fall wird die Messung einfach wiederholt. Zum Anderen ist ein großes Problem die Tatsache, dass die Messungen nicht synchronisiert mit den gefahrenen Z-Schritten sind, weshalb man die erste Messung verwerfen muss. Bei 16 Hz schmeißt man dann nur die hälfte der Zeit weg, das macht also alles insgesamt etwas schneller. Noch höhere Frequenzen bringen beim ADS1100 eher keinen Vorteil mehr (und Mittelungen sind immer ungenauer als direkt eine höhere Auflösung zu haben).

Beim HX711 habe ich es noch nicht ausprobiert. So viel ich weiß gibt es bei 80 Hz keinen Verlust an Auflösung, außerdem ist die ohnehin höher als beim ADS1100. Ich würde es also mit 80 Hz versuchen und trotzdem aber über (mindestens) 2 Werte mitteln. Eine höhere Geschwindigkeit kann bei gleicher Auflösung eigentlich nicht schaden. Am Ende bestimmt dies aber nur die Geschwindigkeit mit der der Scan ausgeführt wird.

Wie ist es beim Drucken mit höheren Geschwindigkeiten

Beim Drucken werden die DMS ja nur benutzt, wenn man ein entsprechendes Feature wie z.B. den sense offset benutzt. Ich denke, das macht dort eher keinen großen Unterschied (sense offset arbeitet ohnehin sehr langsam). Generell würde ich aber auch hier sagen, dass die höhere Auslesegeschwindigkeit nicht schadet. 80 Hz ist nichts, wo ein Prozessor gleich in die Knie geht (naja vielleicht, wenn man auf dem Raspberry Pi 1 läuft, was ohnehin schon nur mit Tricks funktioniert). Es wird umgekehrt aber grundsätzlich eher der Genauigkeit der Berechnungen helfen, wenn diese mit einer höheren Frequenz gefüttert werden.

Viel wird das allerdings dennoch nicht helfen, da am Ende die Latenz-Zeiten das Problem sind: Die Bewegungsbefehle werden in Queues zwischengespeichert, so dass jede Reaktion auf einen Messwert erst eine gewisse Zeit in die Zukunft wirken kann. Diese Latenz-Zeit ist leider recht groß, ich glaube im Bereich von 1/10 Sekunden. Von daher macht 10 Hz oder 80 Hz leider bei Weitem nicht den Geschwindigkeitsvorteil, wie man denken könnte. Wenn es also Probleme macht, mit 80 Hz zu laufen, würde ich nicht lange zögern und auf 10 Hz gehen.

[Juifen]

Danke Martin für die ausführliche Erklärung. Wenn die Latenz eh von den Queues bestimmt wird macht das wirklich keinen grossen Unterschied ob 10 oder 80sps. Meine Überlegung mit dem RP2040 ist einfach, dass ich eine Lösung will die ich später falls das CTC mainboard das zeitliche segnet auch mit jedem anderen 3D Druckerboard weiterverwenden kann. Und ggf. andere Treiber da mich das zwitschern der Schrittmotoren nervt .

Die Boards lösen sich ja auch immer schneller ab. SKR 1.3 oder1.4 gibt kaum noch. Fystec u. Bigtreetech bringen mittlerweile gefühlt im Quartalsrhytmus neue raus. Alles ausser dem Mainboard an dem RF2000 ist ja für die Ewigkeit bzw. standard.

[mhier]

Meine Überlegung mit dem RP2040 ist einfach, dass ich eine Lösung will die ich später falls das CTC mainboard das zeitliche segnet auch mit jedem anderen 3D Druckerboard weiterverwenden kann.

Mach, wie du das für richtig hälst. Ich würde beim Kauf eines neuen Mainboards einfach darauf achten, dass mindestens eine Handvoll GPIO-Pins rausgeführt werden, idealerweise auch ein hardware SPI Bus. Wenn das nicht klappt, kann man immer noch einen zusätzlichen Microcontroller hinzufügen. Das verbaut man sich ja gar nicht. Es ist aber beim CTC-Mainboard gar nicht so einfach, an freie GPIO-Pins heranzukommen, zumindest muss man sich einen relativ untypischen Stecker besorgen. Demnach kann das also gerade dafür sogar die einfachste Lösung sein (ich hab mir so einen Stecker allerdings mal besorgt ).

Die Boards lösen sich ja auch immer schneller ab. SKR 1.3 oder1.4 gibt kaum noch. Fystec u. Bigtreetech bringen mittlerweile gefühlt im Quartalsrhytmus neue raus. Alles ausser dem Mainboard an dem RF2000 ist ja für die Ewigkeit bzw. standard.

Man muss ja nicht jedem Update hinterher rennen...

[mhier]

Wichtiger Hinweis an alle Klipper-Nutzer:

Ich habe soeben einige Updates in unsere Community-Version der Firmware gepusht. Erstens sind wir jetzt wieder auf dem neuesten Stand, was die "upstream" Version angeht. Dies erforderte eine Änderung der Config-Dateien, denn die Achsen werden jetzt anders kalibriert (nicht mehr mm pro Step sondern mm pro Umdrehung).

Außerdem habe ich endlich unser SPI-Problem gelöst: Die CS-Pins des SPI-Busses können jetzt problemlos invertiert werden, indem ein Ausrufungszeichen vorangestellt wird (Standard Klipper-Notation). Das erforderte eine weitere Änderung in den Config-Dateien. Damit sollte sich unsere Community-Klipper-Version jetzt auch problemlos mit jedem anderen Board benutzen lassen. Es wäre super, wenn das mal jemand (Dennis? ) testen kónnte, denn ich kann nur testen, dass der SPI-Bus im invertierten Zustand beim RF1000 noch funktioniert, nicht aber ob ich vielleicht den uninvertierten Original-Zustand verhunzt habe...