Moin,

bei mir kommt es gelegentlich (ca. jedes 5. mal) vor, das nach dem Druck bzw. nach
dem Output des Objekts der drucker Tilt. Es bewegen sich dann unkontrolliert alle Achsen
und der Drucker muss resettet werden....

Ideen ?

easygo25 hat geschrieben: Habe den Community-MOD RF.01.38.34.Mod im Einsatz

Du druckst von SD-Karte, korrekt?
Hast du irgendeine Möglichkeit mit einer Kamera dieses Verhalten als Video auf youtube hochzuschieben?

Führst du OutputObject selbst mit dem M3079 aus `
oder machst das der Drucker nach dem Druck selbst?
Oder passiert es nur, wenn du übers Menü den "Stop Print" wählst?

Ich bin echt froh drüber, dass jemand solche Verhaltensweisen meldet. Ich bin in manchen Punkten schon zu eingefahren und variiere nicht mehr viel.

LG

Hi,

ich werde das die Tage mal versuchen zu filmen. Bin mir nicht sicher, ob es nur nach dem Abbruch oder auch
nach dem geplanten Ende auftaucht.

Gesteuert wird es durch das Stop-Script:
M104 S0 T0 ; turn off left extruder 1
M104 S0 T1 ; turn off right extruder 2
M140 S0 ; turn off heat bed
M3079 ; output the object
M84 ; disable motor

Ich hab mal mit Neustarts gekämpft. Das war der Fall, wenn die Interrupts extrem schnell nacheinander auftreten. Und dazwischen wenig Luft für den Watchdog blieb bzw. sich die Arduino-Zeitrechnung deshalb gedehnt hatte. ("Millis" waren nicht mehr Millisekunden sondern langsamer [oder schneller].)

Beim OutputObject wird Z sehr schnell bewegt. Z hat 2560Steps/mm und XY nur 152. Demnach ist das Runterfahren mit ca. 12mm/s so rechenaufwändig wie 200mm/s auf den Achsen X und Y.

Kannst du testen, ob der Fehler verschwindet, wenn du unter Configuration -> Feedrate -> Z-Achse die Geschwindigkeit auf einen Wert wie 10mm/s senkst?
Ich habe erst in RF.01.38.35.Mod (2018-02-21) diese maximalen Werte angepasst, weil ich auch irgendeinen Reset sah. Bei mir blieb ein OutputObject einfach stehen. Ich schob es erst auf den veränderten Ram den ich nach den Infos von AtlonXP angepasst hatte.
Trotzdem habe ich Octostepping eingeführt und die Grenze auf maximal 12mm/s für Z festgenagelt.
(Hirn denkt nach ... Wenn die Firmware wegen dem Wachdog abstürzt kenne ich das normalerweise daran, dass ich es auf dem Bildschirm sehe und der Drucker einfach neu bootet. Er kann danach eigentlich nur wirren Mist fahren, wenn man die "Verfahrsperre" aufgehoben hat. Ich lasse per USB keine Bewegungen zu, ausser wenn man am Drucker eine Taste gedrückt oder gehomed hat. Sonst sollte er moves ignorieren, was mich in deinem Fall wundert. Oder es ist kein Watchdog-Reset-Crash, sondern ein anderes Problem.)
Edit: OutputObject führt selbst "disable Stepper" aus. Darum frage ich mich auch wo die wirren Bewegungen herkommen. Und natürlich wie die aussehen.

LG

Video!

Link: https://www.youtube.com/watch?v=efdiWs3Yrcg

Wie kann ich die Output-Tiefe anpassen ?

Aha!

Also StopPrint funktioniert in der Version nicht korrekt und irgendwas will nach dem Stop weitermachen. Das Homing ist weg, weil man die Achsen kurz ausschaltet aber dann gehts noch mit ein paar Befehlen weiter. Ich versuche das Problem zu reproduzieren und dann eliminiere ich das.
- Druck per SD.
- Und man sieht, wie langsam das Display bei der "schnellen" Z-Bewegung ist.
- Grund ist vermutlich die Vereinheitlichung des Stop-Print auch für USB.

Danke schonmal!
Die Output-Tiefe ist relativ zum Output-Start-Punkt immer anders. Es gibt den Output_Object_Script_Code dieser wird aber einfach nur durch die Achsenlängen-begrenzt. Die findest du im EEPROM. LG

Ich würde mir wünschen, dann man die Output-Tiefe einstelle kann.
Ich stelle dort dann 80 ein, wenn mein Druck höher ist, fährt der einfach nur raus,
wenn der druck weniger als 80 hoch ist, fährt der Tisch auf 800 runter....

Was denkst du?

Könnte das für mich eine Lösung sein....

#define OUTPUT_OBJECT_SCRIPT_PRINT "G21\nG91\nG1 E-" xstr(SCRIPT_RETRACT_MM) "\nG90\nG1 Z200 F5000\nG1 Y245 F7500"
ändern in:
#define OUTPUT_OBJECT_SCRIPT_PRINT "G21\nG91\nG1 E-" xstr(SCRIPT_RETRACT_MM) "\nG90\nG1 Y245 F7500"

so würde das Druckbett herausfahren ohne Z zu bewegen...

Ich konnte vorher den Fehler nachstellen und habe mich gleich drangemacht. Kannst du für mich auf die 1.38.37 --> https://github.com/Nibbels/Repetier-Firmware wechseln und mir melden, falls der Fehler nochmal auftritt? Nun weiß ich auch von was hille mal gesprochen hatte.

Bei mir ist der Fehler mit der neuen Version nicht mehr aufgetreten!
Erst konnte ich den reproduzieren, dann habe ich geflashed und weder während der Startmade noch direkt beim SD-Druck hatte ich den Fehler mit der 1.38.37.

Korrekt, damit sparst du dir natürlich Z. Aber es ist dann auch kein richtiges Output-Object mehr?
Das Verfahren in Z ist auch nicht mehr das Problem. Durch mein neues Limit mit 12mm/s und dem "Octo-Stepping" passt das inzwischen in der aktuellen Development. Damit jage ich bis zu 8 Steps pro Interrupt an den Stepper raus, das ist effizienter. Das kann deine Version noch nicht Kannst ja vergleichen, wie es nun läuft! (Das war eine Änderung ab RF.01.38.35.Mod)
Ich würde immer das Bett runterfahren, weil es einfach dazugehört.
[Beim RF2000 ist unten ein Endstop, der begrenzt die Fahrt. Beim RF1000 hört der Drucker wohl auf die Achsen-Einstellung.]

LG