Die Idee mit dem Maussensor habe ich vor (über?) 2 Jahren aufgebracht. Ich konnte damals auch beweisen, dass auch transparentes Material erfasst werden kann.
Ich wollte das als hochauflösende Filamentüberwachung sehen. Jetzt im Nachhinein könnte es auch imstande sein, den Schlupf bei höheren Druckgeschwindigkeiten zu kompensieren.

Gescheitert ist die Idee daran, dass ich von der Elektronik zu wenig verstehe, und bei der Programmierung ebenfalls zu wenig Einblick haben.

Ich habe mir damals viele Links zusammengesucht, wo Bastler diese Sensoren in Lego-Objekten, in kleinen Robotern als 'Kilometerzähler, usw., einsetzten. (Hier und hier, z.B.)

Die besten, da einfachsten Sensoren gab es in den original Microsoft Kabel-Mäusen. Sind inzwischen schwer zu finden. Der Sensor Chip, selbst, wird nicht mehr produziert. Die neueren Chips sind funktionsüberladen.

Eine zerlegte Microsoft Maus hängt jetzt noch bei mir am Arbeitstisch herum.

mjh11

Was sicherlich einfacher ist:

Eine Funktion, die festlegt, dass der Drucker bei großen Digits langsamer druckt.
Es gibt im Prinzip schon die Funktion, dass sich der Drucker pausiert, wenn die Digits viel zu hoch werden:
http://www.rf1000.de/wiki/index.php/GCo ... definieren

Und man könnte z.B. bei zweidrittel dieses Wertes anfangen den Drucker bis z.B. auf die halbe Geschwindigkeit zu drosseln.
Mein PETG verursacht definitiv bei hohen Digits Underextrusion, da wir grad heute davon gelesen haben ^^. Geschwindigkeit runter und die Digits fallen wieder.
Dann ist zwar die Ursache im Fall einer Düsen-Verstopfung nicht behoben, allerdings könnte es manchen Druck retten und Fehleinstellungen bei der Geschwindigkeit kompensieren.

Notiz zu M3075: Würde diese Funktion 2x pausieren, müsste eigentlich der Druckkopf auch vom Bauteil wegfahren. Das tut er laut Wessix aktuell nicht. Ich werde das mal beizeiten testen.

LG

Hi
Die Feststellung, dass sich das Filament bewegt sagt eigentlich wenig aus. Wichtig ist, ob es sich genau so bewegt wie vom Programm vorgegeben.
Eine wirkliche Überwachung ist nur möglich, wenn die Feederbewegung ( Rändel, Ritzel ) mit der Bewegung der Andruckrolle verglichen wird.
D.h. die Synchronizität überwacht wird. Ob das mit zwei Maussensoren bewerkstelligt wird oder mit optischen bzw. Hallsensoren ist relativ egal.
Das Bewegungsmuster muss übereinstimmen. Dabei kann eine Phasenverschiebung, solange sie konstant ist, keine wesentliche Fehler reinbringen.
Mit meinem System Filawatch glaube ich , das Problem fast gelöst zu haben. Schwierigkeiten gibt es nur bei sehr kleinen Druckobjekten oder extrem niedriger Layerdicke ( << 0.08mm ) Da bewegen sich bei mir die Magneträder extrem langsam. Weil ich eine analoge Auswertung habe, entstehen dann Fehler. Sonst aber funzt es gut. Könnte man die Auflösung noch steigern, wäre auch das gelöst. Die Unterbringung von optischen Maussensoren ist jedoch kaum möglich. Es geht beim RF1000 schon sehr eng zu und her. Auch andere optische zb. Encoder sind zu gross oder zu teuer.
Jeder Vorschlag einer alternativen Sensorlösung ist willkommen. Mit Vorschlag wie unter zu bringen !

ciao Georg

Georg/georg-AW,

georg-AW hat geschrieben:Die Feststellung, dass sich das Filament bewegt sagt eigentlich wenig aus. Wichtig ist, ob es sich genau so bewegt wie vom Programm vorgegeben.

Da nützen zwei Sensoren, eines am Rändelrad, eines an der Andrückrolle auch nichts, wenn Schritte verloren gehen. Da müsste man wirklich die tatsächlich geförderte Menge (=Strecke) mit dem geforderten Wert im GCode vergleichen.
So zumindest habe ich es mir damals vorgestellt, als ich an der Idee mit dem optischen-Sensor knabberte. Ich stellte mir so was wie ein Raspberry oder Arduino vor, durch den der GCode geschleift wird. Der würde nur auf E-Werte achten und den GCode unverändert an den Drucker weiterleiten. Zumindest einen Kalibrierungslauf müsste man machen, danach sollte das System 10mm mit 10mm vergleichen können. So ein System würde Schrittverluste erkennen können.

Und 100%ig ist das auch nicht. Ich hatte Fälle (wie Andere im Forum gewiss auch) wo ein flexibles Filament wie NinjaFlex, am Hot End vorbei gefördert wird. Das Rändelrad dreht sich munter weiter, ebenso die Andrückrolle. Da stimmen deine ermittelten Werte, und auch die Werte, die mittels direktem Vergleich des GCodes entstehen würden, stimmen exakt. Keines der zwei Systeme würde Alarm schlagen. Trotzdem ist der Druck Schrott, falls man nicht zufällig daneben steht.

Aber deine physisch vorhandene Lösung ist trotzdem noch immer zehntausend mal besser als meine virtuelle Version, bei der es noch an der Verwirklichung mangelt.

mjh11

Nibbels hat geschrieben: Quelle: http://www.extrudable.me/2013/04/18/exp ... nd-limits/ 02.05.2017
"print failures were solved when they were encouraged to try adjusting settings to bring the extrusion rate down below the estimated limits for 0.4mm nozzles – around 8-10 mm³/s. This isn’t helped by the fact the fast ‘QuickPrint’ setting in Cura tries to print at 11.2mm³ per second – almost certainly enough to cause problems for a 0.4mm nozzle."

Um diese Info zu verknüpfen:
Mit dem Repetier-Host 2.0.0 und dem Prusa-Slicer kann man diesbezüglich einiges limitieren: