M600 / Filament Sensor verhält sich unerwartet
Hallo,
Bei dieser Datei aber verhält sich das sehr merkwürdig und jetzt schon ein paar mal wiederholt getestet:
Druck startet und heizt Druckbett und dann Extruder.
Erste Merkwürdigkeit ist schon mal dass er den G1 Z5 F5000 ; lift nozzle relativ am Anfang schon mal ignoriert.
Aber ok.
Er druckt und wenn der Filament Sensor anschlägt druckt er noch ein bisschen weiter zur Position P1 (ich schätz der Puffer wird noch leergefahren), dann fährt der Druckkopf in die ParkPosition wie im Eeprom eingestellt.
Am Display erscheint die Meldung "Klicken zum Aufheizen ..." mit der aktuellen Extruder Temperatur.
Jetzt fährt der Druckkopf sofort wieder zur letzten Position P1 wo er aufgehört hat und druckt noch ein bisschen weiter bis Position P2?
Dann bleibt er einfach an Ort und stelle stehen auf P2.
Wenn ich jetzt am Display die ganze Filament-Tausch Prozedur beende, dann macht ein ein Homing von x und y, wie in der Firmware konfiguriert, und dann fährt er wieder an die P1 und druckt wieder bis zu P2 aber mit extrem viel Filament-Vorschub bis er zu P2 gelangt ist und dann druckt er wieder normal weiter.
Das ruiniert natürlich den ganzen Druck.
Vor allem macht mir das sorgen, weil ich im GCode extra ein M600 drin hab, weil ich die Farbe tauschen möchte.
Habs auch nochmal mit einer anderen Datei getestet und da fährt er brav in die Parkposition, wartet, nachdem das Filament gewechselt wurde fährt er wieder auf die alte Position und druckt von dort ganz normal weiter.
Einzig was in beiden Fällen ist, dass er die aktuelle Extruder Temperatur nach dem Filamentwechsel auf 0 stellt und wenn man die nicht manuell wieder einstellen würde er einfach weiterfahren ... aber ok zu dem Zeitpunkt steht man eh vorm Drucker.
Link zum GCode
Link zur Configuration.h
hab bei meinem CoreXY HEVO versucht eine Datei zu drucken über SDKarte und weil es eine große Datei ist, hab ich versucht einmal die ganzen Reststücke zu verdrucken. Da ich ja einen Filamentsensor eingebaut habe sollte das auch kein Problem sein.
Hab den auch mit anderen Dateien schon getestet und das hat auch ordentlich funktioniert.
Firmware ist die DEV Version vom 29.10. Board ist ein RADDS 1.5; Filament Sensor ist ein Optischer Switch. Bei dieser Datei aber verhält sich das sehr merkwürdig und jetzt schon ein paar mal wiederholt getestet:
Druck startet und heizt Druckbett und dann Extruder.
Erste Merkwürdigkeit ist schon mal dass er den G1 Z5 F5000 ; lift nozzle relativ am Anfang schon mal ignoriert.
Aber ok.
Er druckt und wenn der Filament Sensor anschlägt druckt er noch ein bisschen weiter zur Position P1 (ich schätz der Puffer wird noch leergefahren), dann fährt der Druckkopf in die ParkPosition wie im Eeprom eingestellt.
Am Display erscheint die Meldung "Klicken zum Aufheizen ..." mit der aktuellen Extruder Temperatur.
Jetzt fährt der Druckkopf sofort wieder zur letzten Position P1 wo er aufgehört hat und druckt noch ein bisschen weiter bis Position P2?
Dann bleibt er einfach an Ort und stelle stehen auf P2.
Wenn ich jetzt am Display die ganze Filament-Tausch Prozedur beende, dann macht ein ein Homing von x und y, wie in der Firmware konfiguriert, und dann fährt er wieder an die P1 und druckt wieder bis zu P2 aber mit extrem viel Filament-Vorschub bis er zu P2 gelangt ist und dann druckt er wieder normal weiter.
Das ruiniert natürlich den ganzen Druck.
Vor allem macht mir das sorgen, weil ich im GCode extra ein M600 drin hab, weil ich die Farbe tauschen möchte.
Habs auch nochmal mit einer anderen Datei getestet und da fährt er brav in die Parkposition, wartet, nachdem das Filament gewechselt wurde fährt er wieder auf die alte Position und druckt von dort ganz normal weiter.
Einzig was in beiden Fällen ist, dass er die aktuelle Extruder Temperatur nach dem Filamentwechsel auf 0 stellt und wenn man die nicht manuell wieder einstellen würde er einfach weiterfahren ... aber ok zu dem Zeitpunkt steht man eh vorm Drucker.
Link zum GCode
Link zur Configuration.h
Comments
Dort war es halt mit einem Delta Drucker, aber nach der Beschreibung dass es nur bei langen Moves im Puffer zu den Problemen kommt würde erklären wieso das jetzt bei dem (relativ) großem Teil das ich zu drucken versuche auftritt und sonst nicht.
Aber egal ob ich über Repetier-Server oder direkt mit SDKarte druck (gleicher GCode) hab ich Probleme beim Filamentwechsel/FilamentSensor
Der Link zur konfig klappt nicht. Hast du zufällig rescue support an? Weiß ja nicht wo P1 und P2 liegen aber hört sich an als ob der da mitspielt und seine pause Funktion reindrückt. Möglicherweise führt das zu einer Doppelpause mit den beschreibenen Pausen. Wenn ja versuch mal mit rescue mode aus ob es dann wie gewohnt klappt. Dann müssen wir nur eine methode finden bei M600 den rescue mode zu verhindern.
Der Link sollte jetzt funktionieren.
Rescue Support hab ich zwar in der Firmware aber nicht aktiv. Hab auch schon an sowas gedacht mit doppelter Pause usw.
Hab gestern im Code noch etwas gelesen und hab evtl. eine Vermutung, dass M600 möglicherweise eh richtig funktioniert und mein Problem evtl. nur beim Filament-Jam Event auftritt. Ich bin mal davon ausgegangen, dass der Filamen-Jam eh einfach ein M600 macht. Aber die werden laut Code ja unterschiedlich behandelt.
In beiden Fällen fährt er die Parkposition an, dann fährt er irgendwie und bleibt dann irgendwo stehen. ... Klickt man das Menü durch, dann macht auch allen möglichen Blödsinn. Wie halt oben beschrieben.
Am besten konnte ich es reproduzieren wenn der Puffer auf der langen Geraden am Anfang des GCodes ausläuft.
Was ich noch beobachten konnte, war dass Pause jedes mal wie ich es probiert habe sauber funktioniert hat.
Gibts eigentlich eine Möglichkeit die Firmware zu debuggen? Also dass man besser nachvollziehen kann, welche Variable jetzt welchen Wert enthält usw?
PlatformIO hilft ja schon mal irrsinnig weiter, damit man feststellen kann welche PRECompiler-Blöcke aktiv sind und welche nicht. Aber wenn ich die Firmware damit kompiliere, dann hängt sich der Drucker beim Laden der SDKarte auf. Und ständig zwischen VSCode und Arduino IDE wechseln ist langweilig.
Mit dem Rescue hats du mich aber falsch verstanden. In der Firmware gibt es die auch:
die meinte ich, weil Firmware unter bestimmten bedingungen wie z.b. keine Befehle während eines Drucks auch in eine Park Position fährt. Daher mal mit dem Wert auf 0 firmware testen. Ist eigentlich die einzige andere Funktion die eine Parkposition nutzt.
Hab dann auch noch versucht mit #define EMERGENCY_PARSER 0. Das hat auch nix gebracht.
Nachdem ich #define FAST_COREXYZ 1 entfernt hab (und die xy steps verdoppelt) hab ich es nicht mehr reproduzieren können. Also Filamentwechsel oder der Filamentsensor fahren beide den Puffer Leer, fahren in die Parkposition und dann wartet er dort brav. Klickt man über das Display weiter, dann startet er wieder ordentlich von der letzten Position.
Das einzige was da noch lästig ist, dass er, nachdem er wieder gestartet ist, kurz darauf die Extruder-Temperatur zurücksetzt/auf 0 stellt?.
Bezüglich Platformio:
Kompiliere ich mit Platformio, dann mach der Drucker immer einen Reset wenn ich die Karte einlege, bzw. wenn ich im Menü auf Drucke Datei klick. Witzigerweise kann ich wenn die Karte eingelegt ist mit M20 die Dateien auflisten und auch mit M23 filename.gcode und M24 einen Druck von der SDKarte starten.
Der Switch von NONLINEAR_SYSTEM inkl. Delta/FAST_COREXYZ/GANTRY usw. ist ja so gut wie nicht mehr nachvollziehbar
Da kann ich ja mal bei meinem Delta-Printer testen, ob da Filamentwechsel oder Filamentsensor überhaupt funktionieren. Hatte ich bis jetzt noch nicht probiert.