Hallo, wenn es auch nicht ganz zur Sache passt,
habe ich eine Frage dazu.

Könnte man einen Thermistor Eingang vom Board,
für die Dehnmessstreifen missbrauchen?

LG AtlonXP

Nicht so direkt, da die DMS in einer laut Schaltplan in einer Brücke gemessen wird. Der Ref2940 (4.096 V) versorgt DMS und die DMS wird nach dem Messverstärker mit dem Ref2920 ( 2.048V) verglichen. Die Verschaltung von der Temperaturmessung ist da nicht gut geeignet, die einen einfachen Spannungsteiler bildet, der nicht speziell stabilisiert (Über Refernzspannungsquelle).

Die Auflösung beträgt im ADS1100 16-Bit wie schon gesagt. Beim Mega ist die Auflösung nomonal 10Bit (Max 12 Bit). Also auch dort ein (gewisser) Verlust.

Noch dazu musst du da entweder an der Platine was umlöten oder eine eigene Schaltung machen. Bei letzten könnte man die Brücke an den Eingang hängen, mit Genauigkeitsverlusten. Grob gesagt die jetzige Anzeige durch 64 (16) dividieren.

Wenn es ginge, hätte sich C. sicher die paar Bauteile gespart

Wenn es dir um die Geschwindigkeit geht: Der ADS1100 kann auch schneller, dann aber mit weniger Bits. Bin mir nicht sicher, ob das irgendwas bringt, es kommt ja schon auf wenige Digits an...

Hallo af0815,
den Schaltplan habe ich in dieser Hinsicht noch nicht studiert.
Wenn nun die Auflösung grober wird, dann können wir keine Abstandsmessungen mehr machen.

Für den SenseOffset und DigitFlowCompensation, sollte es (denke ich) immer noch genügen.
Die Bettvermessung müsste dann irgendein Sensor übernehmen.

LG AtlonXP

Ich habe einmal einen Fork gemacht und die Daten für den RF2000V2 versucht zusammen zu bekommen. Deswegen hatt eich den Schaltplan gerade bei der Hand.

Octoprint mit Klipper läuft auch schon einmal. Jetzt kämpfe ich mit dem in Betrieb nehmen bzw. Flashen. Grundlegend sollte es ja gehen. Aber es geht noch nicht

Flashen geht aber

make flash FLASH_DEVICE=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A906KK9M-if00-port0
Flashing out/klipper.elf.hex to /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A906KK9M-if00-port0 via avrdude

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0x1e9801 (probably m2560)
avrdude: reading input file "out/klipper.elf.hex"
avrdude: writing flash (23674 bytes):

Writing | ################################################## | 100% 5.95s

avrdude: 23674 bytes of flash written
avrdude: verifying flash memory against out/klipper.elf.hex:
avrdude: load data flash data from input file out/klipper.elf.hex:
avrdude: input file out/klipper.elf.hex contains 23674 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 5.11s

avrdude: verifying ...
avrdude: 23674 bytes of flash verified

avrdude: safemode: Fuses OK (E:FD, H:D8, L:FF)

avrdude done. Thank you.

ich bekomme keine Verbindung zur MCU

Send: STATUS
Recv: // Lost communication with MCU 'mcu'
Recv: // Once the underlying issue is corrected, use the
Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
Recv: // config, and restart the host software.
Recv: // Printer is shutdown
Recv: // Klipper state: Not ready
Recv: !! Lost communication with MCU 'mcu'
Recv: ok

Geflashed ist was worden, weil sonst wäre das Display am RF2000V2 nicht leer.

Im Log unter / tmp/Klippy.log sieht alles Ok aus, bis plötzlich die Kommunikation abbricht

Stats 67.7: gcodein=60 mcu: mcu_awake=0.000 mcu_task_avg=0.000000 mcu_task_stdd$
Stats 68.7: gcodein=60 mcu: mcu_awake=0.000 mcu_task_avg=0.000000 mcu_task_stdd$
Stats 69.7: gcodein=60 mcu: mcu_awake=0.000 mcu_task_avg=0.000000 mcu_task_stdd$
Lost communication with MCU 'mcu'
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.

Hast du die richtigen Ports in Klipper (printer.cfg) und in Octoprint (oder was auch immer du benutzt) eingestellt? Man vergisst leicht, dass Octoprint nicht mehr direkt mit dem USB-Port des Druckers reden darf, sonst funkt es der Klipper-Kommunikation dazwischen. Stattdessen muss man dort /tmp/printer als Port einstellen. Wenn du vorher statt Octoprint z.B. Repetier-Server benutzt hast (wie ich), dann musst du den evtl. stoppen und deaktivieren.

AtlonXP hat geschrieben:Hallo af0815,
den Schaltplan habe ich in dieser Hinsicht noch nicht studiert.
Wenn nun die Auflösung grober wird, dann können wir keine Abstandsmessungen mehr machen.

Für den SenseOffset und DigitFlowCompensation, sollte es (denke ich) immer noch genügen.
Die Bettvermessung müsste dann irgendein Sensor übernehmen.

LG AtlonXP

Die Frage ist ja noch immer, was du genau bezwecken willst? Der ADS1100 ist glaube ich schon kein schlechter ADC. Hier ist das Datenblatt:
https://www.ti.com/lit/ds/symlink/ads1100.pdf
Auf Seite 6 unten links ist Tablelle 1, dort steht der Zusammenhang zwischen Samplerate und Auflösung. Zusätzlich lässt sich das Gain verändern, wodurch sich für kleine Signale ein Auflösungsverlust evtl. kompensieren lässt. Wenn wir also z.B. annehmen, dass die Digits in der aktuellen Konfiguration immer nur zwischen +- 8000 liegen, könnte man auf 14 Bit gehen und mit 32 Hz sampeln, dafür das Gain um einen Faktor 4 hochdrehen. Ein Digit würde damit weiterhin (ungefähr) der gleichen Kraft wie bisher entsprechen, nur die maximal messbare Kraft wäre eben geringer.

Das bringt aber nur was, wenn dadurch nicht das Rauschen störend erhöht wird. Und man muss mit der höheren Samplingfrequenz auch noch was anfangen können... Das lässt sich aber ja sogar dynamisch umkonfigurieren, also es wäre denkbar während des HBS andere Einstellungen zu verwenden als während des Druckens, oder sogar in unterschiedlichen Phasen des HBS unterschiedliche Einstellungen.

Ich würde aber erst mal versuchen, in etwa den aktuellen Algorithmus in Klipper umzusetzen. Wenn das funktioniert, kann man schauen, ob sich da noch was verbessern lässt. Grundsätzlich würde ich mal annehmen, dass die Original-Konfiguration von Conrad nicht vollkommen ungünstig ist, d.h. Verbesserungen dürften eher im Detail oder für neue Features unserer Community-Firmware relevant sein.

Meine Feststellung, dass nur mit 8 Hz gesamplet wird bezieht sich eher darauf, dass wir zumindest in der Comminity-Firmware das nicht beachtet haben. Wir mitteln dort über mehrere Messungen, meines Wissens lesen wir aber schneller als mit 8Hz aus, so schnell wie es der I2C-Bus hergibt. Wir mitteln also größtenteils über gleiche Messdaten. Mit dem Wissen kann man evtl. den Algorithmus schon mal verbessern.

@af0815:

ich bekomme keine Verbindung zur MCU

Komisch. Ist dein User in die dialout-Gruppe eingetragen?

Danke mhier,
es war von mir nur eine Idee für euch.

Ob es funzt oder nicht, wird wohl die Zukunft zeigen.

LG AtlonXP

ADS1100 - Die Frage ist, zu welchen Zeitpunkt benötigt man welchen signifikanten Wert. Nachdem es in der Software umzuschalten geht, ist das sicher nicht das Nadelöhr.

Ich hoffe das ich mein Kommunikationsproblem lösen kann. Ich habe hier einen RasPi4 mit Kamera. Die Kamera geht, aber es gibt einige 'Features' in Zusammenhang mit dem RasPi 4.

Mal sehen ob sich da was ergibt. Dann kann ich etwas aktiver einsteigen.