search

RF1000community / Repetier-Firmware

Community version of the firmware for the Renkforce RF1000 and RF2000 3D Printers
http://www.rf1000.de
16 stars 12 forks source link

Bugs in aktueller dev-Version (RF1000) #129

Closed mhier closed 6 years ago

mhier commented 6 years ago

In der aktuellen dev-Version gehen bei meinem RF1000 z.Z. folgende Funktionen nicht richtig:

Mein Start-GCode sieht folgendermaßen aus (ich verwende Cura):

; reset origin to (0,0,0)
G28           ; home
G92 X0 Y0 Z0  ; set current position

M109 S260 ; wait for extruder temp to be reached
M190 S110 ; wait for bed temp to be reached

M3005 S6 ; enable debug output

G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0 ; reset extr

M400
M106
M109 S200
M400
G1 F800 E-8
M400
M107
M400

M3900 ; home and find heat bed z offset
M3001 ; Aktivate Z-Compensation
M400

G1 Z5 F1000
M109 S245

G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion

; start line
G92 E0 ; reset extr
G1 X200 Y30 Z0.39 F5000
G1 F800 E6
G1 X20 E20 F500
G1 X25 F1500
G1 Z1 F1000
M400 ; Warten bis Idle

G92 E0 ; reset extr

; correct Y plate offset
G1 X25 Y30
G92 X25 Y10

; Sense offset einschalten
M3909 P4000 S300

Ich beziehe mich auf Repetier-RF1000-community-development-RF.01.39+-70f4da2.hex vom Jenkins. Mit Repetier-RF1000-community-development-RF.01.37x9.Mod-6338bae.hex scheint alles zu funktionieren. Die Versionen dazwischen habe ich nicht getestet.

Nibbels commented 6 years ago

Danke für die Rückmeldung!!

Z-Origin-Scan oder Z-Offset-Scan? Schon der M3900, oder? Kannst du mir sagen, welche Endschalterkombination du drin hast? Oder hast du mir ein Video? Ich vermute, dass SenseOffset nicht funktioniert, weil dein Homing spinnt. Funktioniert das wenn du die Endschalter-Einstellung (Single-Circuit) umschaltest?

LG

mhier commented 6 years ago

Genau M3900 meine ich. Endschalter steht auf "single", weil "circuit" ja generell eher immer Probleme macht. Ein Video kann ich evtl. morgen mal machen, im Moment druckt der Drucker gerade (mit der alten FW) :-)

Hast du evtl. einen Verdacht, wann sich so ein Fehler eingeschlichen haben könnte? Dann kann ich mal entsprechende Zwischenversionen testen.

Nibbels commented 6 years ago

Aktuell wundere ich mich einfach nur, weil ich den Fehler nicht kenne. Dein Startcode ist auch ziemlich lang.

Ich selbst mache den M3900 immer zum korrigieren, wenn ich das Gefühl habe, das Wetter hat meinen Drucker verbogen. Dann speichere ich die Matrix.

Und das ist mein Startcode: ;-------------------------------------- ; Start Code T0-only header ;-------------------------------------- G28 ; home all axes G92 E0 ; Filamentwegreset M3001 ; activate Z-Compensation M3909 ; activate SensiblePressure M3912 S100 P4500 I2 ; Altes Filament und Luft in Duese ausstossen ;-------------------------------------- ; Start Code T0-only header end ;--------------------------------------

Bei Simplify3D fehlen natürlich die Temperaturen.

Edit: Wir haben natürlich mal am Homing gearbeitet, aber ich müsste erstmal recherchieren um überhaupt eine Ahnung zu haben, was da schief laufen könnte. Du hast enorm viele GCodes drin, die ich noch nicht kenne oder deren Sinn ich da nicht ganz klar deuten kann. (ist noch etwas denkarbeit :D )

Nibbels commented 6 years ago

Schwer zu sagen. Ich würde evtl. mal mit der 1.38.10 vortesten. Die könnte grob auf der halben Strecke liegen. So könntest du evtl. einfach mal das Raster verfeinern.

Ich weiß aber auch, dass sowas was völlig billiges sein könnte. Ich habe mal als Check für den maximalen Überfahrweg beim Endschalter -Z_OVERRIDE_MM geschrieben aber der wert war unsigned. (Da hat dann der Cast zwischen Wert und Minus gefehlt?) Das Verhalten in diesem Fall war deinem sehr ähnlich! -> Kein fahren unter 0 möglich, kein vorwärtskommen beim M3900, Offensichtlich defektes SenseOffset weil der Kopf nie unter der Kompensationsgrenze war und die z-CMP schien ausser funktion zu sein.

LG

mhier commented 6 years ago

1.38.10 gibt's irgendwie nicht in Jenkins, hattest du die evtl. nicht einzeln gemerged?

Nibbels commented 6 years ago

Ja stimmt, ich hab meistens auf meinem Account gearbeitet, dass ich niemandem ne halbfertige pre-pre-Version vorsetze. Diese .hex Flashen geht ja schnell und du scheinst genau zu wissen, was du suchst. Wenn du mir einfach sagst, bis wo der Fehler fehlt, kann ich evtl. schon damit arbeiten.

Hast du einen besonderen Schalter drin, nicht oder? Ich habe so ein Lichtlein am Schalter, darum sehe ich direkt ob er gedrückt ist oder nicht - und bei mir klappt das Homing!

(Deinen Startcode muss ich aber noch testen.)

mhier commented 6 years ago

Ok, dann teste ich mal die Versionen schnell durch, sind ja nicht so viele. Ich erstelle dann gleich einen Extra-Post mit den jeweiligen Ergebnissen (den werde ich entsprechend ein paar mal bearbeiten).

Ich habe einen nicht-originalen Schalter drin, das ist richtig. Das ist aber lediglich ein normaler mechanischer Schalter, der nur ein bisschen stabiler ist. Es kann sein, dass der eine größere Hysterese hat, aber an den Werten hast du hoffentlich nicht gedreht?

mhier commented 6 years ago

Hier die Testergebnisse (wird nach und nach erweitert - Update: Jetzt fertig!):

Kommentare während des Testens:

Zusammengefasst:

Nibbels commented 6 years ago

Ich bin gerade etwas unter Zeitdruck, darum leider nur schnelle Antworten: (Und ich war am Schreiben bevor du fertig warst. :D )

Der SenseOffset arbeitet nur, wenn im Mod-Display ^ angezeigt wird, nicht beim @ https://camo.githubusercontent.com/cfe69ecb1968ce471709c134de51bbf58a98330e/68747470733a2f2f646f776e66696768742e64652f70696370726f78792e7068703f75726c3d68747470733a2f2f646f776e66696768742e64652f67726166696b656e2f64696d692f6d6f646d656e75646973706c61795f656e672e706e67 Die Bedingung ist, dass der Kopf in ZHöhe <= MinCompensationSteps arbeitet. Das ist normalerweise 0.33. In neueren Mods werden die Z-Kompensationsgrenzen, (sofern nicht per GCode angepasst) automatisch gesetzt, weil die Lagenhöhe und auch die Welligkeit der Matrix bekannt sind und wir pro Lage nicht mehr als 5% kompensieren wollen. -> Was ich eigentlich sagen will: Prüfe bitte im Display, ob ^ aktiv ist, wenn du SenseOffset testest.

Beim M3900 machen wir ja generell ein Homing.

Den M3900 haben wir mal angepasst, weil er immer nur Step-Vielfache von 255 produziert hatte und wir für PeterKA's Z-Problem irgendeinen Fehler gesucht hatten. Ich habe dann versucht die Schritt-Intervalle zu optimieren. Dann waren wir bei einer Wiederholbarkeit von sehr wenigen Steps in Z. Es ist allerdings immernoch ein Problem, dass unterschiedliche Scanpunkte unterschiedliche Ergebnisse liefern - diese aber nun ziemlich genau.

Wir haben mal die Homing-Direction optimiert und diese ganzen verstreuten Funktionen vereinheitlicht. https://github.com/RF1000community/Repetier-Firmware/blob/70f4da28a73fac7fa9ed7fc0606a09eeb1c16216/Repetier/Printer.cpp#L1802 https://github.com/RF1000community/Repetier-Firmware/blob/70f4da28a73fac7fa9ed7fc0606a09eeb1c16216/Repetier/Printer.cpp#L1383

Wenn man eine Schalterhysterese ausmessen will, kann man FEATURE_CHECK_HOME nutzen, in der configuration.h ganz unten. Das schaltet einen MCode frei, der nach verfahren der Position eine Homing-Prüfung macht und die Schalterhysterese mit ausgibt. (Weg von Drücken bis Loslassen beim Zurückfahren nach dem Antippen des Schalters) Das ist die Einstellung, dass die Firmware wirklich überall weiß, wie weit ein Z-Schalter überfahren werden darf: Z_ENDSTOP_DRIVE_OVER https://github.com/RF1000community/Repetier-Firmware/blob/community_development/Repetier/RF1000.h#L633

RF1000: 0.8mm RF2000: 1.3mm

Hier sehen wir den Backmove: https://github.com/RF1000community/Repetier-Firmware/blob/70f4da28a73fac7fa9ed7fc0606a09eeb1c16216/Repetier/RF1000.h#L689 Das ist 0.3 plus diese Stecke Z_ENDSTOP_DRIVE_OVER

Ein Homing fährt nun generell schrittweise runter, wenn der Schalter noch gedrückt ist. Es prüft zwischen den Schritten den Schalterstatus und sollte in jedem Fall aus dem gedrückten Zustand rausfahren. https://github.com/RF1000community/Repetier-Firmware/blob/70f4da28a73fac7fa9ed7fc0606a09eeb1c16216/Repetier/Printer.cpp#L1846

###########

Jetzt:

Da hat gerade was geupdated und ich lese nochmal oben.

Dass der Scan vorsichtiger ist, mag sein. Ich müsste mir das nochmal anschauen, zumindest für den sauberen Scan ohne Filament war das besser. Der fährt am Ende nur noch minimal hoch und runter um die Position zu verifizieren. Probleme hatte ich, wenn die Digits selbst weglaufen.

Das Geheimnis oder die optimierung steckt in den Schrittweiten und Limits.

Das mit dem G92 schaue ich mir genau an!

Nibbels commented 6 years ago

Dazu:

Homen der Z-Achse über G28 (ohne irgendwelche Parameter) funktioniert nicht richtig, das "retry" findet nicht statt. Er fährt zwar nach dem Auslösen des Endschalters wieder ein Stück zurück, bleib dann dort aber stehen.

Korrekt ist, dass für den Fall, dass deine Matrix positiv ist, also positive Einträge hat, der höchste Punkt als automatisches Z-Offset verwendet wird, wenn du gehomed hast. Das macht der Mod noch nicht so lange. Das ist seit V RF.01.38.09.Mod (2018-01-04) so. Was steht bei dir in der Matrix?

Wir haben quasi immer eine Z-Kompensation, aber sie kompensiert ohne M3001 keine Welligkeit, sondern hebt nur die Düse auf den höchsten Punkt der Z-Matrix, sodass die Düse über dem Bett ist, auch wenn die Z-Schraube falsch ist.

Ich bin nun wieder da und kann mal richtig testen.

mhier commented 6 years ago

Die Matrix ist bei mir ziemlich sicher nicht positiv. Mein Bett ist relativ schief, so dass es vorne links am höchsten ist. Ich stelle beim Scannen dort den Abstand immer so ein (über die Schraube), dass die Düse ca. 0.1mm vom Bett weg ist. Dann ist sie überall sonst eher weiter weg vom Bett, sicher nirgends weniger als 0.

Vielleicht ist der Scan jetzt einfach zu vorsichtig für den Scan mit eingelegtem Filament. Ich bekomme zumindest bei ABS zwar die Düse immer ziemlich sauber, aber nie wirklich 100% natürlich. Es scheint mir tatsächlich so zu sein, dass der Scan den ersten Kontakt des an der Düse klebenden Materials mit dem Bett schon als Kontakt interpretiert, nicht erst den Kontakt der Düse selbst mt dem Bett. Das war früher anders. So ist der Scan jetzt für mich nicht mehr geeignet... Vielleicht kann man da zwei Betriebsmodi draus machen, einer für ohne Material und einer für mit?

Bzgl. dem Problem mit dem Homing: Anscheinend passiert das auch bei der älteren Version gelegentlich. Evtl. ist das also kein neues Problem, sondern taucht bei mir erst seit kurzem auf, seitdem ich den Start-Code kürzlich überarbeitet habe. Vielleicht muss ich auch nur ein M400 dazwischen setzen (wobei das ja eigentlich nicht so sein sollte). Probiere ich demnächst mal aus.

Ich kann gerade nicht sagen, ob beim Sense-Offset ein @ oder ein ^ im Display stand, da habe ich ehrlich gesagt nicht drauf geachtet. Probiere ich bei Gelegenheit noch mal aus.

Nibbels commented 6 years ago

Ich halte das mit dem Scan nicht für unmachbar. Vermutlich müssten wir jetzt nur noch mit den Anpress-Drücken spielen. https://github.com/RF1000community/Repetier-Firmware/blob/70f4da28a73fac7fa9ed7fc0606a09eeb1c16216/Repetier/RF1000.h#L1075 ff

#define SEARCH_HEAT_BED_OFFSET_CONTACT_PRESSURE_DELTA   40                                                                  // [digits]
#define SEARCH_HEAT_BED_OFFSET_RETRY_PRESSURE_DELTA     30                                                                  // [digits]
#define SEARCH_HEAT_BED_OFFSET_IDLE_PRESSURE_DELTA      0                                                                   // [digits]

Bei mir ist der Drucker gerade noch am Testdrucken einer neuen Alpha. Ich habe in den letzten Tagen die Microsteps der Achsen aufgetrennt und alle statischen Steps/MM rausgeschmissen. Wenn dieser kleine GCode durchgelaufen ist, mache ich deinen Startcode vornedran und vergleiche.

Tritt der Fehler dann auf, kann ich suchen. Bisher habe ich am RF2000 leider keinen synthetischen Schnelltest dazu überreden können mir irgendeinen Fehler zu zeigen.

LG

Nibbels commented 6 years ago

Hmm, du machst auf M109 S260 dann auf M109 S200 dann M3900 und dann M109 S245

Ist das Material evtl. bei 200°C etwas zu fest, wenn es anschließend bei 245 gedruckt wird? Da könnte doch jeder Popel den Abstand erhöhen?

Nibbels commented 6 years ago

hasi_ei_gcode.zip

Ich habe nun 2x dieses Teil für 215°C/60°C 0.25er Düse PLA gedruckt und keine Probleme feststellen können.

Diese ganzen M400 sollten eigentlich nicht nötig sein. Temperaturänderungen mit Warten haben den sowieso meist drin. Die meisten Bewegungen warten bis sie beendet sind. Z-Compensation und SenseOffset werden sauber in die Warteschleife gelegt. (...)

Ich weiß aktuell noch nicht, was der Fehler sein könnte.

Nibbels commented 6 years ago

Am Ende von jedem Homing zeigt der Drucker Commands::printCurrentPosition(); Das müsste in der Log auftauchen. Tuts das? Wenn ja, welche Koordinaten schmeißt er raus, wenn er nicht korrekt gehomed hat?

Ist der Motorstrom hoch genug? Sind die Z-Spindeln verspannt? Steht der Drucker enorm kalt, sodass das Fett klebriger ist als sonst?

Um den Schalter zu prüfen, könntest du testweise

define FEATURE_CHECK_HOME 1

aktivieren. Und dann nach Verfahren durch Position oder ähnlich mit dem GCode M3028 X1 Y1 Z1 die Achsen auf Hysterese, verlorene Steps und Schalterwiederholbarkeit prüfen. Ich glaube in deinem Fall fast nicht dran. Nur als Side-Info.

LG

mhier commented 6 years ago

Bzgl. dem Homing: Das ist ziemlich sicher kein mechanisches Problem, allein vom Timing her (er probiert gar nicht erst wieder in die andere Richtung zu fahren). Meine Vermutung ist, dass G92 direkt hinter G28 sich nicht verträgt. Vielleicht packe ich mal ein M400 dazwischen testweise.

Bzgl. dem Z-Offset-Scan: Ich möchte eigentlich nicht bei jedem Firmware-Update alle meine mühsam ausklamüserten Einstellungen neu überdenken müssen. So etwas sollte nach Möglichkeit langfristig stabil bleiben. Ich denke, es spricht nichts dagegen, die Schrittweite zu reduzieren, das dürfte nicht das Problem sein. Meine Beobachtung ist aber eher, dass der Scan sich generell seltsam verhält. Er bleibt z.B. zwischendurch mehrere Sekunden stehen, ohne sich überhaupt zu bewegen (das würde man ja hören, außerdem habe ich Makierungen auf die Achse der Z-Spindel gemalt). Was macht das für einen Sinn? Ist das überhaupt Absicht?

Wenn ich die Temperatur beim Scan größer einstelle, bekomme ich Probleme mit der Dauerdruckplatte. Das Material ist dann nämlich sehr klebrig (und es ist auch deutlich mehr davon vorhanden wegen Oozing) und die Platte wird beim wieder Wegfahren vom Bett abgehoben. Das verwirrt den Scan komplett. Druckunterschiede werden ja leider i.d.R. als Absolutwerte betrachtet, die dann vergleichsweise große negative Kraft ist für den Scan gleichbedeutend mit einer starken Kontaktkraft, obwohl er sich dann sogar 0.5mm vom Bett entfernt befinden kann. Das Ergebnis ist dann ein viel zu großer Abstand zum Bett.

Hast du die Anpressdrücke denn geändert? Kannst du sie ggf. einfach wieder auf die alten Werte zurückstellen? Meiner Erfahrung nach ist ein zu vorsichtiger Scan nur kontraproduktiv. Er mag in "Einzelfällen" (sprich bestimmte Drucker-Exemplare mit einem bestimmten Nutzungsschema) funktionieren und dann auch (scheinbar) reproduzierbar, aber das hilft der breiten Masse nicht. Im Endeffekt kommt es nicht auf wenige Steps Genauigkeit bei diesem Scan an, viel wichtiger ist, dass er ausreichend genau unter möglichst allen Lebenslagen funktioniert. Für mich sah das zum Schluss so aus, als hätten wir das erreicht...

Nibbels commented 6 years ago

Hab mal den Thread "halbiert". Das SenseOffset wird vermutlich funktionieren wenn das mit dem Homing ausgeräumt ist. (?)

mhier commented 6 years ago

Naja, das Homing wurde ja danach korrekt mit dem Z-Offset-Scan ausgeführt. Der Drucker ist also korrekt gehomed...

Danke für's Aufteilen!

Nibbels commented 6 years ago

Also! Es hat etwas gedauert, bis es geklickt hat, aber nun mal ne kleine Zusammenfassung, die nirgends so wirklich genau ins Thema reingehört.

Ich kanns nicht genau deinen Beschreibungen zuordnen, aber wenn eine Bewegung da war und dann moveZ verwendet wurde :

Nebensächliches:

:)

mhier commented 6 years ago

Ich kann nicht ganz folgen, ich bin glaube ich zu wenig in der Firmware drin... Sind die Änderungen, von denen du gerade sprichst, schon hier in der community_development Version enthalten?

Nibbels commented 6 years ago

Dass du nicht ganz folgen kannst ist fast logisch. :D Ich konnte mir erst auch nicht ganz folgen ^^ und bin seit nem Jahr eingearbeitet.

Kurz umrissen: Der Drucker bewegt die Achsen mit folgenden möglichen Systemen:

Alle müssen genau zusammenarbeiten und haben unterschiedliche priorität. Die Zcompensation muss eigentlich immer ihrer Zielvorgabe nachtickern, Dafür muss aber sichergestellt werden, dass die Achse in der Z-CMP-Richtung steht oder diese Achse nach einer anderen Z-Bewegung korrekt freigelassen wird. Das war beim Modus "moveZ" der für alle Scan-Tätigkeiten zuständig ist nicht so. Ausserdem hätte die Z-Kompensation vor dem MoveZ grundsätzlich gegen 0 streben müssen.

schon hier in der community_development Version enthalten?

Das schiebe ich alles rüber in die community_development, wenn ich das nochmal überdacht und getestet habe. Mir sind gestern einige Lichtlein aufgegangen, weil mir ein weiterer Zusammenhang klar wurde. Jetzt überlege ich ob ich die Funktionalität flicke oder das Z-Schraube-Zu-Tief-Spacing (pos. Z-Matrix) raus lasse.

Gestern wars mir zu spät um diese Merge-Entscheidung zu treffen. Ich lese heute nochmal alles durch und überlege welche Fallstricke verbleiben, dann schiebe ich alles rüber und wir haben eine 1.41.mod 📦

LG

Nibbels commented 6 years ago

Wenn ich das richtig verstehe ist hier der Bug mit dem Z-Offsetscan noch offen: -> https://github.com/RF1000community/Repetier-Firmware/issues/132

Ich werde demnächst wohl die EEPROM-Version auf sowas wie "41" stellen, sodass der Drucker die Feedrates die früher mal eingestellt waren verwirft und aktualisiert. Ist das einge gute Idee?

Und die anderen zwei Bugs dürften erklärt oder auch behoben sein? Sollen wir hier schließen?

mhier commented 6 years ago

Ich komme mit dem Testen nicht hinterher und habe die Übersicht verloren, was jetzt tatsächlich gelöst ist... Mach erstmal, wie du denkst. Der Nachteil ist natürlich, dass alle anderen Einstellungen mit verloren gehen. Ich habe z.B. wegen meiner Dauerdruckplatte die Beschleunigungen reduziert, damit die nicht verrutscht (ist ja nur festgeklemmt).

Nibbels commented 6 years ago

Hm, das mit den verlorenen Settings stimmt schon, ich habe bisher auf eine andere EEPROM-Version verzichtet. (Evtl. reicht hier auch beim Einlesen ein if EEPROM > CONFIG-MAX -> update eeprom to max. So habe ich ähnliche Fälle bisher gelöst. Und hier ist dieses Limit tatsächlich sinnvoll und es hilft nur, schränkt aber niemanden wirklich ein.)

Mach dir keinen Stress wegen dem Testen! Ich weiß sehr wohl, dass es wichtigeres gibt. Und verbessert ist der Scan nun schon. Ich bin inzwischen auch wieder mit Silikonfugen ausbessern im Bad beschäftigt. Als Testobjekte drucke ich gerade neue Wandhalter für die Brausestange aus ASA.

Ich habe in den letzten Tagen quasi nur noch Code aufgehübscht, doppelt programmierte Codeblöcke aufgelöst und kleine Bugs gesucht. :D :D RF1000 bekam wieder ne ganze Liste an PNs. (Waren aber nur Kleinkram-Bugs die wohl kaum jemand betreffen hätten können.)

Ich komme mit dem Testen nicht hinterher und habe die Übersicht verloren, was jetzt tatsächlich gelöst ist...

  • Das Homing hast du gelöst. (?) -> Ausstehend Sicherheitsprüfung der EEPROM-Werte.
  • Ein größerer Bug, der den Scan stören (+ Random Offset bei positiver Matrix) hätte können ist gelöst.
  • Diese Kommunikationsfehler treten mit maximal 1280 Steps/mm in der E-Achse bei mir nicht mehr auf.
  • Der Z-Offset-Scan ist nun schneller. Man kann nun auch "Iterations" = 1 einstellen und es ist Standard 1. -> Das heißt aber nicht, dass er nur einmal anfährt. Er übertreibt nur beim Messen nach dem erkennen der groben Betthöhe nicht mehr so extrem mit dem Feinstanfahren.
  • SenseOffset müsste funktionieren, wenn alles andere funktioniert. (?)
  • (Load Filament / Unload Filament ist nun besser. Es hatte bisher ein G92 E0 gefehlt -> Ich habe aber die Funktionen durch was intelligenteres ersetzt.)

LG

Nibbels commented 6 years ago

Dieses 3xIssue scheint mir "erledigt" zu sein.

Z-Offset-Scan und SenseOffset müssten passen. G28 ist auch durch die angepassten Geschwindigkeiten immernoch ok?

Die Firmware nimmt nun automatisch die Geschwindigkeit runter.