›

Head crash after successful Z-homing (several times)

CBX_MichaCBX_Micha
in Repetier-Server
Something strange happened here yesterday...

After transferring a file sliced ​​using CURA to the RS (LAN), the print head crashed into the print bed after (!) successful Z-homing, so that only a reset of the printer (Marlin, current bug fix) helped.
So I deleted the file in RS, transferred the component again from CURA... Another crash at exactly the same point.
Third attempt, this time exporting the component again from FreeCAD, re-slicing it in CURA, transferring it to RS... Bang... Another bed crash at the same point.
Only after restarting RS did this problem disappear. It hasn't reappeared yet.

So I assume that RS had something to do with the issue here, but I can't explain why or where.
Has this ever happened to anyone else?

Comments

  • RepetierRepetier
    If it happens after the print I would guess it is in the after print gcode hat it want to go down, so you should check that code if there is a command that would cause it under some conditions. It is a bit strange that it went away after restart. Would expect the code to still exist and do the same. I'm not aware of a bug that would randomly add moves. So at best you just do not meed the condition for it based on existing gcode in end print script.
  • CBX_MichaCBX_Micha
    edited June 24
    No, it was before printing started while the start code was running.
    I hadn't changed the slicer start code; I'll attach it below and mark the spot where the head hit the bed with ***.
    The phenomenon always occurred after successful homing of the Z axis. It didn't matter whether I used the file already saved in RS or a new file transferred from CURA. Restarting of the printer-board haven't helped. Only restarting RS cleared things up. After that, I was able to print the same, unchanged file without any problems.
    So far it hasn't happened again. I'll keep an eye on it. Since you haven't heard of such an error either, it seems to be something very rare and therefore not really detectable.

    ; *** Startcode für P1_GEEE Umbau (240313)***
G90					; use absolute coordinates
M220 S100					; set Feed rate to 100%
M221 S100					; set Flow rate to 100%
M204 S{acceleration_print} T{acceleration_travel}
M104 S{material_print_temperature_layer_0 * 0.80}	; set extruder temp stand by
M190 S{material_bed_temperature_layer_0}		; wait for bed temp
M211 S1					; software end stops on
G28					; home all
M400					; wait for finished moves
M501					; set config as active
M420 S1					; use former generated mesh

G1 Z3 F3000					; move print head up
    *** here...
G92 E0					; zero Extruder
*** ...or here the head crash into the bed ***
G1 X2 Y185 Z0.2 F4000				; goto start point
M109 S{material_print_temperature_layer_0}		; set extruder temp
G1 E8 F2500					; make a drop
G1 X2 Y50 E20 F1000				; print purge line
G92 E0					; zero extruder




  • CBX_MichaCBX_Micha
    edited June 24
    Update:
    Just happened again!
    Same process; restarting RS fixes the problem... Now I need a new PEI-sheet, I think ...

  • RepetierRepetier
    Did you have logging active to see afterwards which commands get send.
    What wonders me is M501 especially after homing. Normally you should not fiddle with firmware settings during print, can have negative results if it changes sizes. After all you homed already and the steps must match.
    Especially if yo home to z min nothing is dangerous.If you home to z max than M501 can change z height and when  z height during homing was higher than real z the first low z move will crash the head.
  • CBX_MichaCBX_Micha
    ... I messed up the logging; my stupidity... But next time...
    And I home on X/Y/Z=0. It doesn't make sense with a touch sensor, at least with Z, otherwise.
    M501 is fine. That just tells the FW to reset all values ​​to the default values ​​currently stored in the FW. That has nothing to do with "fiddling around" in the FW?! Only the line or the point in time is perhaps a little unfortunate when I look at it; it should go right to the top... But since that has never caused any problems so far...

    I'm going to leave everything as it is for now so as not to jeopardize traceability. I now have logging active and every time I start a new print I will record an external video showing the print head and the terminal next to it. If the error occurs again, the video, the terminal output and the log file are available. We / you / someone should be able to do something with that (I hope)
  • CBX_MichaCBX_Micha
    Ok... again right now...
    Here is the Video and both logfiles in a 7Z


    (~30mb)


  • CBX_MichaCBX_Micha

    Edit:

    I compared the log file with the log file that was created afterwards.
    Left side: log file with the head crash
    Right side: log file with the identical file (still saved in RS) from the same starting point.
    I don't really know anything about it, but the area marked in red really seems extremely strange to me in relation to the Z value...


  • RepetierRepetier
    Ja das ist fast der maximal mögliche negative z Wert für int32 Zahlen. Es wird nichts ungewöhnliches gesendet vom Server, davon kommt es also nicht. Ich denke es kommt hierher:
    Send:21:38:52.348: N60689 M400 ; wait for finnised moves
    Send:21:38:52.348: N60690 M501 ; set config as active
    Send:21:38:52.349: N60691 M420 S1 ; use former generated mesh

    Mit M420 S1 aktivierst du werte aus dem EEPROM. Ich kenne Marlin nicht gut genug um zu sagen ob M501 diese löscht, aber die die zu dem Zeitpunkt im eeprom fürs mesh leveling gespeichert sind scheinen falsch zu sein bei so einer Posititionsangabe. Versuche mal ohne M501 und messe das Mesh neu ein damit da definitiv wichtige werte drin stehen. Wenn es dann klappt kannst du gerne auch testen ob sie nach M501 imme rnoch da sind. Oder lass dir die Werte ausgeben:
    https://marlinfw.org/docs/gcode/M420.html
  • CBX_MichaCBX_Micha
    edited June 26
    Ok, mache ich mal. Mir war halt nicht klar, woher das kommt. Nach einem Neustart des RS-PI's ist das Problem jedes Mal weg, sodass ich erstmal RS in Verdacht hatte...
    Zwischenzeitlich habe ich M501 und M420 an die erste resp. zweite Zeile gesetzt. M501 kommentiere ich jetzt mal aus und teste weiter. Ansonsten ist das Mesh ok. Das hatte ich zwischenzeitlich immer mal wieder abgefragt und generiere das sowieso alle 2-3 Tage neu; das können wir als Ursache sicherlich streichen.
    Komisch nur, dass es so monatelang ohne Probleme funktioniert hat... Ghost in the machine...
  • CBX_MichaCBX_Micha
    Kurzes Update:
    • Ohne M501 gibt es Ärger. Nach einem Neustart nicht, aber wenn man mehrere Teile in Folge druckt, werden diverse Zähler nicht auf 0 gesetzt und noch einige andere Merkwürdigkeiten. M501 sollte aber an erster Stelle im pre-Printcode stehen.
    • Der HeadCrash ist noch 2-3 mal aufgetreten, ohne dass hier eine Ursache zu finden wäre.
      Nach einem vollen Update/Upgrade des Debian OS auf dem Host ist es bisher nicht wieder aufgetreten. In welchem Zusammenhang das steht, ist mir aber vollkommen rätselhaft.
    Summa summarum scheint das Problem weg zu sein. Ärgerlich, dass die Ursache nicht zu finden war, aber man kann halt nicht alles haben... B)
  • CBX_MichaCBX_Micha
    Noch ein Update:
    Der Crash passiert gelegentlich immer noch. Es scheint mir, dass nach einem abgeschlossenen Druck RS einen Status nicht mitbekommt. Das lässt sich auch daran festmachen, dass (ganz selten) der Drucker beim Drucken einen Reset macht, RS das nicht mitbekommt und irgendwo wild in der Gegend da weitermacht, wo er vor dem Reset war. Das ist dann natürlich sonst wo auf der Bauplatte; hat schon für reichlich Spagetti gesorgt.
    Ich werde jetzt als DirtFix mal nach einem Druck einen zwangsweisen Reset ausführen via PostCode... Mal sehen ob das hilft...
    Könnte ich den RS nach einem Druck per PostCode oder anders ebenfalls neu starten?

  • RepetierRepetier
    Prinzipiell kannst du externe Befehle aufrufen mit @execute, wenn die in extcommands.xml stehen und die benötigten berechtigungen haben. Da es aber schlecht ist im lauf während er den Druck beendet den Server zu stoppen könntest du "at" installieren und damit den Server Neustart mit verzögerung aktivieren.

    Einen Reset bekommen wir nur mit, wenn die Firmware nach dem Verbinden "start" sendet. Kommt auch aufs board an weil ja nach board wird die Verbindung getrennt was wir immer mitbekommen. Ist aber eher bei 32 bit boards so. 8 bit boards haben oft einen Kommunikationschip der usb nicht trennt und es dann halt darauf ankommt ob die Meldung durch kommt. Sonst meckert die Firmware nur wegen falsche Zeilennummern die ja nach dem reset bei 0 anfangen.
  • CBX_MichaCBX_Micha
    ... wegen falschen Zeilennummern oder ähnliches hat hier noch niemand gemeckert. Und ja: Ist ein 8bit Board. Ob das bei einem Reset die Verbindung trennt, weiß ich aber nicht. Wenn ich am Board selber einen Reset auslöse, bekommt RS das aber ausnahmslos mit.

    externe Befehle aufrufen mit @execute, wenn die in extcommands.xml stehen

    Muss ich mich erstmal mit auseinandersetzen. Gibt es dazu irgendwo was zu lesen?


  • CBX_MichaCBX_Micha
    edited August 25
    Neues Problem, was schon ein paar mal aufgetreten ist. Wenn es im laufenden Druck auftritt, ist der Druck tot.





  • CBX_MichaCBX_Micha
    edited August 25
    CBX_Micha said:
    Neues Problem, was schon ein paar mal aufgetreten ist. Wenn es im laufenden Druck auftritt, ist der Druck tot.






    ... gerade wieder passiert und Druck versaut bei ca. 98% fertig ...
Sign In or Register to comment.