Noch mehr Antworten. Jetzt kommt AtlonXP dran.

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

Ja, ein ganz klein wenig ungenauer wird es, da die Schaltpunktschwankungen des zweiten Schalters hinzukommen. Sind es gute Schalter, handelt es sich um max. 1-2 hundertstel-Millimeter.
Die Wiederholgenauigkeit der optischen Endschalter ist mir nicht bekannt.

AtlonXP hat geschrieben:Wir haben einige Z Offsets zu berücksichtigen.

Den Einwand verstehe ich nicht. Handelt es sich tatsächlich um einen Offset, bezieht er sich auf Z=0 und sollte somit von der ganzen Sache unbeeinflusst bleiben. Auch der Programmierer müsste sich da um nichts extra kümmern. Oder verstehe ich dich falsch?
Auch ich verwende gelegentlich Offsets, ändere aber deswegen nichts an meiner 'Z=0'-Einstellung, und ändere deswegen schon gar nichts in der Firmware.

(Ist einem das Volumen der Schmelzkammer im E3D bekannt?)

Die FFP2 lebe hoch!

mjh11

Also gut, hier das alte Z Offset Lied.

In unserer Community FW haben wir folgende Z Offset Werte.
Die Offset Werte wo mit „*“ markiert sind, sind auch in der originalen FW vorhanden:

- Der Z Offset wo in der HBS Matrix hinterlegt ist. *
- Der Z Offset wo von Hand im Druckermenü eingestellt werden kann. *
- SenseOffset verwendet seinen eigenen Offset und manipuliert den Offset flüchtig über den von der Handeinstellung.
- Diese Manipulation wird meines Wissens nur im RAM gespeichert.

Der Z-Offset-Scan (mhier Scan) verschieb den HBS Z Offset nach seiner ermittelten Messung.
Dieser Wert muss im Minusbereich stehen.
Da mein Überfahrweg der Lichtschranke max. -10 mm zulässt, kann der Offset so weit im Keller stehen.

Jetzt kommt das leidige Lied, wer der Z Achse oben etwas klaut, muss es ihr unten wieder geben, ansonsten Rappelt es in der Kiste.

Da ich oben auf jeden Fall -10 mm reserviert habe, muss ich den verfahr Weg von Z um mindestens 10 mm verkürzen.

Zumindest bei dem SenseOffset gibt es ein Fragezeichen, da dieser Wert nur im RAM gespeichert ist und dieser kann auch nicht rekonstruiert werden.

Z = 0 ist immer der Schaltpunkt meiner Lichtschranke.
Da wird nichts verändert.

Z = 0 Teiledruck ist mit dem Z Offset vom HBS (M3001 Z Kompensation ein).

Du solltest unsere Community FW auf deinen Drucker aufspielen und testen.
Dein Drucker bekommt dann Flügel!

Es ist dort sogar möglich die Hysterese des Endschalters zu messen.

Hoch lebe die Impfung, falls er denn drankommt!

LG AtlonXP

rf1k_mjh11 hat geschrieben: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).

Ganz genau. Zumindest mit Klipper wäre die Auswertung ein Kinderspiel. Man muss nur wissen, wie viel mm Extrusion einem Lochabstand entsprechen. Dann kann man eine Grenze definieren, wenn nach mehr Extrusion die Lichtschranke nicht anspricht, stimmt was nicht.

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).

Stimmt, vielleicht werden es auch eher ein paar Euro, wenn noch ein zweiter Microcontroller hinzukommt. Einfacher ist die Lösung trotzdem, und Einfachheit lohnt sich oft wegen der höheren Zuverlässigkeit.

Völlig richtig. Je früher, desto besser. Die Frage ist, wie schnell reagiert die Lichtschranken-Version?

Das kann man im Design vergleichsweise frei wählen. Je enger die Löcher sind, desto häufiger wird die Lichtschranke unterbrochen. Genaugenommen geht es bei der Lösung also nicht um Zeit, sondern um Materialmenge - was gar nicht so blöd ist, denn darauf kommt es am Ende ja an. Wenn man noch mit etwas mehr gedruckten Teilen arbeitet und mittels Zahnrädern eine Übersetzung einbaut, kannst du die Empfindlichkeit ziemlich weit treiben.

Da könnte passieren, dass der Algorithmus zuschlägt, obwohl nichts fehlt. Zugegeben, auch die Firmware-Variante würde sich hier schwer tun.

Deshalb würde ich das in der Firmware integrieren und von der aktuellen Extruder-Feedrade abhängig machen. Wenn man sich ein wenig Mühe gibt, kannst du sogar konstanten Schlupf erkennen, bei dem das Material zwar noch gefördert wird, aber dauerhaft zu wenig.

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.

Ich fürchte, unter realistischen Bedingungen sieht das am Ende leider anders aus. Du wirst vermutlich, um eine akzeptable Rate an falschen Positiven zu erhalten, lange mitteln müssen.

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.

Ausgeschlossen ist nichts, da der "Algorithmus" aber sehr viel simpler ist und keine komplexen Annahmen machen muss, die vielleicht bei geänderter Temperatur oder was weiß ich plötzlich nicht mehr stimmen, dürfte das eher nicht 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.

Versteh ich nicht, die Reaktion auf das Ereignis "Problem erkannt" kann doch in beiden Fällen identisch sein. Ich würde grundsätzlich den Druck pausieren und vielleicht sicherheitshalber noch die Koordinaten loggen, aber eher lieber dafür sorgen, dass die Motoren und das Bett an bleiben (nur Extruder aus), so dass ich nur das Problem reparieren muss und einfach den Druck fortsetzen kann. Druckbett-Heizung aus kann Drucke schon zerstören...

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).

Ja einige Hundertstel sind es wohl schon, womöglich fast 1/10 (Kanten Antasten ist jedenfalls messbar genauer). Das sieht man im Ergebnis schon, wenn man eine ansonsten glatte Oberfläche hat. Dürfte aber nur ein optisches Problem sein.

Hallo,

hab' jetzt nicht alles komplett gelesen, um ehrlich zu sein

Finde die Idee von rf1k_mjh11 super mit dem ExtrusionSense!
Müsste man im Störfall nur in Pauseposition gehen und warten bis der Fehler behoben ist und könnte dann weiterdrucken.

Aber es scheint mir doch nur implementierbar zu sein von einem Firmware-Guru.

Man könnte dann gleich den Königsweg einschlagen und eine Art Encoder an ein Rädchen montieren:
dieses wird gegen das Filament gepresst und gibt der Steuerung den realen Vorschub des Filaments weiter.
Dann sieht man sofort wie viel Unterschied im Materialvorschub zwischen Soll (aus gcodes) und Ist vorliegt und könnte dementsprechend reagieren (oder gleich regeln).

(Dazu noch einen Filamentdickensensor https://www.klipper3d.org/HallFilamentWidthSensor.html (muß ich mir auch iwann zulegen )
und alle Zuführprobleme mit Filamenten wären gelöst. )

Grüße, anwofis

anwofis hat geschrieben:Man könnte dann gleich den Königsweg einschlagen und eine Art Encoder an ein Rädchen montieren:
dieses wird gegen das Filament gepresst und gibt der Steuerung den realen Vorschub des Filaments weiter.
Dann sieht man sofort wie viel Unterschied im Materialvorschub zwischen Soll (aus gcodes) und Ist vorliegt und könnte dementsprechend reagieren (oder gleich regeln).

Genau so meine ich das! Meiner Einschätzung nach ist das die einfachere Lösung - und das sage ich als erfahrener Software-Entwickler, der eigentlich immer Software- den Hardware-Änderungen vorzieht

Weitere Ergebnisse.

Ich gehe im nächsten Beitrag auf die Bemerkungen/Antworten mhiers, aus dem vorhergehenden Beitrag, genauer ein. Zuerst präsentiere ich die Ergebnisse der heutigen Versuche.

Diese waren

Filament-'Fräsen'

und

Vasenmodus (später mit Filamentfräsen gekoppelt)

Vorab: Die Ergebnisse sind nicht vertrauenserweckend, leider.

Den Versuch mit dem Fräsen machte ich mit zwei kleinen 20x20x4mm Quader, mit geringem Füllgrad (um Material & Zeit zu sparen). Da zwei Quader vorgegeben waren, wurde ein Retract zwingend, beim Verfahren vom ersten zum zweiten Objekt, erforderlich.
Das Fräsen provozierte ich indem ich am Ende des ersten Layers die Temperatur auf 90° reduzierte (was für das verwendete PETG wohl etwas zu wenig ist ).
Der Verlauf der F-Digits über die volle Druckzeit von ca. 4 Minuten, sieht so aus:Man kann gut erkennen, dass auch in der Phase des Fräsens, wo schon kein Material mehr gefördert wird, ein Retract sich trotzdem deutlich auf die Digits auswirkt (entgegen meiner Annahme!). Damit könnte man diesen Zustand nicht auf einfache Weise über den Digit-Verlauf erkennen.

Ebenso traurig macht der Versuch im Vasenmodus.
Für diesen Versuch wurde eine Zeitlang im Vasenmodus gedruckt, nach einigen Minuten wurde die Temperatur ebenfalls auf 90° reduziert, um ein Fräsen zu provozieren.
Der gesamte Druck (bis zum Abbruch, insgesamt etwas über 9 Minuten) sieht so aus:Man sieht schon, dass sich das Erscheinungsbild der Digits (wenn gefräst wird) sich von jenem im regulären Vasenmodus unterscheidet, aber das nutzt nichts, da das Digit Verhalten, wenn nur mehr Filament gefräst wird, sich kaum vom Digit Verhalten beim normalen Drucken unterscheidet (also wenn nicht im Vasenmodus gedruckt wird). Damit müsste ein Algorithmus viel zu komplex werden, um verlässlich einen Fehler zu erkennen.
Für die Interessierten gibt es ein 11-Sekunden Ausschnitt aus der Vasenmodus-Phase:Hier sieht man, was ich vermutete: Dass die Digit-Schwankungen im Vasenmodus sehr gering ausfallen würden. Das ist quasi ein bildlicher Beweis des eigentlichen Hintergedankens der 'Volumetric Extrusion', wo vom Slicer versucht wird, das extrudierte Volumen möglichst konstant zu halten (ähnlich wie DigitFlowCompensation in der Community Firmware).

Damit sieht es jetzt aus meiner Sicht so aus:

• Eine Filamentüberwachung rein auf Basis der F-Digits könnte zwar das Ende des Filaments erkennen, aber eine
  verstopfte Düse oder 'Filament-Fräsen' kaum.

Na ja, man lebt, man lernt.


Mögen Alle von COVID-19 verschont bleiben!

mjh11

(Antworten auf den vorhergehenden Beitrag kommen erst morgen)

rf1k_mjh11, danke für deine Mühen.

Wie ich weiter oben schon schrieb:
Zuerst gehen die Digits hoch und dann fängt das Ritzel an zu fräsen.

Wir haben in der FW zwei verwandte Funktionen:
Emergency Stopp und das selbe um die Pausefunktion zu aktivieren.
Nibbels hat bis zu Letzt, an der Pausefunktion gewerkelt.
Wenn der Drucker längere Zeit im Pausemodus steht, wird die Hot End Temperatur gesenkt.

Falls man auf FlowControl verzichten möchte,
kann man diese Funktion abschalten und dafür diese andere aktivieren.
Es wird leider nicht viel bringen, wenn die Digits unter die Decke gehen
ist der Druck bereits versaubeitelt!

So neben bei, dein Extruder scheint ordentlich eingestellt zu sein,
wenn dieser mehr als 10 000 Digits schafft.

Bei etwa > 13000 Digits nehmen die DMS schaden!

LG AtlonXP

.
Nun,
ich glaube, nachdem meine Messungen und Versuche fehlgeschlagen haben, werde ich das Feature von

ExtrusionSense

auf

ExtrusionNonSense

leider umbenennen müssen.


Immunität über Alles!

mjh11

Vielleicht könnte man deine Idee aus der PM aber noch mal aufleben lassen? Eine vernünftige Überwachung des Filamenttransports wäre doch schon eine feine Sache... Willst du noch mal einen separaten Thread dafür aufmachen? Ich denke, wir könnten noch ein paar Ideen von findigen Tüftlern gebrauchen für die ideale Umsetzung