dennis02121978 hat geschrieben:und die Logik im Klipper muß komplett neu geschrieben werden da Sie sich auf i2c bezieht bzw sogar neu da das Originale sonst nicht mehr funktioniert.

Das ist schlicht Bullshit. Das wird der Repetier-Autor so ganz sicher nicht gesagt haben.

dennis02121978 hat geschrieben: Bitte denke auch daran das nur Klipper und Repetier (Original) dann wenn du es mal hinbekommen solltest mit dem RF1000 möglich sind und ich spreche nicht nur die Klasse mit meinen Emulator an sondern jeglicher Drucker TYP und Drucker Firmware.

Das ist ebenfalls Bullshit. Wenn das HX711 mal ordentlich in Klipper integriert ist, funktioniert es a) mit jedem von Klipper unterstützten Board, das noch genügend freie Pins hat und b) auch noch für ganz andere Zwecke als nur die load cell probe. Deinen Emulator hingegen werden viele eher nicht dazwischen fummeln wollen, ja weil er halt ne Krücke ist.

dennis02121978 hat geschrieben: Wie du geschrieben hast er geht mit Klipper, aber auch mit Repetier, Marlin,GRBL etc.....

Dein Emulator funktioniert nur in zusammenhang mit meinem ADS1100 Klipper-Modul, und ggf. noch mit viel Glück noch mit anderen Firmwares, die das ADS1100 ebenfalls unterstützen. Also vielleicht unsere Repetier-Variante, alles andere sicherlich nicht. Es sei denn, jemand strickt für diese Firmwares einen ADS1100-Support *UND* baut eine load cell probe nach. Klar ist das möglich, aber warum baut man sich dann nicht gleich nen vernünftigen HX711 Support? In klassischen Firmwares (also alles was nicht Klipper ist), ist das ja gar kein Mehraufwand.


Deine Herangehensweise ist in etwa so: Entwickler A hat für einen Computer einen Tastatur-Treiber geschrieben. Person B kommt daher und möchte aber einen Maus-Treiber. A sagt, das geht nicht ganz so einfach. Person B bastelt sich einen Adapter und kann anschließend ungefär die Maus-Bewegungen auslesen. Dann sagt er, das ist ja jetzt mist, weil viel zu langsam, kann man den Tastatur-Treiber nicht so ändern, dass der schneller lesen kann. Du merkst vielleicht, was da das Problem ist?

Fun fact: Ich hab gerade erfolgreich ein Klipper-Modul geschrieben, das das HX711 ausliest. Das ist in der Form ebenfalls eine Krücke, denn ich halte mich nicht an die Spezifikationen im Datenblatt. Trotzdem sehe ich Digits, die sich verändern, wenn ich die Düse mit dem Finger nach oben drücke.

Was ich konkret mache ist, einfach periodisch 32 Bit per SPI-Interface zu lesen. Das hat zwei Probleme: zum einen ignoriere ich die data ready Signalisation (was vermutlich ok ist, wenn ich einfach immer lang genug warte), zum anderen sollte ich eigentlich 25 bis 27 clock Signale senden und nicht wie aktuell 32, denn damit wird das Gain eingestellt. Ich vermute, die weiteren Clock Pulse werden ignoriert und das Gain ist damit Fix bei 64. Das dürfte OK sein, denn die hinteren Bits sind schon so nur Rauschen.

Das Modul habe ich schon mal auf Github geladen und kann THEORETISCH schon mit der load_cell_probe benutzt werden - ich habe das aber NOCH NICHT GETESTET! Es wird mindestens deutlich veränderte Einstellungen der Parameter benötigen, weil die Zahlen in einem ganz anderen Bereich sind. Auch bin ich mir noch nicht sicher, ob die Auslese zuverlässig genug funktioniert (oder ob das starke Rauschen nicht vielleicht doch durch den falschen Betrieb verursacht wird). Hier der Code:

https://github.com/RF1000community/klip ... s/hx711.py

Dem Modul muss man aktuell 4 Pins mitgeben, in etwa so: (Ich habe zum Testen das HX711 an einem zweiten Microcontroller angeschlossen, den ich in Klipper konfiguriert habe, dadurch komme ich leichter an die Pins heran. Deshalb das Prefix "loadCellMcu:")

Bevor ich mich daran wage, das mit der load_cell_probe zu testen, werde ich erstmal Vergleiche anstellen der ausgelesenen Werte mit einem einfachen Arduino-Test-Code.

Man kann die Werte mit dem QUERY_ADC Modul/Befehl auslesen und anzeigen. (Auf dem Display sieht man nicht genügend Stellen!)

EDIT: Das Rauschen ist gar nicht so stark. Ich musste die Werte nur durch 256 teilen, weil ja nur 24 der gelesenen 32 Bits Daten beinhalten. Jetzt schwankt der Wert vielleicht um +- 10. Das ist mehr als beim Original-Mainboard, aber dort gibt es nur 16 Bit. Die Auflösung ist also im Prinzip erstmal höher.

dennis02121978 hat geschrieben:Was hast du denn für ein HX711?
Du hast 4 Pins definiert aber das HX711 hat nur 2.

Hab ich X-mal schon gesagt. Die zwei zusätzlichen Pins müssen definiert werden, sind aber nicht verbunden. Es geht nur darum, damit Klipper zufrieden ist.

dennis02121978 hat geschrieben:Schwankung stärker durch 10Hz bei 80Hz weniger.

Hab ich auch X-mal schon gesagt. Das sieht nur so aus, weil dein Auge 10 Hz auflösen kann, nicht aber 80 Hz. Oder hast du mal eine statistische Analyse der Messwerte gemacht, die beweist, dass die Streuung bei 10 Hz höher ist? Wenn dann würde ich das übrigens eher anders herum erwarten, denn wenn weniger Zeit für die Konversion vorhanden ist, ist das Ergebnis meist ungenauer. Vermutlich ist das beim HX711 aber nicht der Fall, weil bei 10 Hz einfach die Messwerte dezimiert werden (vermute ich). Deshalb gehe ich davon aus, dass die Streuung und Verteilung bei 10 Hz und 80 Hz absolut identisch ist, bis mir jemand mit wissenschaftlichen Methoden das Gegenteil beweist, oder die Stelle im Datenblatt unter die Nase hält, die genau das aussagt.

dennis02121978 hat geschrieben:Wie hast du es angeschlossen?

Da gibt's mehr oder weniger nur eine Möglichkeit. Das genaue (aber eigentlich irrelevante) Pinout am Microcontroller kannst du der Konfiguration oben entnehmen. Ich verwende einen Arduino Nano Klon. (Vorsicht, die Arduino Pin-Bezeichnungen sind nicht die, die von Klipper benutzt werden, maßgeblich sind die Pin-Bezeichnungen des ATMega 328P Chips.)

Er hat eine Endstop Auslöser und kann als Switch in jeder Firmware benutzt werden mit jedem DMS.

Du vermischt da jetzt was. Ich sprach von deiner ADS1100-Emulation. Die Implementation mit der statischen Schwelle kann von der Genauigkeit und den Möglichkeiten einer richtigen Implementierung nicht mal annähernd das Wasser reichen und stellt für mich (und viele andere hier) keine ernstzunehmende Alternative dar. Anstatt diese Aussage persönlich zunehmen, könntest du sie einfach mal akzeptieren.

Du musst wohl ne neue Config schreiben damit man im Klipper die Wahl hat zwischen Original oder HX711 und auch den Code den du angefangen hast.

Das würde ich "etwas" anders formulieren. Man kann in der Klipper-Konfiguration problemlos auswählen, ob man ein ADS1100 oder ein HX711 benutzt, und wie die jeweils angeschlossen sind. Es geht aber nur um die 5 Zeilen, die ich oben gepostet habe, und ggf. ein paar Zahlen in der load_cell_probe Konfiguration. Wer seine Hardware modifiziert, muss diese Konfiguration aber logischerweise immer anfassen - und auch irgendwie herausfinden, wie genau das sein muss, denn die meisten Hardware-Modifikationen sind nun mal mehr oder weniger Unikate. Ggf. kann man einen konkreten Umbau im WIki dokumentieren und dort auch dazu schreiben, wie man die Konfiguration konkret anpassen muss. So pauschal kann man das aber nicht in die Konfiguration einbauen, da es zu viele Möglichkeiten im Detail gibt.

Und bitte Lies richtig

Habe ich. Du allerdings nicht. Oder du verstehst es vielmehr nicht. Was völlig ok ist, niemand muss Details über Software-Implementierung etc. verstehen. Problematisch ist nur, dass du das nicht merkst und dann aber glaubst, du könntest den Leuten hier ihren Drucker erklären, den sie seit vielen Jahren benutzen und auch weiterentwickeln.

Kindergarten

Den machst du. Du bist der jenige, der die sachliche Ebene verlässt und persönlich wird, bzw. berechtigte Kritik persönlich nimmt. Ich habe auch langsam keine Lust mehr auf diese elenden Diskussionen, die sich doch immer im Kreis drehen.

Ich habe ein eigenes Forum erstellt wo ich alles weitere bekannt gebe etc.

Schön. Dann ist ja jetzt hoffentlich endlich Ruhe hier.

Also für die die kein Display mehr wollen gibt's dann jetzt wieder ein Display, was nix kann außer die Digits anzeigen. Wow. Und was hat das mit dem Raspberry zu tun?

Und hör mal endlich mit diesen nervigen Doppel-Posts auf. Du musst hier nicht jeden Thread vollspammen.

Verbesserungsvorschlag:
Verlege das OLED in die Nähe des "Hauptdisplays" - denke auch mal an die Opas mit mehrstärken Lesebrille.
Aber ich glaube druckende Opas mit Lesebrille sind bestimmt zahlreicher als der Bedarf an dem immer komplizierter werdenden Umbau.

Na ja,
Gruß zero K

Dennis, du bist schon ein komischer Vogel. Ich habe langsam keine Lust mehr, mit dir zu diskutieren. Du verstehst sehr grundlegende Sachen nicht. Leider bist du sehr gut darin, deinen verqueren Inhalt gut zu verpacken mit schicken Videos und tollen Bildchen, so dass viele deine Aussagen glauben. Es ist ja auch immer ein Kern Wahrheit drin. Leider ziehst du teils gravierende Fehlschlüsse, schmeißt Dinge in einen Topf, die nichts miteinander zu tun haben, und hälst umgekehrt Dinge für verschieden, die exakt das selbe sind.

Hier konkret:

Das was du als "Raspberry Pi" Display bezeichnest, ist vermutlich ein per HDMI angeschlossenes Display (falls nicht, ist deine komplette Aussage ohnehin für die Tonne). Das ist nichts anderes, als was ich mache - nur benutze ich keinen Raspberry Pi sondern einen PC und habe einen ganz normalen Monitor angeschlossen. Das Setup mag dann anders aussehen, ist technisch aber absolut equivalent. (Das sind diese Details, die du irgendwie nie richtig durchblickst, sorry das mal so deutlich zu sagen, aber anders kriegst du das ja anscheinend gar nicht mit. Ist mir jetzt egal, ob du das als Beleidiung auffasst, es ist halt inhaltlich korrekt.) Dieses Display ist grundverschieden von dem von der Firmware direkt angesprochenen Display.

Dein tolles neues Display ist also eben genau das, was ich in meinem letzten Post gesagt habe. Du desigst das direkt angesprochene Display aus, stellst fest, dir fehlt doch ein Feature, und fügst dann also wieder mit völlig anderen Methoden ein neues Display hinzu. Vernünftig durchdachtes Systemdesign geht anders.

Wer Klipper benutzt, braucht das jedenfalls nicht, denn man kann sich ein passendes Display einfach direkt an Klipper dran hängen und das nach belieben ansteuern. Dort kann mans ich problemlos die Digits und andere Dinge anzeigen lassen. Jeder, der Klipper auf den RFx000 benutzt (außer dir) macht das genau so. Dein tolles neues Display ist also lediglich für Nutzer interessant, die die Wägezellen zu einem einfachen Schalter degradieren mit deiner Krücke aller Krücken. Denn nur da kommt man anders an die Digits nicht ran. Die Lösung ist eh für die Tonne, weil viel zu ungenau, das hab ich ja schon x-mal erklärt, aber das interessirt dich ja anscheinend nicht.

So oder so hat das also in diesem Thread nichts verloren. Deshalb möchte ich dich jetzt bitten, damit aufzuhören, hier für deinen Quatsch Werbung zu machen. Dein Gehabe mit "Mehr Details per PM" etc. deutet immer noch darauf hin, dass du die Absicht hast, hier etwas zu verkaufen.

dennis02121978 hat geschrieben:Und den Ausdruck Krücken aller Krücken kannst dir wirklich sparen. Denn es Funktioniert fehlerfrei wo es nix anderes bis Dato gibt.

Zum letzten Mal: Es (das Gesamt-System mit deiner Krücke) funktioniert eben NICHT fehlerfrei. Deine EIGENEN Aussagen lassen das erkennen. Du weißt offenbar nicht mal so ganz genau, was es (= die load cell probe) tun sollte. Ich hab dir das schon X-Mal erklärt, nochmal mach ich das nicht.

dennis02121978 hat geschrieben: Dann nochmals, das mit dem Touch der Nozzle als Trigger wird von vielen Herstellern genutzt und ich glaube mal nicht das du Gott bist und über alles herrscht und denen sagst das die Müll produzieren. Bei denen Funktioniert es genauso gut wie von denen gewollt ist. Beispiele Hersteller sind Ender und Anycubic.

Hab ich nie gesagt. Die machen das aber anders, mit dem Ergebnis, dass unsere load cell probe eigentlich mehr kann - solange man nicht dich ranlässt, der sie dann zur Unkenntlichkeit frisiert.

dennis02121978 hat geschrieben:Du kannst nach der Funktionsweise eines Kantentasters gerne googeln und dich dazu belesen.

Mit dieser Aussage bist du endgültig bei mir unten durch, denn:
viewtopic.php?f=27&t=2869

Der Klipper-Code kann das auch, wie man unschwer erkennen kann, wenn man sich den mal ansieht.

Leider kapierst du hier wieder die feinen Unterschiede nicht. Ich erklär dir das jetzt aber nicht mehr.

Und jetzt hör endlich auf, hier den Thread vollzuspammen. Das gehört alles hier nicht rein.

Langsam glaub ich auch dass es hier nur ums verkaufen geht, so vehement wie der ADS-EMU in allen möglichen passenden und unpassend threads gepushed wird.

Zwischen dem Viper und der Conrad Lösungs gibt es zwei grundlegende Unterschiede

Viper : Aufhängung ist mit Dehnunsmessstreifen in einer Ebene versehen, ein simpler Kraftsensor. Ergo Schwellwertverfahren. Überlastet wird durch Verformung des Bauteils abgefangen. Im Endeffekt ein KlickyProbe bei dem man sich den extra Abtaster spart und Offset zwischen messnehmer und Werkzeug entfällt.

Conrad: Wägezellen ( auch wenn die hier landläufig als DMS bezeichnet werden).
Eine Wägezelle hat einen speziellen konstruktiven Aufbau ( meistens Vierkant mit überlappenden Bohrungen) und ist mit Dehnungsmessstreifen in zwei Ebenen versehen. Geeignet für präzise Messungen.

Wie toll ein Schwellwert funktioniert wenn er nicht genauestens kalibriert wurde kann man in den Viper Foren lesen. Auto-Level issues etc. meistens hat sich der DMS gelöst/verformt weil sich das Bauteil verformt hat.

Das kann bei dem massiven Aufbau des RF nicht passieren, da gibt dann eher das Hotend heartbreak auf. Was damit alles geht sieht man in der CommunityFirmware.

Nein, die Funktion ist eben nicht gleich. Das ist wie Bimetallschalter gegen Themperatursensor. Das eine kann bei einem voreingestellten Wert auslösen. Mit dem Sensor kannst du messen und auch mittels Algorithmen zu einem Wert kommen. Z.b. drift kompensieren oder Sensitivität ändern.

Creality macht das wie Vyper. Die Reverse Engineering Doku https://github.com/CR6Community/Hardware

Die sagen auch ganz klar zum Schwellwert:

A potentiometer that can be used to set a threshold for the strain gauge to trigger. It does not control a sensitivity. The potentiometer is read by the firmware on the STM32 chip

Beide Lösungen haben im Vergleich bei der Wiederholgenauigkeit grotten schlecht abgeschnitten. (The Best Auto Bed Leveling Sensor, YT)

Platz 1 war Prusa Superpinda und 2 orig BL Touch mit unter 1,5% Fehler bezogen auf 0,2mm Layer Höhe. Schwellwert DMS hatte 7% Fehler.

Wenn ich mal viel Lust und Zeit habe mache ich die 25 Test Durchläufe mal mit dem ADS1100.

Sondern nur ob die Aussage mit Nozzle as Probe as Trigger im Anycubic und Ender definiert ist.

Ich verstehe den Satz nicht. As Probe as trigger? Gerne auch gleich auf Englisch.
BTW von Ender war nie die Rede. Vyper und Creality CR-6