ExtrusionSense - Neuer Feature-Request für Community & Klipper - Filamentüberwachung!!!

Beitrag von **rf1k_mjh11** » Mi 19. Mai 2021, 15:25

Liebes Forum,

Ich schlage ein neues Feature vor, womit eine gewisse Filamentüberwachung OHNE zusätzliche Hardware möglich sein sollte.
Das Feature könnte man in die Community Firmware und natürlich auch in Klipper unterbringen. Ob Conrad, oder genauer, unser Forums-User RF1000 dieses Feature in die offizielle Firmware einpflegt, bezweifele ich, leider.

Diesem Feature möchte ich den Namen ExtrusionSense verpassen, da damit erkannt werden soll, ob (ordnungsgemäß) extrudiert wird.

Wird unheimlich lang...

Vier Zustände lassen sich mit dem Feature erkennen:

ordnungsgemäßer Druckvorgang
das Ende des Filaments
eine Düsenverstopfung
Filament, dass nicht mehr transportiert wird und wo das Ritzel nur mehr ‚fräst‘, obwohl die Düse nicht verstopft sein muss (also als Folge von zu hohem Extrusionsdruck (eine Düsenverstopfung wird unter Nr.2 behandelt))

Ich bringe nur die Idee - für die Umsetzung bin ich beinahe völlig ungeeignet, da meine Programmierfähigkeiten sehr eingeschränkt sind.

Hintergrund:
Wenn man während eines Druckauftrags die Digit-Anzeige beobachtet, sieht man meist ein auf und ab der Werte. Bei jedem Retract oder Layerwechsel geht der Wert stark zurück, um kurz darauf wieder anzusteigen sobald wieder extrudiert wird. Dieses Verhalten könnte man ausnutzen. Ich glaube man wird drei verschiedene Verläufe der F-Digits während eines Druckauftrags erkennen können:

ein dauernd mehr oder weniger schwankender F-Digit-Wert (entspricht ein normales Verhalten - Vasenmodus eventuell ausgeklammert!!)
ein plötzlicher Abfall der F-Digits (ohne vorhergehendem Retract!) - das deutet darauf, dass das Filament alle ist. Das entspricht Fall 2 in der obigen Liste.
ein sich kaum ändernder, recht hoher F-Digit-Wert, ohne deutliche Schwankungen - das deutet auf eine Düsenverstopfung (was natürlich sofort das 'Fräsen' verursacht). Entspricht Fall 3 in der obigen Liste.
ein mäßig rasch abfallender Wert, der nie mehr ansteigt - hier ist die Düse nicht verstopft aber das Ritzel hat sich so weit ins Filament gefräst. dass nichts mehr gefördert wird. Das dürfte Fall 4 in der obigen Liste entsprechen.
Bei manchen ist es anders
Bei mir, zum Beispiel, ist Fall 4, aus der ersten Liste, mit dem gleichen Digit-Verhalten erkennbar wie eine Düsenverstopfung, obwohl die Düse nicht verstopft ist. Beim Fräsen wird entweder das Material verformt, oder es bildet sich ein Grat der verhindert, dass das Filament in das Führungsrohr des Hot Ends passt (bei mir geht das Führungsrohr bis auf ca. 1.2mm an das Ritzel heran). Damit klemmt das Filament und übt weiterhin eine Kraft auf die DMS, währenddessen sich die Schmelzkammer, weiter unten, langsam 'leer-sabbert'.

Funktionieren kann das nur mit der DMS.

Sehr verlässlich sollte es beim Layerwechsel klappen (oder generell beim Retract). Andererseits beim Vasenmodus VIELLEICHT NICHT, da hier kein Retract stattfindet! (Ob es nicht trotzdem möglich ist, muss noch geprüft werden.) Gibt es da auch ausreichende Schwankungen der F-Digit-Werte ohne Retracts, wird die Filamentüberwachung auch im Vasenmodus funktionieren.

Offen ist auch, wie rasch die Firmware einen Fehler erkennen kann (Tests dazu werde ich in den nächsten Tagen/Wochen durchführen).

Wie schnell erkennbar

Haben wir dann Ausschuss

Wieso bei mir stockender Transport

Die Idee basiert auf meiner Vorstellung des Verlaufs der F-Digits während des Drucks. Ich stelle mir das so vor:

ExtrusionSense_1.jpg

Mit 'unterem Limit', im Bild, stelle ich mir einen Wert vor, der beim Drucken (wo Filament gefördert wird) garantiert nicht vorkommt. Dieser Wert wird (hoffentlich) über dem Leerlaufwert der DMS liegen.
Die Firmware muss einfach bei einem Retract ein oder 2 Sekunden lang auf die Digits achten. Sinken diese nicht, ist was faul (Düsenverstopfung und/oder Fräsen). Umgekehrt sollten beim Fördern die Digit-Werte meist weit über dem 'unteren Limit' liegen. Tun sie dies nicht, ist ebenfalls was faul (Filament aus oder Fräsen).
Dabei hoffe ich, dass sich ein ausreichender Sicherheitsabstand ergibt, zwischen den üblichen, ordnungsgemäßen Digit-Werten, und dem 'unteren Limit'. Stimmt das alles, könnte die Firmware, ohne zusätzliche Hardware, eine ordentliche Filamentüberwachung abgeben!

Weiter geht es im nächsten Beitrag - mit tatsächlichen Digit-Werten!

was hier früher stand...

Als ich diesen Beitrag vor 10-12 Tagen erstmals verfasste, stand noch:
Ich bin kein Programmierer, bekomme die Idee daher nicht in die Firmware hineingestrickt. Als Ansatz für einen Algorithmus ergeben sich für mich zwei Ansätze:

beim Abarbeiten eines Retract Befehls (erkennbar daran, dass der E-Wert geringer als der vorherige E-Wert ist) wird zuerst der aktuelle Digit-Wert gespeichert und einige Zehntelsekunden nach der Abarbeitung des Retracts der neue Digit-Wert ausgelesen und mit dem gespeicherten Wert verglichen. Falls kein Filament-Transport-Fehler vorliegt, sollte der neue Wert deutlich geringer sein
generell regelmäßig die Digit-Werte speichern und mit dem nächsten Digit-Wert vergleichen. Es sollte sich ein Auf und Ab des Werts feststellen lassen (also Schwankungen von 10%, oder mehr, des durchschnittlichen Werts ergeben. Nachteil: Die Firmware würde im Vasenmodus vermutlich kaum Schwankungen feststellen und einen Fehler annehmen. Abhilfe: Falls diese Funktion mittels speziellem GCode-Befehl aufgerufen werden kann, kann man die Funktion im Start-GCode deaktivieren, falls im Vasenmodus gedruckt werden soll (das ließe sich in Slic3r und PrusaSlicer mittels der systeminternen Variable ‚spiral_vase‘ automatisieren).

Vermutlich benötigt Variante 2 deutlich mehr Rechenleistung als die erste Variante, aber das sollte einer der Programmierer beurteilen.

Und noch wichtiger:

Toll wäre es, wenn einer der Programmierer eine der FW-Varianten so modden könnte, dass der Digit-Wert im (Repetier-)Log ausgegeben werden würde (analog der ViscositySense Funktion). Schließlich gibt die Log auch die Temperatur und das ‚ok‘ samt der jeweiligen Zeilennummer brav aus. Dann könnte ich Fragen klären, wie z.B. ‚Wie groß ist die Zeitverzögerung bei einem Retract, bevor der Druck tatsächlich sinkt?‘ oder ‚Gibt es ausreichende Digit-Schwankungen im Vasenmodus um einen Fehler zu erkennen?‘ Dazu muss ja nicht jeder Digit-Wert ausgegeben werden. Optimal wäre natürlich einmal pro abgearbeitetem Befehl, reichen würde vermutlich einmal pro 5 Befehle (schließlich muss man die vielen kurzen Kurvenabschnitte bedenken, die existieren, wenn die STL mit hoher Auflösung erstellt wurde). Die jetzige Firmware überwacht ja die DMS-Werte, um bei Bedarf den Not-Stopp auszulösen. Ebenso sendet die Firmware pro abgearbeiteter GCode-Zeile ein ‚ok‘ an die Log(-Datei), samt Zeilennummer. Man müsste also nur eine Leerstelle samt Digit-Wert dranhängen. Dann stünde im Log statt (beispielsweise):
ok 33741
dann:
ok 33741 2586
Womit erkenntlich wäre, dass zum Zeitpunkt der Abarbeitung des Befehls in Zeile 33737 ein Digit-Wert von 2586 ermittelt wurde. (Im Log, einige Zeilen darüber, findet man sogar den zugehörigen GCode-Befehl selbst: „N33741 G1 X62.218 Y67.530 E2.80412*101“, im Format ‚N‘, Zeilennummer+Leerstelle, GCode-Befehl, einen ‚*‘ und am Schluss eine Prüfnummer, in diesem Fall ‚101‘.)

Möge COVID-19 uns alle verschonen!,

mjh11

Beitrag von **rf1k_mjh11** » Mi 19. Mai 2021, 16:18

Teil 2 des vorhergehenden Beitrags.

In den letzten Tagen bin ich über einige Hinweise im Forum gestolpert, wonach Nibbels in nächster Zeit sich kaum der Firmware-Programmierung zuwenden wird können. Dadurch fühlte ich mich leider auf mich allein gestellt, was die Umsetzung meines Vorschlags im vorherigen Beitrag betraf.

Was ich brauchte

Da ich nicht sonderlich begabt bin, was die meisten modernen Programmiersprachen angeht, dauerte es allein schon einige Stunden, bis ich die Stelle fand, wo sich die Textbausteine der Log-Ausgabe befanden. Dazu noch etliche Stunden, über mehrere Tage verteilt, bis ich die Firmware so ändern konnte, dass auch der Digit-Wert ausgegeben wurde (nicht ganz fehlerfrei, aber brauchbar – siehe dazu spoiler ‚Nummernfehler‘ später im Beitrag). Dazu musste die Firmware etliche Male kompiliert und beanstandete Fehler bearbeitet werden. Falls fehlerfrei, wurde ein pseudo-Druckauftrag gestartet (ohne Filament) und die entstandene Log-Datei betrachtet. Das Ganze so lange wiederholt, bis auch der Digit-Wert wie gewünscht, erschien. Dabei rauchte mein Kopf derartig stark, dass in der gesamten Gegend die Feinstaubwerte mehrere Tage durch die Decke gingen (vermutlich entstand dadurch auch eine weitere Klimaerwärmung um einige Zehntel Grad, leider).

Da der Digit-Wert nun endlich greifbar wurde, ging es ans Datensammeln.

Nach dem Erfolg wurde die Repetier-Log-Datei ‚geleert‘. Ein repräsentativer Druckauftrag wurde gestartet: ein nützlicher Spulenadapter. Wie hier:

PrintJob_#1.jpg

Repräsentativ deshalb, da zwei ‚Hauptinseln‘ existieren, durch die zwei getrennten Objekte. Pro Objekt gibt es zusätzlich mehrere Gelegenheiten für einen Retract, da Unterbrechungen vorhanden sind.

Gedruckt wurde mit schwarzem Polymaker PETG, 1.75mm. Die Düse war 0.6mm, die Layer-Höhe 0.45mm.
Der Auftrag dauerte ca. 85 Minuten. Bald am Anfang sah ich, dass die Digit-Werte recht hoch waren. Und so erhöhte ich die Temperatur schrittweise insgesamt um 14 Grad. (Vermutete Ursache: Da ich die Firmware neu aufspielte, dürften die PID-Werte nicht mehr gestimmt haben und die Temperatur-Regelung erreichte die gewünschte Temperatur nie ganz.)

Die entstandene Log-Datei hatte eine Größe von 14.5 MB. Die Log-Datei wurde mit einem Editor bearbeitet, um jene Zeilen zu entfernen, die für die Untersuchung nicht von Belang waren (z.B. Temperatur-Meldungen). Das Ergebnis davon kam in eine Tabellenkalkulation zur weiteren Bearbeitung und Analyse. Durch die weitere Bearbeitung wuchs die Datei auf knapp 35MB (das Arbeiten wurde dadurch recht langsam und mühselig)

. Dabei wurde ein Nummernfehler in der Zeilennummerierung gefunden

Nummernfehler

Nachdem der Nummernfehler beseitigt wurde, wurde eine grafische Darstellung der Digit-Werte erstellt. Ich war erstaunt darüber, wie gut diese meiner Vorstellung entsprach.

Weitere Analysen stellten fest, dass es zu einer Verzögerung von ca. 0.5 Sekunden zwischen der Bestätigung des Retract-GCodes und des ersten feststellbaren Druckabfalls gibt. Übrigens, die durchschnittliche Verzögerung zwischen dem Einlangen eines GCode-Befehls und der rechnerischen Abarbeitung liegt bei unter 0.3 Sekunden. In der selben Zeit kommen 4 bis 5 weitere GCode-Befehle in die Bearbeitungsschleife. Ob der GCode mit dem Liefern der ‚OK-Meldung‘ auch mechanisch abgearbeitet wurde, ist mir nicht bekannt.

Jetzt geht es zu den tatsächlichen Kurven der Digit-Werte während eines Druckauftrags. Um alles etwas verständlicher zu machen, habe ich mehrere Ausführungen. (Ein Bild der gesamten 80 Minuten ist praktisch unbrauchbar, da so viele Punkte auf begrenztem Raum dargestellt werden (über 168000). Als erstes kommt eine Darstellung über 8 Minuten Dauer. Es beginnt kurz nachdem der erste Füllvorgangs (100%) beginnt:

8MinutesOfDigits(annotated).jpg

Die vertikale Achse zeigt den F-Digit-Wert, wie dieser an den Log gemeldet wird. Die horizontale Achse zeigt die Zeilennummer aus dem Log.

Auch die 8 Minuten Graphik sagt nicht sonderlich viel aus.

Eine schöne Übereinstimmung mit meiner ursprünglichen Vorstellung ergibt hingegen die Grafik über 30 Sekunden:

30SecondsOfDigits.jpg

Die Analyse des GCodes erlaubt die Klassifizierung der einzelnen Abschnitte der Kurve:

30SecondsOfDigits(annotated).jpg

Um es bildlich noch schöner darstellen zu können, hier die Phasen in der Repetier-Host Vorschau:

30SecondsOfPrint.jpg

Links sieht man den Rest der Schürze, das gedruckt wurde (in orange hervorgehoben), rechts dann den ersten Umriss der Bohrung (Perimeter), gefolgt vom äußeren Umriss und schließlich die ersten Bahnen der Füllung. Das entspricht den abgearbeiteten Zeilen in dem Bild zuvor (entspricht 30 Sekunden Druck). Die blauen Abschnitte sind noch zu drucken (Ausnahme: die blauen Teile der Schürze wurden bereits gedruckt!).

Wie in der Grafik angegeben, war der Leerlaufwert der DMS ca. 650. Damit ist zu erkennen, dass bei einem Retract der Digit-Wert meist kurzzeitig auf den Leerlaufwert zurückfällt.
Interessant ist der Unterschied zwischen dem ersten Umriss (die kleine Bohrung, 6mm Durchm.) und dem äußeren Umriss. Hier ist ein Anstieg von ca. 500 zu erkennen. Die vermutliche Begründung dafür liegt an einer Einstellung im Slicer (hier: Prusa Slicer) bei dem bei kleineren Umrissen eine geringere Geschwindigkeit vorgegeben werden kann. Als kleinerer Umriss gilt ein Durchmesser <= 6.5mm. Bei mir ist die Einstellung hier mit ca. 50% der normalen Geschwindigkeit zu drucken. Das wirkt sich sofort auf die Digit-Werte aus, wie man sieht (ein weiteres Argument für das Drucken mit konstantem Volumen, dass manche Slicer seit einigen Jahren anbieten).

Wählt man ein noch kürzeres Zeitfenster, ergibt sich das folgende Bild (6 Sekunden Druckdauer):

6SecondsOfDigits(annotated).jpg

Hier sieht man, dass man bereits an die Rechengrenze der Systemplatine (oder an die Reaktionsgrenze der DMS) stößt. Die meisten Digit-Werte sind über 3 oder 4 Zeilen ident, als ob diese nicht extra gerechnet/ermittelt wurden. Im Bild sind nur der letzte Teil der Schürze und der erste Umriss (die 6mm Bohrung) abgebildet.

So.

Damit dürfte meine Idee bewiesen sein. Offen bleiben noch das Fräsen und der Druck im Vasenmodus. Diese werde ich in den nächsten Tagen auch noch durchführen. Den Vasenmodus zu simulieren geht ohne Aufwand. Das Fräsen des Filaments werde ich provozieren indem ich die Temperatur um 30 oder 40 Grad reduziere.

Aber das Ganze hier in die Firmware einzuarbeiten bekomme ich nie und nimmer hin

. Dazu kann ich nicht ausreichend programmieren - es ist schon eine Leistung, dass ich es fertig brachte, die Digit-Werte auszudrucken (es waren im Endeffekt nur 3 geänderte Zeilen).

Genug für jetzt. (Ich verzichte auf das letzte Bild, Dauer 44 Sekunden, zeigt nur die Phase der 100%-igen Füllung.)

Möge COVID-19 alle verschonen!

mjh11

AtlonXP · Beitrag von **AtlonXP** » Mi 19. Mai 2021, 17:19

Hallo rf1k_mjh11,
neue Ideen sind immer willkommen.

Nibbels wird sich vermutlich hier nicht mehr so schnell blicken lassen.
Ich habe die Hoffnung, ihn an wieder stattfindenden Stammtischen zu treffen.
Auch bin ich gespannt was mhier dazu schreibt.

Deine Idee kollidiert allerdings mit der Community Funktion: DigitFlowCompensation.
wiki/index.php/DigitFlowCompensation

Was ich jetzt noch nicht ganz verstanden habe ist:
Was soll der Drucker machen, wenn dieser Unregelmäßigkeiten an den Digits feststellt?

Für unsere Community FW war mal noch angedacht, einen Filament Run_Out Sensor einzupflegen.

Das wollte ich noch loswerden:
Seit dem ich mit dem E3D V6 drucke, sind meine Digits der Art in den Keller gewandert,
dass ich keine Probleme mehr mit den Digits habe.
Das E3D V6 hat auf jeden Fall mehr Dampf auf der Düse!

Wenn ich grob drucke, ist bei mir mit einer 0,4 mm Düse und LH 0,2 mm Schluss.
Eventuell reicht bei deinem PICO das Schmelz Volumen nicht mehr aus?

Wenn ich schnell fahre, ist bei etwa 80 mm/s eine Schallmauer.
Bei dieser Geschwindigkeit kommt der Drucker ins Stockeln.
Auch bei lang gezogenen Radien wie dem Spuckschutz.

Auch häufen sich die Lese Errors bei höher Geschwindigkeit.

In unserer Community FW habe ich leider zwei Fehler gefunden die mich stören.
- Der HBS sollte so störungsunempfindlich laufen, wie der Z Offset Scan.
- Wenn im Startcode die Stratmade kleiner wie 0,2 mm definiert ist,
wird SenceOffset automatisch abgeschaltet.

Die Fehler wird wohl leider keiner mehr beheben…

LG AtlonXP

Beitrag von **af0815** » Mi 19. Mai 2021, 17:51

Für meinen Teil bin ich auf Klipper umgestiegen, somit ist die Community Version maximal als Nachschlagwerk interessant.

Die Auswertung der DMS ist dort in Klipper entkoppelt vom Drucken, das macht die Sache nicht einfacher. Noch dazu kämpfe ich mit Python, wobei aktuell Python noch gewinnt.

Ansonsten ist der Beitrag hoch interessant.

Beitrag von **rf1k_mjh11** » Mi 19. Mai 2021, 20:23

Hallo AtlonXP,

AtlonXP hat geschrieben: ... Deine Idee kollidiert allerdings mit der Community Funktion: DigitFlowCompensation.
wiki/index.php/DigitFlowCompensation ...

Dieser Punkt wurde in einer meiner Entwürfe behandelt und ist dann irgendwie beim Schreiben des Beitrags verloren gegangen (und der Beitrag wäre nooooch länger geworden

).
Im Prinzip handelt es sich um ein ähnliches Problem wie der Vasenmodus. Der Druck wird kaum schwanken (zumindest nehme ich an, dass im Vasenmodus kaum welche auftreten werden).
Nur, mit Ausnahme das Vasenmodus, ist es nicht ganz so. Siehe dazu die Erklärung im neuen Beitrag der Vor- und Nachteile der DMS, unter DigitFlowCompensation.
Denn auch mit DigitFlowCompensation wird es garantiert Retracts geben, spätestens beim Layerwechsel. Und auch, wenn die Geschwindigkeiten der Layerzeit angepasst werden. Wird die Geschwindigkeit stark gesenkt (bei einem dünnen Turm, z.B.), wird auch DigitFlowCompensation nichts machen können und der Digit-Wert wird zwangsläufig sinken. (Aber darauf sollte man nicht unbedingt achten: ist vielleicht zu unsicher.)

Trotz allem, ich gebe zu, ich vermute ,dass sich ExtrusionSense im Vasenmodus, mit volumetric speed und mit DigitFlowCompensation schwer tun wird.

Möge die COVID-19 Impfung bald alle erreichen!

mjh11

Beitrag von **rf1k_mjh11** » Do 20. Mai 2021, 14:22

Hier muss ich im Nachhinein feststellen, dass nikibalboa mir mit der Idee hier eigentlich zuvorgekommen ist.

So jetzt geht es an die Fragen:

#1:

AtlonXP hat geschrieben:Wenn ich grob drucke, ist bei mir mit einer 0,4 mm Düse und LH 0,2 mm Schluss. Eventuell reicht bei deinem PICO das Schmelz Volumen nicht mehr aus?

Der Pico hat genug 'Schmackes' für die Temperaturen, schließlich wurde er von der Konzeption her schon für bis zu 500°C ausgelegt (BTW, habe mir kürzlich einige 500° Thermistoren besorgt).

Bei der Layerhöhe von 0.45mm und der Gescwindigkeit von 55mm/s pendelt die durchschnittliche Heizleistung um den Wert von 65% Auslastung herum.

Rechnerisch ergibt sich (aus Layerhöhe, Raupenbreite=Düsendurchmesser, Geschwindigkeit) ein verdrucktes Volumen von 14.85mm³/s. Die Schmelzkammer des Picos hat etwas über 75mm³ (inkl. ein Teil der Düse, die ja mitgeheizt wird). Damit bleiben 5 Sekunden Zeit, das Material auf Temperatur zu bringen.
Rechne ich deine Angaben nach (LH, RB, Geschw) komme ich mit 0.2*0.4*80 auf bloß 6.4mm³/s, und damit weniger als die Hälfte von meinem Wert. Allerdings, vermute ich, basieren deine Zahlen auf ABS, meine auf PETG (bei PLA bliebe alles gleich, nur die Geschwindigkeit würde auf ca. 65-70mm/s wachsen).

Was ist Volumen der Schmelzkammer beim E3D?

#2:

AtlonXP hat geschrieben:Hallo rf1k_mjh11,
du bist mir die Antwort schuldig geblieben, was soll der Drucker machen,
wenn er im Retrakt eine Störung erkennt?

Genau genommen wird das System vermutlich nicht in der Lage sein "im Retract eine Störung" zu erkennen. Eher etwas danach, wenn die Digits nicht abfallen, oder wieder etwas später, wenn diese nicht erwartungsgemäß steigen. Ich nehme aber an, du meinst, "Was soll im Falle einer erkannten Störung geschehen?".

Da bieten sich mehrere Möglichkeiten an. Als erstes wäre interessant, was denn so marktübliche Filament-Überwachungssysteme machen.
georg-AW hat eines entwickelt. Sein Filamentüberwachungs-System stoppt den Druck und gibt einen Alarm aus.
Egal wie das externe System aussieht, in jedem Fall wird die Firmware angepasst werden müssen, denn schließlich sollte diese auf ein von Extern eingebrachtes Signal reagieren müssen.

Kommen wir zurück zu unserem Fall:
Wie reagiert das System?
Am flexibelsten wäre, ähnlich wie die OBJECT_OUTPUT_SCRIPT, eine in der Firmware hinterlegte Befehlskette anzulegen, die dann beim Auftreten der Störung automatisch abläuft. Den Script kann sich dann jeder, der damit klar kommt, persönlich seinen Wünschen entsprechend anpassen.

Beispiele wären:

M3070 S2 ; pause print & move away
M3117 Extrusion ERROR! ; show message (alternate: 'M117')
M104 S120 ; reduce filament temp. to prevent material degradation
; Do not change bed temp! Otherwise adhesion may fail.
M300 S3520 P3000 ; beep for 3 seconds
M3071 ; wait for continue
Das ist mein persönlicher Vorschlag. Im Prinzip mache ich es so, wenn ich einen Fehler in einem langen Druckauftrag rechtzeitig entdecke. Ich kann dann, nach den Filamentwechsel (oder was auch immer) und der Temperaturanhebung, recht einfach wieder weiterdrucken.

Oder

M401 ; store position
G91 ; relative coords
G1 Z0.5 F2000
G1 X0 F5000
M104 S120 ; reduce filament temp. to prevent material degradation
; Do not change bed temp! Otherwise adhesion may fail.
M3117 Extrusion ERROR! ; show message (alternate: 'M117')
M300 S3520 P3000 ; beep for 3 seconds
M3071 ; wait for continue
Diese Lösung wäre für das spätere, manuelle Weiterdrucken gedacht. Dabei dürfen aber die Schrittmotore (zumindest der Z-Motor) keinesfalls stromlos geschaltet werden. Sonst verliert man die Z-Höhe. Die muss uns erhalten bleiben. Auch wenn wir es schaffen, die Koordinaten zu speichern, die zur Zeit der Fehlererkennung galten, nützt uns der Z-Wert wenig. Denn man sollte Z NICHT homen !!!!! Es bestünde CRASH-Gefahr. Die X und Y Achse hingegen können sehr wohl ge-homed werden.

Schön wäre es, die Koordinaten, wo die Düse gerade war als der Fehler erkannt wurde, an die Log-Datei auszugeben, ebenso die zuletzt bearbeitete Zeilennummer. Dann könnte man jeden Druck manuell tatsächlich retten (solange sich das Druckobjekt nicht vom Bett gelöst hat, oder das Objekt zumindest nicht verschoben wurde - Sekundenkleber als Rettung!).

Eine weitere Variante wäre natürlich, einfach den Druck zu stoppen und die Heizungen auszuschalten. Da muss man das Druckobjekt vermutlich abschreiben. Einmal verliert man 'Z', dann kühlt sich das Bett ab und die Haftung (und damit die X- und Y-Position) geht flöten.

Es gäbe eine Möglichkeit, 'Z' zu retten. Das beschreibe ich im nächsten Beitrag.

Wünsche Gesundheit!

mjh11

Beitrag von **rf1k_mjh11** » Do 20. Mai 2021, 14:58

Einen Druck retten

Wenn mir bisher ein Filamenttransportfehler untergekommen ist, und ich den Druck 'retten' wollte, konnte ich den Drucker nicht ausschalten damit ja nicht die Z-Position verloren gehen konnte.

gelogen, geht auch anders

Man hat 'Z' verloren

Wurde der Drucker ausgeschaltet, oder auch nur der Schrittmotor der Z-Achse, hat man eigentlich schon 'Z' verloren. Das Problem ist einfach, dass man Z nicht homen kann. Es liegt ein halb-fertiges Durckobjekt auf dem Bett. Würde das Bett hochfahren, käme es zur Kollision.
Hat man 'Z' verloren und kann Z nicht homen, ist einem der exakte Z-Wert unbekannt. Ein Weiterdrucken wird schwierig.

Es gäbe jedoch eine Möglichkeit die Position der Z-Achse zu bestimmen, ohne dass man das Bett hochfahren muss. Diese Methode benötigt aber zusätzliche Hardware. Diese Hardware wäre dafür sozusagen 'Conrad-konform'. Es handelt sich dabei um einen zweiten Z-Endschalter. Mit einem unteren Endschalter kann man ebenso Z=0 bestimmen, ohne das Bett hochfahren zu müssen. Man muss nur einmal das System quasi 'eichen' indem man Z homen tut (auf Z=0 bringt), dann nach unten fährt, bis der untere Schalter auslöst und sich den Gesamtabstand 'merkt' (am besten im EEPROM). Habe ich dann irgendwann ein halbfertiges Druckobjekt auf dem Bett, muss ich nur den unteren Schalter auslösen und kenne wieder mein 'Z'.
Das wird vermutlich ebenso nicht in der Firmware implementiert sein.

Besonders tüftl-feudige könnten das Ganze ohne Firmware-Eingriff hinkriegen:
Nachdem der untere Schalter eingebaut wurde, kann man natürlich händisch den Abstand ermitteln und notieren. Danach, wenn 'Z' verloren ging, ebenso wieder händisch den unteren Schalter anfahren.
Dann mittels Eingabe des GCode-Befehls

G92 Z[notierter_Wert]

wird die Position der Z-Achse korrekt definiert.

Wünsche allseits Gesundheit!

mjh11

mhier · Beitrag von **mhier** » Do 20. Mai 2021, 16:05

Versteh mich bitte nicht falsch, ich finde die Idee und die Arbeit, die du schon rein gesteckt hast, beeindruckend. Aber was spricht eigentlich gegen einen einfachen Filament-Sensor? Den kann man sich doch für ein paar Cent mit einer Lichtschranke selbst bauen. Das dürfte bedeutend einfacher sein und vor allem viel zuverlässiger - in beide Richtungen. Wenn dir bei einem langen Druck über Nacht der Algorithmus reingrätscht und den Druck fälschlich unterbricht, ist das auch ziemlich ärgerlich. Die entscheidende Frage ist also am Ende, wie oft passiert das, und wie oft kannst du damit einen echten Fehlschlag verhindern?

M.M.n. ist es übrigens recht wichtig, einen Fehler bei der Filamentzufuhr sofort zu erkennen, nicht erst 1-2 Layer später. Die Layer fehlen dir ja sonst im Druck.

Btw: Mit einem unteren Endschalter könntest du auch einfach generell homen. Das löst auch gleich sämtliche Probleme mit dem wackeligen Z-Schalter beim RF1000

Es gibt durchaus einige Drucker, die das genau so machen. Gerade mit Klipper kann man die genaue Z=0 Position ja auch auf längere Distanz gut vermessen, d.h. man würde einfach zügig bis ca. 10mm über das Bett fahren und dann per DMS nachmessen. Dadurch würdest du die genaue Position des (unteren) Z-Schalters vermessen. Nur das homing dauert dann generell natürlich ein bisschen länger...

Allerdings hat neu homen durchaus immer gewisse Ungenauigkeiten. In X und Y wird man evtl den Ansatz sehen...

AtlonXP · Beitrag von **AtlonXP** » Do 20. Mai 2021, 17:27

Ich könnte mir vorstellen, dass es mit zwei Endschalter für die Z Achse auch ungenau wird.

Wir haben einige Z Offsets zu berücksichtigen.
Heute ist mein normaler Z Offset der Matrix bei irgendwo -5,x mm und gestern war er bei -4,5 mm.
Dann ist mein zusätzlicher Z Offset meist zwischen 0,03 und 0,08 mm, je nach Layerhöhe und Oberfläche der Druckplatte.

Die Unterschiede ergeben sich aus verschiedenen Druckplatten und auch gewechselte Hot End.
Da sage ich Prost Mahlzeit für den Programmierer!

Auf meine Lichtschranke bin ich stolz!

LG AtlonXP

Beitrag von **rf1k_mjh11** » Do 20. Mai 2021, 20:31

Weitere Antworten

mhier hat geschrieben:Aber was spricht eigentlich gegen einen einfachen Filament-Sensor? Den kann man sich doch für ein paar Cent mit einer Lichtschranke selbst bauen. Das dürfte bedeutend einfacher sein und vor allem viel zuverlässiger - in beide Richtungen.

(Hier scheinen gegenseitige Verständnisschwierigkeiten zu herrschen.)
Als erstes könnte ich AtlonXPs Frage weiterleiten: "Was passiert, wenn die Lichtschranke anspricht?" Dabei nehme ich an, du sprichst von einer Lichtschranke, wie sie früher in einer Computermaus war. (Bloss eine einfache Lichtschranke würde nur ein 'Filament-Aus'-Zustand erkennen.) Also mit Schlitzscheibe und Lichtschranke: Entweder muss man dann das Signal in der Firmware aufarbeiten, oder einen eigenen Microcontroller dafür nehmen (kosten heutzutage auch fast nichts).
Irgendwo muss die Firmware trotzdem angepasst werden. Oder soll die Lichtschranke-Microcontroller-Kombination beim Auftreten eines Fehlers einfach eine Sirene ansteuern?

Der Drucker würde dann munter, ohne Filament zu extrudieren, weiterarbeiten. Was sinnlos wäre. Die Firmware wird auf das Signal der Filamentüberwachung reagieren müssen und dann entsprechende Schritte setzen (siehe meine Beispiele in Beitrag #6).

Und was der Preis von ein paar Cent angeht, wage ich zu behaupten, dass die reine Firmware-Lösung, wenn sie einmal steht, jedem neuen User exakt 0 Cent kosten würde (und ohne Einbauschwierigkeiten verbunden wäre - verlangt dafür aber das Aufspielen der neuen Firmware - was bei der Lichtschranke ja auch notwendig wäre).
Bezüglich der Aussage "in beide Richtungen" kann ich nur annehmen, dass die FW-Lösung auch dort reagieren würde. Schließlich betrachtet die FW nur das Auf und Ab der Digits. Geht was beim Retract schief, sollte eigentlich die FW innerhalb weniger Sekunden ebenfalls reagieren.

mhier hat geschrieben: ... ist es übrigens recht wichtig, einen Fehler bei der Filamentzufuhr sofort zu erkennen, nicht erst 1-2 Layer später. ...

Völlig richtig. Je früher, desto besser. Die Frage ist, wie schnell reagiert die Lichtschranken-Version? Jedes der bekannten Systeme hat seine Grenzen. Die Lichtschranke, oder auch die Magnete in der Lösung georg-AWs bewegen sich nur so schnell wie das Filament gefördert wird. Die Magnete beim georg-AW sind so weit auseinander dass die Auflösung in gewissen Situationen bereits problematisch werden könnte.
Extrembeispiel gefällig?: Nehmen wir an, wir drucken was ganz Feines, das Material ist problematisch und kann nur langsam gedruckt werden (ähnlich TPE). Die Einstellungen: Filament 2.85mm, einer 0.2mm Düse und 0.05mm Layerhöhe, einer langsamen Geschwindigkeit von 25mm/s. Das ergibt ein Fördervolumen von nur 0.25mm³/s. Das wird durch den Transport von 0.039mm Filament pro Sekunde erreicht. Da könnte passieren, dass der Algorithmus zuschlägt, obwohl nichts fehlt. Zugegeben, auch die Firmware-Variante würde sich hier schwer tun.

Jedenfalls, um auf die Reaktionszeit zurück zu kommen:
Man sieht anhand der ermittelten Daten im Beitrag #2, dass in fast allen Druckaufträgen ein Transportfehler innerhalb weniger Sekunden gefunden werden würde, und nicht erst nach 1-2 Layer.

mhier hat geschrieben:Wenn dir bei einem langen Druck über Nacht der Algorithmus reingrätscht und den Druck fälschlich unterbricht, ist das auch ziemlich ärgerlich.

Kann bei der Lichtschranke genauso passieren.

Wenn aber die von mir gewünschten/erhofften Bedingungen erfüllt werden würden (dokumentieren der Koordinaten und der letzten abgearbeiteten GCode-Zeile), könnte ich an nächsten Tag den unterbrochenen Druckauftrag weitaus leichter fortsetzen als wenn die Lichtschranken-Version den Job stoppt.

mhier hat geschrieben:Allerdings hat neu homen durchaus immer gewisse Ungenauigkeiten. In X und Y wird man evtl den Ansatz sehen...

Das ist richtig. Die Genauigkeit wird durch die Schaltpunktschwankungen der Schalter bestimmt. Diese sind aber sehr gering und dürfte im hundertstel-Bereich liegen (tauscht man die Original 'gummi-benoppten' Schalter gegen ordentliche Microschalter wird es noch viel besser - wie es mit optischen Endschaltern aussieht, weiß ich hingegen nicht).

Impfung für Alle!,

mjh11