Exakte Filamentüberwachung - Hardware Vorhanden
- af0815
- Donator
- Beiträge: 829
- Registriert: Di 2. Jun 2020, 14:45
- Wohnort: Burgenland
- Has thanked: 35 times
- Been thanked: 123 times
Re: Exakte Filamentüberwachung - Hardware Vorhanden
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).
-
- Prof. Dr. des 3D-Drucks
- Beiträge: 1672
- Registriert: Fr 11. Sep 2015, 11:37
- Has thanked: 279 times
- Been thanked: 247 times
Re: Exakte Filamentüberwachung - Hardware Vorhanden
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.rf1k_mjh11 hat geschrieben:Ob das Filament erkannt wird, kann man jederzeit mit einer Maus testen. Einfach das Filament unter dem 'Auge' der Maus vorbeiziehen.
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
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.zero K hat geschrieben: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.
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...
Gruß, Martin
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)
- Digibike
- Globaler Moderator
- Beiträge: 2419
- Registriert: Sa 6. Sep 2014, 13:19
- Wohnort: Bei Heilbronn
- Has thanked: 280 times
- Been thanked: 455 times
Re: Exakte Filamentüberwachung - Hardware Vorhanden
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
Sieht man z.b. hier
Gruß, Christian
Du suchst Hilfe bei Druck(er) Problemen? Dann lies bei der Anfrage hier "Lösung für Druckeinstellung/Hardwareprobleme gesucht?" durch und beantworte die
Fragen in deiner Anfrage - so wissen wir recht schnell, wo der Schuh drücken könnte!
Fragen in deiner Anfrage - so wissen wir recht schnell, wo der Schuh drücken könnte!
- rf1k_mjh11
- Developer
- Beiträge: 2096
- Registriert: Di 6. Jan 2015, 19:44
- Wohnort: Autriche
- Has thanked: 276 times
- Been thanked: 557 times
Re: Exakte Filamentüberwachung - Hardware Vorhanden
Hallo mhier,
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.
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
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:mhier hat geschrieben: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
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.mhier hat geschrieben:Ne neue 1000dpi Laser-Maus kriegt man für unter 10 EUR...
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.
... könnte man einen einfachen Mikroschalter einsetzen.Digibike hat geschrieben:Wenn es nur darum geht, ob noch Filament da ist/schon eingelegt ist, ...
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
RF1000 (seit 2014) mit:
Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
-
- Prof. Dr. des 3D-Drucks
- Beiträge: 1672
- Registriert: Fr 11. Sep 2015, 11:37
- Has thanked: 279 times
- Been thanked: 247 times
Re: Exakte Filamentüberwachung - Hardware Vorhanden
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).rf1k_mjh11 hat geschrieben:Der Anschluss des Sensors erfolgt nicht über die gewöhnlichen seriellen Pins, sondern über MOSI und MISO (ist das 'ne Suppe?).
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?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.
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).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 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.
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.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.
(Mich hat Samstag ein Nachbar angerufen, ein befreundeter Arzt hatte noch AstraZeneca übrig Sonntag war ich allerdings eher so: )Es lebe die Impfung! Es sterbe der Virus!
Gruß, Martin
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)
- georg-AW
- Developer
- Beiträge: 536
- Registriert: Mi 1. Okt 2014, 14:43
- Wohnort: Schweiz Nordost
- Has thanked: 40 times
- Been thanked: 238 times
Re: Exakte Filamentüberwachung - Hardware Vorhanden
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
"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
-
- Prof. Dr. des 3D-Drucks
- Beiträge: 1672
- Registriert: Fr 11. Sep 2015, 11:37
- Has thanked: 279 times
- Been thanked: 247 times
Re: Exakte Filamentüberwachung - Hardware Vorhanden
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).
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).
Gruß, Martin
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)
- rf1k_mjh11
- Developer
- Beiträge: 2096
- Registriert: Di 6. Jan 2015, 19:44
- Wohnort: Autriche
- Has thanked: 276 times
- Been thanked: 557 times
Re: Exakte Filamentüberwachung - Neue Erkenntnisse
Hallo FilamentüberwachungsTeam,
Jetzt kommt wieder eine Ernüchterung :
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.
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
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.)mhier hat geschrieben: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?
Jetzt kommt wieder eine Ernüchterung :
Ich glaube auch, ich schrieb hier irgendwo, dass sich ein Fehler innerhalb sehr kurzer Zeit entdecken ließe.mjh11 hat geschrieben: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.
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
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
RF1000 (seit 2014) mit:
Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
- rf1k_mjh11
- Developer
- Beiträge: 2096
- Registriert: Di 6. Jan 2015, 19:44
- Wohnort: Autriche
- Has thanked: 276 times
- Been thanked: 557 times
Exakte Filamentüberwachung - Variante 2 (oder 3, 4, 5?)
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:
Nicht sofort 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
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)
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
RF1000 (seit 2014) mit:
Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
Pico Hot End (mit eigenem Bauteil- und Hot End Lüfter)
Ceran Bett
FW RF.01.47 (von Conrad, modif.)
Die Natur kontert immer sofort mit einem besseren Idioten.
-
- Prof. Dr. des 3D-Drucks
- Beiträge: 1672
- Registriert: Fr 11. Sep 2015, 11:37
- Has thanked: 279 times
- Been thanked: 247 times
Re: Exakte Filamentüberwachung - Hardware Vorhanden
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.
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.
Gruß, Martin
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)
Klipper Firmware für den RFx000: Klipper für RFx000 | Original-Dokumentation | Diskussion | Wiki mit Installations-Anleitung
(Ich bin in diesem Forum nicht mehr aktiv)