M600 / Filament Sensor verhält sich unerwartet

Rossini

Hallo,

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? :s
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
<a href="http://" title="Link: http://">Link zur Configuration.h</a>

Rossini

Das scheint ein ähnliches Problem zu sein wie hier beschrieben: Link
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

Repetier

Zwischen G1 Z5 und G1 Z0.350 F7800.000 liegen keine Befehle die Zeit benötigen, er geht also gleich auf 0.35 (mit umweg z=5) un erst dann heizt er.

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.

Rossini

https://gist.github.com/rossiniscarface/210ad3103eb83531578437ebf052318a

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.

Weil das reproduzierbar war und ich zuerst versucht hab den GCode über den Repetierserver zu drucken hab ich dann den Drucker abgehängt und über SDKarte gedruckt. Da ist das gleiche Problem, also den Repetier-Server und Rescue-Mode usw würde ich mal ausschließen.
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.

Rossini

Also ich hab jetzt versucht noch etwas mit der Firmware herumzuspielen, aber weder Filamentwechsel noch der Filamentsensor funktionieren zuverlässig.
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.

Repetier

Nutze nur noch PlatformIO und der hat einen Debugger wenn du die passende Hardware hast. Brauchst einen hardware debugger und ein board mit passenden pins.

Mit dem Rescue hats du mich aber falsch verstanden. In der Firmware gibt es die auch:

/** Enable rescue system that helps hosts to reconnect and continue a print

* after a disconnect. */

#define HOST_RESCUE 1

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.

Rossini

Weitere Erkenntnisse:

#define HOST_RESCUE 0 hat nichts verändert.
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:

Also wenn ich den gleichen Code mit Arduino IDE compiliere, dann funktioniert das SD-Karten ohne Probleme.
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.

Repetier

FAST_COREXYZ 1 macht das er sich wie ein delta verhält also die nichtlinearen Bewegungsroutinen nutzt, aber sonst kein unterschied. Wundert mich ein wenig das dies auch auf den Filamentwechsel durchschlägt.

Rossini

Vielleicht kommt es da ja zu einer Ausnahme, dass er dann noch Befehle im Puffer hat, oder glaubt er darf noch Befehler verarbeiten;
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.