Exakte Filamentüberwachung - Hardware Vorhanden

[af0815]

Duet3D hat mit dem Lasersensor eine gute Lösung. Einfach und Nachvollziehbar aufgebaut. Sicher besser als mit Mausteilen zu jonglieren. Ca. 45 Pfund für das Teil + Versand + Steuer. Na ja. Werde mal ohne Lösung leben (so wie bisher).

[mhier]

Ob das Filament erkannt wird, kann man jederzeit mit einer Maus testen. Einfach das Filament unter dem 'Auge' der Maus vorbeiziehen.

Hab ich gerade mal mit meiner alten Maus ausprobiert (klassische Logitech, genauen Typ kann ich nicht mehr lesen). Zumindest bei 1.75mm rotem ABS Filament funktioniert es nicht zuverlässig. Der Mauscursor bewegt sich zwar ab und zu mal, aber nur sehr ruckartig und bleibt dann auch wieder stehen. Ich schätze, die Fläche ist zu klein.

Evtl. sind da Laser-Mäuse im Vorteil, weil die sich eine kleinere Fläche anschauen. Mit meiner Laser-Gaming-Maus (Razer Lachesis) geht es jedenfalls problemlos - die Maus gebe ich allerdings nicht dafür her

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.

Das kann man auch leicht ausprobieren: Einfach die Maus knapp über dem Tisch hin und her bewegen. Meine Maus reagiert noch recht zuverlässig bis ca. 1mm über der Tischplatte (geschätzt). Wenn ich 3mm Sperrholz unterlege, so dass der Sensor frei bleibt, tut sich definitiv nichts mehr. Man muss den Abstand also schon recht genau treffen, das ist sicher ein guter Hinweis. Allerdings errinnere ich mich, dass ich mal eine Maus hatte, die noch in 1-2cm Abstand reagiert hatte, wenn auch nur noch ungenau. Das kann also stark variieren.

Klar kann man auch einen fertigen Sensor kaufen. Da muss man aber weiterhin schauen, wie man den in die Firmware einbindet. Wenn das Protokoll da nicht anständig dokumentiert ist, kann das schnell aufwändiger sein, als eine Maus zu verhackstücken Ne neue 1000dpi Laser-Maus kriegt man für unter 10 EUR...

[Digibike]

Wenn es nur darum geht, ob noch Filament da ist/schon eingelegt ist, warum schaut ihr euch nicht mal den Prusa an...? Da ist es ganz simpel gelöst: Wird abgetastet - Gibt ja genug Varianten. Da braucht es nichts besonderes. Aber die Abtastung greift nicht am Filament, sondern einer Metallkugel, die den Filamentkanal versperrt. Wenn Filament durch will/soll, muß dieses die Kugel nach oben verdrängen - damit gerät Sie in den Abtastbereich. Vorteil: Es jukt 0, was für Material geladen wird. Funktioniert immer. Keine großen Ansprüche an die Überwachung/ kann optimal aufeinander abgestimmt werden...
Sieht man z.b. hier

Gruß, Christian

[rf1k_mjh11]

Hallo mhier,

Evtl. sind da Laser-Mäuse im Vorteil, weil die sich eine kleinere Fläche anschauen. Mit meiner Laser-Gaming-Maus (Razer Lachesis) geht es jedenfalls problemlos - die Maus gebe ich allerdings nicht dafür her

Ich habe mir vor 3-4 Tagen so was bestellt. Ist den Sensor einer Laser-Maus. Dauert jetzt noch 6 Wochen und kostet natürlich mehr als die bloßen €10, die du zitierts:

Ne neue 1000dpi Laser-Maus kriegt man für unter 10 EUR...

Dafür muss ich nichts unnötiges mehr entfernen (keine Schalter, ScrollRad, usw.). Damit ergeben sich für mich weniger Fehlerquellen. Auf der Seite des Verkäufers ist auch schön der Anschluss an ein Arduino Uno dargestellt. Der Anschluss des Sensors erfolgt nicht über die gewöhnlichen seriellen Pins, sondern über MOSI und MISO (ist das 'ne Suppe?). Damit bleibt zumindest ein 'TX' und 'RX' frei (im Bild die digitalen Pins '0' und '1'). Wenn diese Pins für die eingebaute USB-Buchse nicht verwendet werden, könnte man glatt einen Uno für die Filamentüberwachung einsetzen. Hier ein Link zu einer Arduino Anwendung mit dem obigen Sensor.

Das interessante an den Chips für die Laser-Maus-Sensoren ist, dass der Laser gleich am Chip mit dabei ist (z.B. ADNS-9800 oder PWM3360).

Ich schätze, dass man ohne der Linse nicht auskommen wird. Ohne der Linse dürfte das 'Blickfeld' quasi nie 'scharf gestellt' werden. Außerdem leitet die Linse den Laser (das LED-Licht) genau zur benötigten Stelle. Aber mit Glück könnte es (zumindest bei der LED-Variante) vielleicht ohne Linse klappen, wenn der Abstand passt (bloß wird uns keiner den richtigen Abstand OHNE LINSE verraten - und der ist vielleicht verdammt knapp am Chip selbst). Auch könnte es sein, dass ohne Linse die Toleranz für den Abstand noch enger werden könnte.

Im Vergleich zur LED-Variante wird der Laser weniger Probleme mit rotem Filament haben, da die LED-betriebenen Sensoren oft mit einem rotem LED arbeiten (auch die Infraroten LEDS dürften sich mit roten Oberflächen schwer tun). Laser tun sich angeblich auch mit stark glänzenden Flächen leichter (z.B. Glas - oder ein Kugellageraußenring!)

Ich dachte, beim ersten Mal als ich mich damit beschäftigte, dass Laser-Mäuse nicht funzen würden, weil sie zu neu wären und daher kein PS/2 Protokoll unterstützen würden. Das war offensichtlich falsch. Mein Fehler liegt darin begründet, dass ich von solchen Sachen absolut keinen Tau habe. Der Link mit der Arduino-Lösung beweist, dass es geht, unabhängig, ob PS/2 oder nicht. Es geht scheinbar seriell, ohne PS/2 Protokoll, auch.

Wenn es nur darum geht, ob noch Filament da ist/schon eingelegt ist, ...

... könnte man einen einfachen Mikroschalter einsetzen.

Wir hier träumen aber davon den Filamentverbrauch so exakt zu verfolgen, dass zusätzlich zu dem noch übermäßiger Schlupf, beginnendes Fräsen und Düsenverstopfer erkannt und behandelt werden können.

Es lebe die Impfung! Es sterbe der Virus!

mjh11

[mhier]

Der Anschluss des Sensors erfolgt nicht über die gewöhnlichen seriellen Pins, sondern über MOSI und MISO (ist das 'ne Suppe?).

Das ist SPI, ebenfalls ein serielles Protokoll, das dem asynchronen UART (TX/RX) deutlich überlegen ist, da es die Daten synchron überträgt (daher gibt es noch einen 3. Pin SCK - dort einfach nur SC genannt - für das Takt-Signal).

Aber mit Glück könnte es (zumindest bei der LED-Variante) vielleicht ohne Linse klappen, wenn der Abstand passt (bloß wird uns keiner den richtigen Abstand OHNE LINSE verraten - und der ist vielleicht verdammt knapp am Chip selbst). Auch könnte es sein, dass ohne Linse die Toleranz für den Abstand noch enger werden könnte.

Wenn da wirklich keine Linse im Spiel ist, gibt es keine optische Abbildung. Das wird nicht funktionieren, auch nicht mit extrem kleinen Abständen. Auf dem einen Bild ist aber doch eine Linse zu erkennen?

Im Vergleich zur LED-Variante wird der Laser weniger Probleme mit rotem Filament haben, da die LED-betriebenen Sensoren oft mit einem rotem LED arbeiten (auch die Infraroten LEDS dürften sich mit roten Oberflächen schwer tun). Laser tun sich angeblich auch mit stark glänzenden Flächen leichter (z.B. Glas - oder ein Kugellageraußenring!)

Rot mit rot geht doch gut. Problematisch wäre eher die Komplementärfarbe (Cyan), weil dann quasi kein Licht reflektiert wird. Das hängt aber stark von der Empfindlichkeit des Sensors ab, da zum einen die LED und zum anderen das Filament nicht nur eine einzige Wellenlänge haben bzw. reflektieren. Das ist mit dem Laser schon anders (hat nur eine Wellenlänge), allerdings ist der deutlich heller (da kleinere Fläche), und die meisten farbigen Materialien reflektieren im IR trotzdem ziemlich gut (Farbstoff filtert immer Farben heraus, das Material ist ja eigentlich weiß - für IR gibt es keinen Grund, das rauszufiltern, denn es geht ja nur um's Aussehen).

Ich würde aber ohnehin die Laser-Version empfehlen, da wie gesagt zumindest bei meiner LED-Maus der Sichtbereich zu groß ist. Bei Laser-Sensoren dürfte der deutlich kleiner sein, denn ein Laser ist ja sehr viel gerichteter als eine LED.

Ich dachte, beim ersten Mal als ich mich damit beschäftigte, dass Laser-Mäuse nicht funzen würden, weil sie zu neu wären und daher kein PS/2 Protokoll unterstützen würden. Das war offensichtlich falsch.

PS/2 ist halt viel einfacher als USB und wird deshalb von Bastel-Arduino-Projekten lieber benutzt, um eine Maus anzusprechen, als USB. Mit einem SPI-Interface und anscheinend mitgelieferten Arduino-Libraries ist dein Sensor aber natürlich noch leichter von Arduino aus anzusprechen.

Es lebe die Impfung! Es sterbe der Virus!

(Mich hat Samstag ein Nachbar angerufen, ein befreundeter Arzt hatte noch AstraZeneca übrig Sonntag war ich allerdings eher so: )

[georg-AW]

Hi
"Ich würde aber ohnehin die Laser-Version empfehlen, da wie gesagt zumindest bei meiner LED-Maus der Sichtbereich zu groß ist. Bei Laser-Sensoren dürfte der deutlich kleiner sein, denn ein Laser ist ja sehr viel gerichteter als eine LED."

Das ist er nur wenn die Kollimatorlinse davor sitzt, andernfalls hat man eine rechteckige, asymmetrische Fläche in mm Grösse.
Die Halbleiterlaser haben in einer Richtung mehrere Maxima was zu einem strichförmigen Bild führt.
Ich denke, dass die optischen Probleme bei der Anwendung recht gross sein werden. Beim Filamentsdurchmesser von 1.75 mm und den diversen Farben.
Evl. muss eine Schlitzblende montiert werden. ZB. 0.5mm in der Breite und 5mm in Längsrichtung. Dies alles wenn man das Filament direkt abtastet.
Wenn allerdings die Anpressrolle abgetastet werden soll, kann man sich evl. den Aufwand sparen. Leicht aufrauhen könnte reichen.

ciao Georg

[mhier]

Jo und jetzt vergleich das mal mit einer LED, die quasi in 360 Grad Raumwinkel Licht emittiert....

So oder so ist die Beleuchtung ohnehin nur ein Teil des Aspekt. Wichtiger wäre zu wissen, wie groß die Fläche ist, die sich der Sensor anschaut. Diese wird aber definitiv nicht größer sein, als die beleuchtete Fläche. Wenn ich mir dann noch ansehe, wie groß das "Sichtfenster" in einer LED Maus, und wie klein in einer Lasermaus ist, bin ich mir sehr sicher, dass die Fläche bei einer Lasermaus wesentlich kleiner ist. Das ist ja auch der Grund, warum Lasermäuse besser funktionieren (also in ihrer vorgesehenen Nutzung): je kleiner die beobachtete Fläche, desto kleinere Strukturen können gesehen werden - da findet sich dann viel leichter etwas, selbst bei eigentlich glatten und gleichmäßigen Oberflächen.

Ich will natürlich nicht ausschließen, dass es LED Mäuse gibt, die geeignet wären, und Lasermäuse, die es nicht sind. Die Wahrscheinlichkeit wird aber eher gering sein, und warum soll man LED Technik überhaupt in Erwägung ziehen, wenn Laser Technik schon so günstig zu haben ist?

Wen ich im Moment nicht zu viele andere Baustellen hätte, würde ich mir ne billige Lasermaus kaufen und das genauer ausprobieren. Ich vermute, besonders schwer kann das nicht sein, die irgendwie in Klipper einzubinden, zumindest als passive Überwachung (also bei Fehler warnen und Druck pausieren, kein closed-loop).

[rf1k_mjh11]

Hallo FilamentüberwachungsTeam,

Wenn da wirklich keine Linse im Spiel ist, gibt es keine optische Abbildung. Das wird nicht funktionieren, auch nicht mit extrem kleinen Abständen. Auf dem einen Bild ist aber doch eine Linse zu erkennen?

Wenn du damit eines der Bilder vom Sensor, das ich bestellt habe meinst, dann Ja, da ist natürlich eine Linse mit dabei. (Ich persönlich glaube auch nicht daran, dass es ohne Linse geht - außer, man setzt das Prinzip einer Lochkamera ein.)

Jetzt kommt wieder eine Ernüchterung :

Wir hier träumen aber davon den Filamentverbrauch so exakt zu verfolgen, dass zusätzlich zu dem noch übermäßiger Schlupf, beginnendes Fräsen und Düsenverstopfer erkannt und behandelt werden können.

Ich glaube auch, ich schrieb hier irgendwo, dass sich ein Fehler innerhalb sehr kurzer Zeit entdecken ließe.

Dem ist nicht so! Leider.

Die Log-Datei, mit der ich meine 'ExtrusionSense' Untersuchungen durchführte, hat auch hier gute Dienste geleistet. Ich prüfte, wie viel Zeit zwischen dem Einlangen eines GCode-Befehls und der dazugehörigen 'ok'-Meldung verging. Hier entdeckte ich gelegentlich Zeiten über 4 Sekunden.
Meine Vermutung war, dass die Druckgeschwindigkeit, bzw. die Dauer eines einzelnen Segments, hier einen Einfluss hatte. Im 'ExtrusionSense' Thread sieht man den Druckauftrag, der der Log-Datei zugrunde liegt. Die Teile sind nicht sonderlich groß oder gerade.
Daher setzte ich ein Extrembeispiel ein, um eine neue Log-Datei zu generieren. Das Druckobjekt war ein Quader, 225mm lang und 3mm breit und hoch. Damit entsteht pro lange Seite eine über 220mm lange Raupe, die in einem Stück, ohne Unterbrechung, gedruckt wird. Eine weitere Erschwerung der Situation wurde mit der Angabe von NinjaFlex, als Material, erreicht, da dieses Material relativ langsam gedruckt werden muss.
Damit ergeben sich (Verfahr-)Zeiten, pro lange Seite, von über 8 Sekunden.
Gedruckt wurde nicht wirklich, es wurde der 'Dry Run' Modus eingesetzt. Die Log-Datei wurde trotzdem erstellt und von mir ausgewertet.
Es ergaben sich Zeiten bis an die 9 Sekunden, die zwischen dem Befehl und der bestätigten Ausführung liegen.

Schlussfolgerung: Eine zeitnahe Reaktion auf ein Problem im Filamenttransport wird ohne echte Einbindung in die Drucker-Firmware nicht möglich sein. Das Durchschleifen der GCode-Befehle, die Auswertung der Extrusionswerte und die Überwachung mittels einem externen System (Arduino, Raspberry, usw.) wird nicht zeitnah möglich sein. Zumindest nicht exakt, egal wie exakt der eingesetzte Sensor ist.
Baut man, software-mäßig, einen Zeit-Puffer ein, wird zwar eine Überwachung möglich sein - aber eben mit einer gewissen Zeitverzögerung. Die Zeitverzögerung muss aber vorher als Konstante festgelegt werden und muss größer als die längste, mögliche Zeitverzögerung sein (also ca. 10 Sekunden). Damit vergehen dann beim Auftreten eines Fehlers immer 10 Sekunden bevor die Software reagiert.

was ist mit einem Trick

---

OK, man könnte schlauerweise sagen, ich gucke zusätzlich noch auf die 'ok'-Zeile (die ja die Zeilennummer enthält), vergleiche dann erst den 'E'-Wert mit dem Sensor. Das ginge fix mit einem Puffer (sagen wir 32 Befehlszeilen - reicht sicher). Das Problem sind aber wieder die 'langen Geraden'. Die 'ok'-Meldung kommt, sowie der GCode-Befehl zur Ausführung gelangt. Aber die Ausführung dauert 8-9 Sekunden. Im Laufe der 8-9 Sekunden wird kontinuierlich, gleichmäßig, extrudiert. Der 2te Mikrocontroller, hingegen, sieht sofort, am Anfang (wenn der Befehl zur Ausführung gelangt) einen 'E'-Wert, der erst, nachdem die 8-9 Sekunden vergangen sind, erreicht wird. Ich weiß nicht, ob das mittels Software so einfach zu lösen wäre.

Ok - grübeln ... grübeln ...

Na gut, gucken wir halt immer auf die 'ok'-Meldung des nachfolgenden Befehls - da müsste doch der vorhergehende Befehl ja abgeschlossen sein, oder? [Nachweis erforderlich]

Jedenfalls wird es schon etwas komplexer als ursprünglich gedacht ....

Andererseits, wird so ein System direkt in die Firmware mit eingebaut, wäre eine exakte Überwachung vermutlich leichter realisierbar.

Eine Klipper-Lösung scheint mir ebenso fraglich, denn, der Drucker gibt auch nur die 'ok'-Meldung zurück, ohne dass Klipper über den tatsächlichen Verfahr-/Extrusionsvorgang genau Bescheid weiß (oder täusche ich mich hier?).

Aber noch nicht die Flinte ins Korn werfen - siehe nächsten Beitrag.

Hoch die Masken! Es leben die Vakzine! Nieder mit COVID-19!

mjh11

[rf1k_mjh11]

Also - noch ist der Ofen nicht ganz aus. Es gibt noch die Möglichkeit einer zeitnahen Reaktion auf (zumindest einige) Probleme des Filamenttransports.

Das Problem, im vorhergehenden Beitrag beschrieben, ist, dass mehr als 8 Sekunden vergehen können, bevor der Drucker die Abarbeitung eines GCode-Befehls bestätigt. Das erlaubt kein sofortiges Reagieren auf Fehler im Filamenttransport. In der Software müsste ein genügend großer Zeitpuffer vorgesehen werden um solche Verzögerungen 'schlucken' zu können. Dieser Zeitpuffer verhindert ein sofortiges Reagieren.

Geht es aber nicht irgendwie trotzdem schneller?

Ja.

Damit werden aber nicht alle Probleme zwangsläufig sofort erkannt. Dazu komme ich später. Zuerst aber der Trick:

Einen zweiten Sensor am Ritzel/Rändelrad anbringen.

Damit könnten Filamentende, beginnendes Fräsen (z.B. durch eine verstopfte Düse) und übermäßiger Schlupf beinahe sofort erkannt werden. Sobald die zwei Sensoren einen deutlichen Unterschied erkennen, ist eines der eben genannten Fehler aufgetreten. Reaktionszeit sicherlich unter einer Sekunde. Eigentlich müsste die Umfangsgeschwindigkeit der Andrückrolle und des Ritzels/Rändelrads beinahe identisch sein.

Nicht sofort erkannt werden:

• lockere Madenschraube am Ritzel/Rändelrad - da sich das Rändelrad nicht dreht, bleiben die Werte vom Rändelrad und der Andrückrolle gleich.
• Gebrochene Motorachse - dieselbe Erklärung wie eben
• Toter Motor (sei es Kabelfehler, Treiber, oder sonstwie elektronisch bedingt)

Diese Fehler könnten jedoch alle trotzdem mit der im vorhergehenden Beitrag erwähnten Zeitverzögerung erkannt werden.
Verzichtet man auf diese drei letztgenannten Fehlermöglichkeiten, kann man völlig auf das Durchschleifen der GCode-Befehle durch den zweiten Mikrocontroller verzichten. Möchte man diese Fehlermöglichkeiten unbedingt mit einbinden, wird die Hardwareauswahl weiter eingeschränkt. Denn der Mikrocontroller wird einen zusätzlichen seriellen Port (für den zweiten Sensor) benötigen. Und damit dürfte der Arduino Uno endgültig als möglicher Mikrocontroller ausfallen.

Wir gedenken 2021 - Das Jahr der Impfung!

mjh11

[mhier]

Das liegt daran, dass die Firmware einen Befehls-Puffer drin hat (haben muss). Es handelt sich also nicht um eine konstante Zeitverzögerung, sondern (wahrscheinlich) um eine feste Anzahl an Befehlen, die der Drucker "hinterher hinkt". Wenn du diese Zahl herausfindest, kannst du theoretisch genau berechnen, wo sich das Filament gerade befindet. Allerdings müsstest du dazu im Grunde einen Großteil der Firmware nachbauen, um genau berechnen zu können, wann das Filament wie weit bewegt wird. Es sind ja auch Beschleunigungen im Spiel, und die jeweils anderen Achsen spielen eine wichtige Rolle (die Bewegungen sind ja synchron!).

Deutlich einfacher wäre es, das Stepper-Signal für den Extruder noch auf einen zweiten Pin zu geben (inkl. Richtung, also zwei Pins, aber es sind genügend frei). Dann kannst du einfach mitzählen. Das ist eine minimale Firmware-Änderung, die schnell gemacht sein sollte.

Evtl. ist das sogar auch die Lösung, die man für Klipper am besten benutzen würde, denn auch dort gibt es im Mikrokontroller eine Befehls-Queue, allerdings sind die Befehle dort keine G-Codes sondern sehr viel kleinteiliger. Die Verzögerung dürfte dort sehr viel kleiner ausfallen, deshalb hoffe ich eigentlich, dass es dort ohne derartige Klimmzüge geht.