›

Seltsames Verhalten bei Recover Print

HomerNo1HomerNo1
in Repetier-Server
Hallo,

meine Konfiguration: RasperryPi4 mit Repetier Server 1.2.0 und 7" TFT, CoreXY Drucker mit Marlin 2.0.9.2

hatte gerade leider einen Stromausfall, mitten im Druck.
Als der Strom dann wieder da war hab ich dem Display Druck retten ausgewählt und dann Druck nach dem letzten Befehl fortsetzen.
Dann hat er home XY gemacht und fuhr auf das Bauteil, dachte schon er druckt jetzt, aber Pustekuchen.
Dann wieder home XY, wieder aufs Bauteil, usw.
Das macht er jetzt schon seit 10min. Das Filament ist inzwischen schön ausgeblutet, aus der Düse und das Bauteil sieht auch aus wie sau, da er ja immer schön quer drüber fährt.
Im WEB-Interface steht oben in Rotem Balken "Wiederhole bereits gesendeten G-Code"
Das Bauteil kann ich dann wohl doch wegschmeißen.

Hier mal ein paar Zeilen aus der Konsole:
Send:11:10:27.525: N4333 G90
Send:11:10:27.525: N4334 M82
Send:11:10:27.525: N4335 G1 F2400.0
Recv:11:10:27.526: X:290.7700 Y:186.8000 Z:38.9200 E:6.1126 Count A:0B:0 Z:2
Send:11:10:27.527: @enableRecoverRecording
Send:11:10:27.527: N4336 G1 X293.049 Y186.800 E6.20744
Send:11:10:27.528: N4337 M82
Send:11:10:27.528: N4338 G90
Send:11:10:27.529: N4339 G92 Z38.92000
Send:11:10:27.529: N4340 T0
Send:11:10:27.529: @waitForAllTemperatures
Send:11:10:27.540: N4341 G28 X0 Y0 R0
Send:11:10:27.541: N4342 M114
Recv:11:10:27.553: X:293.0490 Y:186.8000 Z:38.9200 E:6.2074 Count A:0B:0 Z:2
Send:11:10:27.554: N4343 G1 X293.05 Y186.80 F6000.00
Send:11:10:27.554: N4344 G1 Z38.92 F600.00
Recv:11:10:40.187: X:0.0000 Y:0.0000 Z:38.9200 E:6.2074 Count A:0B:0 Z:2 (2)
Send:11:10:40.187: M117 ETE 20:49:14
Send:11:10:40.187: N4345 G92 E6.20744
Send:11:10:40.188: N4346 G90
Recv:11:10:40.189: X:293.0500 Y:186.8000 Z:38.9200 E:6.2074 Count A:0B:0 Z:2
Send:11:10:40.189: N4347 M82
Send:11:10:40.189: N4348 G1 F2400.0
Send:11:10:40.190: @enableRecoverRecording
Send:11:10:40.190: N4349 G1 X293.752 Y187.503 E6.24886
Send:11:10:40.192: N4350 M82
Send:11:10:40.192: N4351 G90
Send:11:10:40.192: N4352 G92 Z38.92000
Send:11:10:40.193: N4353 T0
Send:11:10:40.193: @waitForAllTemperatures
Send:11:10:40.193: N4354 G28 X0 Y0 R0
Send:11:10:40.194: N4355 M114
Recv:11:10:40.211: X:293.7520 Y:187.5030 Z:38.9200 E:6.2489 Count A:0B:0 Z:2
Send:11:10:40.211: N4356 G1 X293.75 Y187.50 F6000.00
Send:11:10:40.217: N4357 G1 Z38.92 F600.00
Recv:11:10:52.823: X:0.0000 Y:0.0000 Z:38.9200 E:6.2489 Count A:0B:0 Z:2 (2)
Send:11:10:52.824: M117 Layer 319/1890
Send:11:10:52.826: N4358 G92 E6.24886
Recv:11:10:52.826: X:293.7500 Y:187.5000 Z:38.9200 E:6.2489 Count A:0B:0 Z:2
Send:11:10:52.827: N4359 G90
Send:11:10:52.828: N4360 M82
Send:11:10:52.828: N4361 G1 F2400.0
Send:11:10:52.829: @enableRecoverRecording
Send:11:10:52.830: N4362 G1 X293.752 Y190.497 E6.37362
Send:11:10:52.831: N4363 M82
Send:11:10:52.832: N4364 G90
Send:11:10:52.833: N4365 G92 Z38.92000
Recv:11:10:52.833: X:293.7520 Y:190.4970 Z:38.9200 E:6.3736 Count A:0B:0 Z:2
Send:11:10:52.834: N4366 T0
Send:11:10:52.834: @waitForAllTemperatures
Send:11:10:52.835: N4367 G28 X0 Y0 R0
Send:11:10:52.836: N4368 M114
Send:11:10:52.836: N4369 G1 X293.75 Y190.50 F6000.00
Send:11:10:52.837: N4370 G1 Z38.92 F600.00
Recv:11:11:05.586: X:0.0000 Y:0.0000 Z:38.9200 E:6.3736 Count A:0B:0 Z:2 (2)
Send:11:11:05.587: M117 ETA 08:00:03 day 15
Send:11:11:05.588: N4371 G92 E6.37362
Recv:11:11:05.589: X:293.7500 Y:190.5000 Z:38.9200 E:6.3736 Count A:0B:0 Z:2
Send:11:11:05.589: N4372 G90
Send:11:11:05.589: N4373 M82
Send:11:11:05.590: N4374 G1 F2400.0
Send:11:11:05.590: @enableRecoverRecording
Send:11:11:05.591: N4375 G1 X293.049 Y191.200 E6.41504
Send:11:11:05.592: N4376 M82
Send:11:11:05.592: N4377 G90
Send:11:11:05.592: N4378 G92 Z38.92000
Send:11:11:05.593: N4379 T0
Send:11:11:05.593: @waitForAllTemperatures
Recv:11:11:05.593: X:293.0490 Y:191.2000 Z:38.9200 E:6.4150 Count A:0B:0 Z:2
Send:11:11:05.594: N4380 G28 X0 Y0 R0
Send:11:11:05.594: N4381 M114
Send:11:11:05.594: N4382 G1 X293.05 Y191.20 F6000.00
Send:11:11:05.595: N4383 G1 Z38.92 F600.00

Comments

  • HomerNo1HomerNo1
    gerade mal in den G-Code geschaut.
    Aktuelle Z-Position ist 38,9. Die taucht im Code in Zeile 375.669 auf, kann also noch ein paar Stunden dauern.

  • RepetierRepetier
    Konnte dies nie reprodizieren, hab es aber schon mal gehört. In 1.2.1 wurde das Retten Modul überarbeitet und der User meldete das dieses Problem nicht mehr auftritt. Daher würde ich erst mal ein Update vorschlagen.
  • HomerNo1HomerNo1
    Hab den Druck dann abgebrochen und neu gestartet.
    Werde dann danach updaten.
    Danke.
  • HomerNo1HomerNo1
    So, hab das Ganze heute mal trocken (ohne Filament) durchprobiert.
    Mit V1.2.0 konnte ich das Problem wiederholen.
    Hab dann auf V1.2.1 upgedatet und den Druck ganz normal gestartet und nach 'ner Weile den Drucker ausgeschaltet.
    Dann in der Roten Meldeleiste auf Druck Retten geklickt.
    Also da oben Beschriebene Verhalten tritt nicht auf, aber wirklich zu gebrauchen ist die Funktion nicht.
    Nach dem Home XY fängt der sofort an zu Drucken, während die Düse noch aufheizt, steht der Extruder, aber der Kopf fährt fleißig seine Bahnen, halt ohne Filament zu fördern. Wenn die Düse dann ihre Temperatur erreicht hat, wird auch Filament gefördert.
    Fehlt aber halt 'ne ganze Menge.
    Leider war der Teile in der WEB Interface Konsole nicht zu sehen, daher als Foto vom Touchdisplay.

  • RepetierRepetier
    An der recover Position baut er ein @waitForAllTemperatures ein, was Ausführung bis zum erreichen der Zieltemperatur verhindern soll. Wie ich das sehe wird es immer gesendet. Werde es auch mal testen ob die Funktion eventuell beschädigt wurde. Geplant ist das jedenfalls so nicht. Aber bei meinen tests hab ich nicht lang genug gewartet um das zweifelsfrei zu sagen.

    Wenn aber mit M111 des S wert 8 als Teilsumme (binär) enthält, überspringt er das warten!
  • HomerNo1HomerNo1
    Wäre aber auch nicht so toll, wenn er auf dem Bauteil steht und wartet bis die Temperaturen erreicht sind.
    Speziell, wenn die Düse schon heiß ist, aber das Bett noch länger braucht schmilzt er ein Loch ins Bauteil.
    Wäre es nicht besser ,er würde in der Homeposition auf das erreichen der Temperaturen warte?
  • RepetierRepetier
    Dazu gibt es ja die verbinden und fortsetzen Skripte. Damit er frühzeitig aus dem Weg fährt. Problem ist normal das es schon beim Stromausfall passieren könnte mit dem einbrennen. In der reptier-firmware haben wir für den einfachen Verbindungsausfall bereits ein aus dem weg fahren in die Firmware eingebaut und speichern gleichzeitig die Position beim Ausfall um es exakt wieder herstellen zu können.

    Das beste wa sman sonst machen kann ist beim vebinden z.b.  Home XY und hoffen das die Düse noch heiß ist.

    Bei restart ist er damit bereits uas dem weg und weiter gehts ja erst (eigentlich) nach dem aufheizen was dann außerhalb passiert. Man kann auch @waitForAllTemperatures  selber im Skript verwenden, dann senden wir es nicht mehr explizit. So kann man es noch verfeinern, z.b. außerhalb aufheizen, warten und dann düse noch etwas nachfüllen da ja einiges ausgelaufen sein dürfte.
Sign In or Register to comment.