Exakte Filamentüberwachung - Hardware Vorhanden

[rf1k_mjh11]

Ich mache hier einen eigenen Beitrag bei der es um die Positionierung des Sensors geht.

Bis zu diesem Punkt geht es darum, den optischen Sensor auf die Andrückrolle zu richten. Das kann, zum Beispiel beim RF2000, etwas schwieriger werden.

Es ist selbstverständlich möglich, eine separate 'Andrückrolle' zu konstruieren, die man überall am Filament befestigen kann. Ähnlich wie ein Filamentreiniger. Beispielsweise knapp über der echten Andrückrolle.

So ein System würde erkennen, wenn das Filament ausgeht, die Düse verstopft, starker Schlupf oder Fräsen auftritt. Nicht erkennen würde es den Fall, wo flexibles Filament sich den Weg am Hot End vorbei gefunden hat ('ausbricht').
Wenn also selten flexibles Material verdruckt wird, wäre das sicherlich eine alternative.

WICHTIG ist in so einem Fall, das die Sensoreinheit quasi 'starr' mit der Extrudereinheit verbunden ist, sich also am Filament nicht nach oben oder unten bewegen kann. Sonst wären die ermittelten Werte verfälscht. Als 'schlechtes Beispiel' dient hier wieder der Filamentreiniger. Beim Retract wandert dieser mit dem Filament hoch. Das ist für den Reiniger kein Problem, aber der Sensor würde hier falsche Werte liefern.

Hätte man also so einen 'aufklipsbaren Sensor' samt dazugehörigem Arduino, nach der Methode 'b)' aus dem vorhergehenden Beitrag, wäre das System völlig portabel und könnte an jeden Drucker eingesetzt werden. Bei Bowden-Druckern würde der Sensor im Bowden-Rohr integriert werden, oder vorm Extrudermotor.

Gesundheit allseits,

mjh11

[zero K]

...
Dafür müsste man es allerdings schaffen, dem System beizubringen, welches die normale Maus und welches unser Filament-Sensor ist - oder man kann das System nicht mehr interaktiv benutzen (das wäre für mich ein Problem).

Edit: Hier schon mal die Lösung, wie man Linux beibringt, die zweite Maus nicht für die graphische Oberfläche zu nutzen - solange man noch X und nicht schon Wayland hat (die Frage zielt auch auf Windows, die Antwort ist aber Linux):
https://stackoverflow.com/questions/441 ... -linux-any

Nur eine Idee für den ersten Ansatz, kann man das mit udev-Rules im RaspiOS für Klipper lösen?

Gruß, zero K

[mhier]

Nur eine Idee für den ersten Ansatz, kann man das mit udev-Rules im RaspiOS für Klipper lösen?

Das ist glaube ich der falsche Level, udev-Rules regeln ja, welcher Treiber für welches Gerät mit welchen Parametern benutzt wird, nicht aber welche Anwendung welches Gerät benutzt. Ich denke schon, dass man das in X bzw. Wayland machen muss.

[rf1k_mjh11]

Ich mache wieder ein Stück weiter mit den Hardware-Anforderungen für so ein Filament-Überwachungssystem.

Wichtiger Hinweis:Ich bin nicht vom Fach was Elektronik betrifft. Daher bitte alle meine Angaben mit Vorsicht behandeln!

OK, so wie ich es sehe, müsste der Mikrokontroller drei Serielle Schnittstellen bieten (muss 2x Daten senden und 3x Daten empfangen können). Das wäre so, wenn über USB und ein Host-Programm gedruckt wird (Repetier-Host, Simplify 3D, Pronterface, usw.).

drei Schnittstellen

---

Mit einer Schnittstelle werden Daten (GCodes) vom Host empfangen und es müssen die vom Drucker kommenden Meldungen ('ok', 'Resend', usw.) an den Host gesendet werden (= 1x Senden & Empfangen). Eine Schnittstelle sendet die durchgeschleiften GCodes an den Drucker weiter und empfängt alle Meldungen des Druckers (= 1x Senden & Empfangen). Die dritte Schnittstelle wird (vermutlich) nur empfangen müssen - die Mausbewegungen.

Wird von einer SD-Karte gedruckt, wobei die SD Karte vom Mikrokontroller gesteuert werden muss, könnte eine Schnittstelle eingespart werden. (Diese Lösung wäre für mich keinesfalls interessant.)

Beim Suchen im Netz glaube ich erkannt zu haben, dass ein Arduino Uno oder Nano nicht unbedingt funzen würde, da nur eine serielle Schnittstelle vorhanden ist. (Ob man hierfür eine oder mehrere sogenannte 'Shields' einsetzen kann, ist mir nicht bekannt.) Der Prozessor unterstützt nur eine Serielle, scheinbar.

Der Arduino ATMega2560, dass als Basis für die Systemplatine im RFx000 dient, scheint 4 serielle Schnittstellen zu bieten. Also ausreichend. Es handelt sich aber um ein recht großes Ding (mehr als halb so groß wie ein Handy) und kostet an die €30.

Die Größe eines Teensy LCs liegt etwas unter 40X20X5, und bietet 3 serielle Schnittstellen. Das würde reichen. Der Preis sollte unter €20 liegen.
Ein Teensy 3.0 (oder höher) kommt auf weniger als €25.

Ein Blue Pill STM32 bietet ebenso 3 serielle Schnittstellen, ist eine Spur größer als das Teensy LC und käme auf ca. €10

Ein WeMos D1 Mini ist 'ne Spur größer als 'ne Briefmarke, hat leider 3 Serielle Datenausgänge und nur 2 Eingänge. Dafür beherrscht das kleine Ding WiFi. Falls einer das hinbekommt, drahtlos mit dem Host zu kommunizieren, würde das auch schon reichen. Die kleinen Dinger kosten, mit Glück, weniger als €5.

Wie gesagt - alle Angaben misstrauisch behandeln.

Gesundheit ringsum!

mjh11

[af0815]

Grundlegend ist die Platine des ATMega2560 im RFx000 schon ziemlich ausgebucht. Die Port die serielle Schnittstelle in Hardware machen sind sowieso belegt, jede weitere serielle könnte nur in Software sein und das ist hier ausgeschlossen, da die Datenversorgung der Antriebe verhindert, das ein serielles Protokoll in Software überhaupt mit nötiger Geschwindigkeit funktionieren kann. Ich habe am Ardunio Uno schon mit SOftware serieller Schnittstelle genug experimentiert (Für LIN-Bus). Ja geht, Geschwindigkeit ist unterdurchschnittlich und blockiert andere Prozesse. Als Debugausgabe an ein serielles Terminal ja, für mehr - nein.

Generell ist es so, das der ATMega2560 im RFx000 bereits an die Grenzen geht. Man sieht es wenn man die originale Software und Klipper vergleicht. Unter Klipper werden die Bewegungen besonders an den Umkehrpunkten viel weicher. Das kommt daher, das der ATMega bei Klipper nicht mehr die Bahnkurven zugleich berechnen muss, sondern nur sich um die Ausführung kümmern muss.
Zusätzlich sieht man ja schon beim Kompilieren, das der Speicher fast voll belegt ist (Das ist der Warnhinweis der immer kommt). Daher viel an zusätzlichen Routinen mit Variablen wir immer problematischer.

Jede Lösung sollte daher auf die Mitarbeit des ATMega tunlichst verzichten.

[rf1k_mjh11]

@ af0815,

Jede Lösung sollte daher auf die Mitarbeit des ATMega tunlichst verzichten.

Ja, ich rechnete nicht wirklich mit einer Umsetzung direkt auf der Systemplatine es Druckers.

Ich habe eben eine weitere Seite im Netz gefunden, die vermuten lässt, dass auch für den Maussensor (=die 'Maus') eine bidirektionale Kommunikation notwendig sein wird. Keine große Affäre. Meist, wenn der Empfang serieller Daten unterstützt wird, ist das Senden 'gratis' dabei. Bloß gibt es einige Mikrokontroller, die auf einer Schnittstelle 'nur' ein Senden bieten.

Diverse Befehle werden (müssen?) an die 'Maus' gesendet werden.
Unter Anderem kann man die Datenrate damit festlegen (wie oft der Sensor ausgewertet wird). Standardmäßig geschieht dies 100 Mal in der Sekunde. Gefühlsmäßig erscheint mir diese unnötig hoch. Zulässig sind 10, 20, 40, 60, 80, 100 und 200 Vorgänge pro Sekunde.
Ebenso kann mittels Befehl die Auflösung damit festgelegt werden, sowie eine Skalierung (1:1 oder 2:1). (Nach dem Lesen des Links bin ich mir jetzt nicht mehr sicher, ob die 1200dpi eines Maussensors auch voll auf die erreichbare Bewegungsauflösung durchschlagen )

Möge COVID-19 alle verschonen,

mjh11

[mhier]

Ich denke, das wird ein Feature sein, was sich am besten in Klipper umsetzen lässt. Dann brauchen wir auch keinen zusätzlichen Microcontroller, sondern können die Maus per USB nativ am Host-Computer (Raspberry Pi oder was auch immer) anschließen.

Will man unbedingt einen zusätzlichen Microcontroller verwenden, würde ich die Maus per vUSB einbinden:
https://www.obdev.at/products/vusb/index.html

Ich denke, ein einfacher ATMega dürfte ausreichend sein, um als ausschließliche Aufgabe die Maus per USB auszulesen und das Ergebnis per seriellem Interface z.B. an Klipper weiterzureichen.

Eine Idee ist mir noch gekommen, die ich mal demnächst testen wollte: Kann man mit dem Maussensor evtl. direkt das Filament abtasten, also ganz ohne Rolle? Dann müsste man sich im Grunde nur ein passendes Gehäuse für die Maus drucken, bei dem das Filament vor dem Sensor entlanggeführt wird, ganz ohne weitere Mechanik. Nachteil könnte sein, dass der Sensor evtl. bei bestimmten Filamentarten/-farben versagt. Aber das kann man ja vorher mal ausprobieren. Ich habe noch eine alte optische Maus gefunden, die ich nicht mehr brauche

[af0815]

Eine Idee ist mir noch gekommen, die ich mal demnächst testen wollte: Kann man mit dem Maussensor evtl. direkt das Filament abtasten, also ganz ohne Rolle? Dann müsste man sich im Grunde nur ein passendes Gehäuse für die Maus drucken, bei dem das Filament vor dem Sensor entlanggeführt wird, ganz ohne weitere Mechanik. Nachteil könnte sein, dass der Sensor evtl. bei bestimmten Filamentarten/-farben versagt. Aber das kann man ja vorher mal ausprobieren. Ich habe noch eine alte optische Maus gefunden, die ich nicht mehr brauche

Erfahrung von mir, bei optischen Messverfahren an runden Drähten: Man sieht ca. nur 1/3 der Oberfläche aufgrund der optischen Streuung von runden Teilen. Das haben wir bei Cognex-Inspektionssystemen für Drähte erfahren müssen. Ist schlimmer je besser der Draht reflektiert.

[rf1k_mjh11]

Hallo mhier, af0815,

Eine Idee ist mir noch gekommen, die ich mal demnächst testen wollte: Kann man mit dem Maussensor evtl. direkt das Filament abtasten, also ganz ohne Rolle? Dann müsste man sich im Grunde nur ein passendes Gehäuse für die Maus drucken, bei dem das Filament vor dem Sensor entlanggeführt wird, ganz ohne weitere Mechanik. Nachteil könnte sein, dass der Sensor evtl. bei bestimmten Filamentarten/-farben versagt. Aber das kann man ja vorher mal ausprobieren. Ich habe noch eine alte optische Maus gefunden, die ich nicht mehr brauche

Siehe den vierten Beitrag in dem Thread hier. Ob das Filament erkannt wird, kann man jederzeit mit einer Maus testen. Einfach das Filament unter dem 'Auge' der Maus vorbeiziehen.

Gesundheit allerseits!

mjh11

[zero K]

Abtasten der Andruckrolle ist sicher ein guter Weg.
Es sollte aber durch einen Anschlag gewährleistet sein, dass die Andruckrolle bei Filamentende nicht vom Antriebsritzel bewegt wird.
Bei den Bondtechs mit angetriebenem Andruckritzel dürfte es also nicht funktionieren.
Da schon von Schwierigkeiten zur Abtastung an unterschiedlichen Filamenten geschrieben wurde, nur mal die Lage des Filaments im Fokus des optischen Maussensors in den Raum geworfen - die sollte einiger Maßen (vielleicht genau) stimmen.

Schaut auch mal dort, Duet3d schreibt auch sehr schöne Dokumentationen ...
https://duet3d.dozuki.com/Wiki/Duet3dFi ... serVersion

Gruß, zero K