ADXL345 am Raspberri Pi Pico

Ich bin seit Input-Shaping auch bei Marlin läuft am Überlegen, mir einen ADXL345 im Drucker fest zu verbauen. Da ich sowieso schon einen Arduino als Zweit-Controller eingebaut habe, der beim GCode mitlauscht um Funktionen zu übernehmen, für die das Mainboard keine freien Pins mehr hat, hätte der Arduino die Möglichkeit, die Beschleunigungs-Resonanzen kontinuierlich festzustellen. Die könnten dann zum Raspberry (mit OctoPi) nebenbei übermittelt werden. Das ergibt dann 2 Möglichkeiten: Wenn die Frequenzen sich nicht wesentlich ändern sollten, stelle ich sie am LCD-Controller ins EEPROM und gut ist. Sollten sie sich aber ändern (sollte nur bei Änderung der Geschwindigkeit bzw Beschleunigung vorkommen, ansonsten bei Y wenn ein großer Druck die Bett-Resonanz ändert), könnte man überlegen, ein kleines OctoPrint-Plugin zu bauen, dass in den GCode-Stream zum Drucker ein M593 einschiebt um das Input-Shaping während des Drucks zu ändern. Der Vorteil läge klar auf der Hand, da die Firmware konstant über die aktuellen Verhältnisse informiert wäre, könnte ohne großen Qualitätsverlust schneller gedruckt werden. Das hat natürlich Grenzen, da bei höherer Geschwindigkeit das Filament auch noch mitreden möchte, aber immerhin. Wäre auf jeden Fall mal ein interessantes Projekt, das an Materialkosten gerade mal um 4€ ausmachen würde, aber eine Menge an Lernerfahrung mitbringt.

Ich habe nicht vor, dem Arduino die Berechnung zu überlassen, der soll nur den ADXL345 steuern bzw dessen Daten entgegennehmen und zum Raspi weiterleiten. Das schafft sogar ein Uno noch nebenbei, ein ESP8266 langweilt sich dann. Der Vorteil wäre, dass der ADXL345 wirklich einfach fest eingebaut werden könnte, und dann, wenn der Raspi mit OctoPi dran hängt, dieser einfach mittels USB verbunden werden kann. Wenn kein Raspi, läuft der Drucker mit allen Zusätzen immer noch Solo weiter, könnte dann nur keine Input-Shaper Frequenzen mehr erhalten und würde dann mit den statischen Werten leben müssen.

Die Berechnung würde ich mit C++ auf dem Raspi als Freistehendes Modul bauen, damit würde ich auch die Geschwindigkeitsprobleme mit Python aus dem Spiel haben. Ein kleines OctoPrint-Plugin könnte dann die aktualisierten Daten übernehmen und in den GCode-Stream einbauen.

Dann muss man noch überprüfen, ob Marlin die Daten nur beim Start ausliest oder bei einem M593 in einem laufenden Druck übernimmt. Sollte aber kein Problem darstellen

Theoretisch könnte man natürlich den ADXL345 auch direkt am Raspi anhängen (solch eine Lösung wäre eventuell für viele mit OctoPi eine sinnvolle Ergänzung, wenn sie Marlin 2.1.2 oder neuer haben). Das ist nicht ganz so einfach wie mit der Arduino-USB-Verbindung, aber wenn der Raspi fest verbaut ist, dann müssen die GPio-Verbindungen auch nur einmal gemacht werden. Das Ding ist, einfach nebenbei (ein 3er Raspi ist flott genug dafür) die Werte zu ermitteln und OnTheFly der Firmware die aktuellen Daten zu übermitteln. Die statische Ermittlung (egal ob mit Sensor oder per Testdruck) ist zwar schon eine nette Ergänzung, aber wenn schon Sensor, dann möchte ich den auch tatsächlich beschäftigen. Ich denke, ich werde mir mal so ein Ding kommen lassen und mal etwas losbasteln. Wird sicherlich eine Weile dauern, aber das ist ja auch der Spaß daran

Nachtrag: Sinnvollerweise würden 2 ADXL345 verbaut werden, einer am Druckkopf und einer am Heizbett. Dadurch würden X und Y-Werte gleichzeitig ermittelt

Nach der Theorie hängt die Resonanzfrequenz von der Masse der bewegten Teile und der Steifigkeit der beteiligten Teile ab (z.B. Elastizität der Zahnriemen). Danach sollte die x-Resonanzfrequenz (gemessen am Druckkopf) immer einigermaßen gleich bleiben, weil sich dort nichts ändert. Die y-Resonanzfrequenz (gemessen am Heizbett) müsste mit fortschreitendem Druck immer weiter absinken, weil bei einem "Bettschubser" das Heizbett wegen dem verdruckten Material immer schwerer wird. So weit die Theorie.

Eine Idee wäre, die x-Resonanzmessung einmal zu machen und danach den x-Input-Shaper zu bestimmen. Um den y-Input-Shaper zu bestimmen, könnte man den Druck nach einer bestimmten Anzahl von Schichten unterbrechen, um eine y-Resonanzmessung durchzuführen. Mit dem Ergebnis wird dann der y-Input-Shaper angepasst. Es kann natürlich sein, dass man die Unterbrechung für die Messung im fertigen Druck sieht, oder dass es bei der Resonanz-Messung den Druck vom Bett schüttelt.

Eine Alternative wäre, anhand der verdruckten Filamentmenge, die kennt man, die neue Resonanzfrequenz zu berechnen bzw. zu schätzen um damit den y-Input-Shaper während des Drucks kontinuierlich anzupassen.

Nur so eine Idee.

Die dynamische Ermittlung der Resonanzfrequenz während des Drucks hat aus meiner Sicht folgendes Problem. Die eigentliche Resonanzfrequenz wird durch den eingeschalteten Input-Shaper mehr oder weniger vollständig unterdrückt. Die kann man während des Drucks idealerweise nicht mehr messen. Was man messen kann, sind Frequenzanteile neben der Resonanzfrequenz, die der Input-Shaper nicht so gut unterdrückt. Es ist die Frage, ob man daraus brauchbare Daten gewinnen kann, um den/die Input-Shaper anzupassen. Käme wahrscheinlich auf einen Versuch an, um das herauszufinden.

Ich bin nicht sicher, ob es wirklich einen großen Unterschied macht, wenn z.B. ein großes Objekt auf dem Bett liegt. Aber das kann man ja zumindest mal untersuchen, sehr teuer wäre die Hardware ja nicht. Allerdings wäre in meinem Fall noch der Fakt, dass ich unterschiedliche Druckbettauflagen verwende. Meistens benutze ich die magnetische flexible Auflage. Die wiegt 133 Gramm. Manchmal benutze ich aber ein Glasbett. Das Ding wiegt 535 Gramm, ist also rund 400 Gramm schwerer. DAS macht mit Sicherheit einen ziemlich großen Unterschied. Nun könnte man die Frequenzen mit beiden Auflagen ermitteln und dann nach Bedarf eingeben, das geht sowohl über M593 als auch direkt über den LCD-Controller. Es ist aber eine Sache mehr, an die man jeweils denken muss. Außerdem finde ich die Untersuchung an sich schon interessant, ist doch schön wenn man solche Dinge herausfinden kann. Abgesehen davon, dass ich durchaus mit unterschiedlichen Geschwindigkeiten und Beschleunigungen drucke. Ich habe mir mehrere verschiedene Druckprofile für verschiedene Zwecke angelegt

find ich ne gute idee! frage mich nur ob der pico dann genug 'vorausschau' auf die anstehenden bahnen und beschleunigung hat um das rechtzeitig und sinnvoll im gesamtkontext zu berechnen?

Bei den allermeisten Druckobjekten werden sich die Bewegungen diverse Male wiederholen. Und wenn bei der ersten Bahn die Frequenz noch danebenliegt, dann wirkt der Input-Shaper vielleicht nicht ganz so gut. Ich habe allerdings den Eindruck, dass er insgesamt den Druck etwas verbessert. Und da ist er ja noch statisch bei mir. Bei den ersten Lagen (oder zumindest beim allerersten Layer) ist ja üblicherweise die Geschwindigkeit stark herabgesetzt, da macht der Shaper gar keinen Unterschied bei mir

ist halt vermutlich eine sache die man einfach ausprobieren muss und ich find wert isses die idee auf jeden fall. was ich dir aus meinen kleinen und kurzen erfahrungen bei klipper schon mal beruhigend sagen kann ist dass die werte nicht so ueberkritisch sind. ich hatte auf bloed einfach mal auf bett und druckkopf so 50g draufgepappt. gab keinen sichtbaren unterschied. und auch wenn ich in der printer.cfg von klipper die mit dem adxl345 ermittelten statischen werte haendisch a bisserl geandert hatte war auch nichts sichtbar. allerdings hatte ich es auch nur bei eher geringen geschwindigkeiten probiert. mehr kann mein ender-3 eh nicht.

Das kommt auf den Ender3 an. Das einfachste Modell hätte wohl Probleme. Ich habe aber den Ender3-Pro mit dem Meanwell-Netzteil und dem 32Bit-Board. Der schafft locker ohne Qualitätsverlust 80mm/s (also rund 50% höhere Geschwindigkeit als Standard) und die Beschleunigung kann dabei fast verdreifacht werden. Ich habe die Parameter für Marlin sorgfältig probiert, wobei die Möglichkeit, ohne neu zu flashen, nur einfach im LCD-Menu die wichtigsten Parameter zu ändern, dabei enorm hilft. Da kann man sich relativ leicht an gut funktionierende Parameter heran arbeiten. Ich drucke die meisten Dinge mit 120mm/s, die Druckqualität ist dabei immer noch gut.

genau. den hab ich auch. aber ich meinte halt schneckentempo im vergleich zu dem was andere so machen/haben. und weil bei meinen wenigen teilen die ich druck mein eiziger wirklich mir wichtiger faktor die oberflaechenguete is druck ich halt immer nur mit 50-80mm und moderater beschleunigung.

So, habe mich mal ein bisschen schlau gemacht. Ich werde demnächst 2 Ansätze probieren. Der erste wäre, den Raspi Pico aus dem Klipper-Projekt ähnlich zu verwenden, dessen Ausgaben aber eben nicht in Klipper zu leiten sondern OctoPrint damit zu belästigen (was effektiv ja auch bei Klipper läuft, wenn auch nicht so sichtbar). Der zweite Ansatz wäre, einen ESP8266 zu verwenden (die ich häufig für Arduino-Projekte benutze und auch immer herumliegen habe). Auch der hat mehrere SPI-Busse, die Rechenleistung ist ähnlich wie beim Raspi-Pico, und genug Flash und RAM hat er auch. Es gibt gute ADXL345 Libraries für Arduino für das Teil, damit sollte man also ähnlich einfach zum Ziel kommen. Pico und ESP8266 sind preislich auf etwa gleichem Niveau, sind etwa gleich groß, brauchen beide 3.3V und sind gut erhältlich. Beide haben (beim ESP in der NodeMCU-Version) USB-Anschlüsse für das Flashen und zur Kommunikation, der ESP hat außerdem noch WLAN (kostet extra beim Pico). Die ADXL345 direkt an den Octoprint-Raspi anzuschließen halte ich nicht für eine so gute Idee, es sind zu viele Anschlussdrähte nötig, man kann zu leicht die Verdrahtung falsch machen, bei den meisten Gehäusen passt dann kein Deckel mehr, und je nach Aufstellung- / Befestigungsort werden die Kabel unnötig lang und bringen Elektronisches Rauschen in die Messung. Deswegen werde ich auf jeden Fall einen Extra-Controller benutzen, entweder den ESP-Arduino oder den Pico.

Eine weitere Möglichkeit wäre den ESP mit Tasmota zu flashen und statt des ADXL345 einen MPU-6050 zu benutzen. Da müsste man aber untersuchen, ob die Geschwindigkeit ausreicht. Vom Datenblatt her ist das Ding eher besser als der ADXL

Eine relativ einfache Methode die ‚Schädlichkeit‘ von Schwingungen zu bewerten ist „Vibration Speed“ in mm/s.

Ich habe dazu noch keine Literatur gefunden, aber ich muss das in ein paar Wochen ohnehin beruflich wissen. So wie ich es bisher verstehe wird einfach jeder gemessene Beschleunigungswert mit seiner Dauer multipliziert. Das verbraucht wenig Rechenleistung, ist frequenzunabhängig und genau genug um Resonanzen zu erkennen.

Sobald ein bestimmter Wert überschritten wird stimmt etwas nicht.

Vibration Measurement: The Complete Guide | Brüel & Kjær

Stimmt, die Wemos D1 sind gut. Ich benutze allerdings selten ein Breadboard. Allerdings für dieses Projekt würde 1 SPI-Anschluss fehlen, es ist nur 1 herausgeführt. Wäre kein Problem wenn man nur 1 ADXL anschließen will um die XY-Messungen getrennt zu machen. Ich möchte aber ausprobieren, ob man die Messungen während des Drucks durchführen und den Input-Shaper dabei aktualisieren kann, auch ob verschiedene Druckgeschwindigkeiten und Beschleunigungen einen großen Einfluss auf die Resonanzen haben. Wenn ja, könnte man mit dem Ansatz einfach verschiedene Druckprofile benutzen ohne den Input-Shaper jedes mal zu ändern

Während des Druckens wird schwer werden, da du ja nie weißt was genau gefordert wurde, da müsstest du den GCode gleichzeitig dazu auswerten. Wenn z.b. ne textur oder kleine Details gedruckt werden und der Input Shaper steuert die Frequenz dagegen, siehst die Textur nicht mehr. Deswegen wird dazu geraten bei Klipper z.b. auch den am wenigsten aggressiven Shaper zu nutzen der gerade noch gute ergebnisse bringt. Soviel wie nötig sowenig wie möglich. Sonst kostet es Details, sieht man z.b. beim Benchy an der Schrift hinten im Heck. Die wird selbst bei der kleinsten Stufe schon fast weg gefiltert.

Wenn das dann im Druck passieren soll, müsste man ein Ist-Soll Vergleich machen und das wird schwierig meines Erachtens. Zumindest übersteigt es definitiv MEINE Möglichkeiten.

Quote from PeterK

Allerdings für dieses Projekt würde 1 SPI-Anschluss fehlen, es ist nur 1 herausgeführt.

Welcher Anschluss fehlt denn? Doppel-S/Chip Select?

Ich kenne mich damit nicht wirklich aus, habe aber mal aufgeschnappt man könne am ESP8266 jeden GPIO-Pin als CS definieren...?