Bugs in aktueller dev-Version (RF1000)

[mhier]

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

• 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.
• Der Z-Origin-Scan ist unzuverlässig und bleibt zu weit vor dem Heizbett stehen (anschließend keine Haftung beim Druck)
• Der Sense Offset tut nichts

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]

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]

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]

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]

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]

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

[Nibbels]

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]

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]

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

• Repetier-RF1000-community-development-RF.01.39+-70f4da2.hex [FAIL]
• Repetier-RF1000-community-development-RF.01.38.35-c112007.hex [G28 OK, M3900 FAIL, M3909 FAIL]
• Repetier-RF1000-community-development-RF.01.38.18-96957e1.hex [G28 OK, M3900 FAIL, M3909 FAIL]
• Repetier-RF1000-community-development-RF.01.38.01.Mod-882fed8.hex [G28 OK, M3900 FAIL, M3909 OK]
• Repetier-RF1000-community-development-RF.01.37x9.Mod-6338bae.hex [OK]

Kommentare während des Testens:

• Vielleicht funktioniert der Sense-Offset auch deswegen nicht korrekt, weil M3900 nicht funktioniert und ich dann manuell eingreifen muss?
• Wenn das Homing in G28 schief ging, hat übrigens hinterher das Homing in M3900 trotzdem funktioniert!
• M3900 scheint sozusagen zu vorsichtig zu sein. Bei der funktionierenden Version hat er, wenn er einen Kontakt vermutet hat, ein paar mal das Bett leicht rauf und runter gefahren und den Kontakt damit verifiziert. Jetzt bleibt er stattdessen einfach stehen. Die Position, die er jetzt misst, ist gar nicht mal so unreproduzierbar, aber eben leider cam 0.1mm zu weit vom Bett entfernt. Wenn man flach über das Bett peilt, sieht man tatsächlich noch eine kleine Lücke. Der Wert schwankt außerdem auch deutlich stärker als früher. Manchmal ist er sogar nah genug am alten Wert, dass der Druck funktioniert. Ich kann nicht 100%ig sagen, ob zwischen den Versionen da vielleicht auch noch unterschiede liegen. Mein "FAIL" bezieht sich jetzt erstmal auf das geänderte Scan-Verhalten (jetzt vorsichtig und unzuverlässig gegenüber früher etwas aggressiver und damit zuverlässiger).

Zusammengefasst:

• Der Z-Offset-Scan via M3900 scheint also sein Verhalten zwischen RF.01.37x9 und RF.01.38.01 geändert haben. Hast du da absichtliche Änderungen vorgenommen? War das alte Verhalten zu aggressiv? Ich fand es sehr zuverlässig.
• Der Sense-Offset scheint zwischen RF.01.38.01.Mod und RF.01.38.18 kaputt gegangen zu sein, es sei denn, manuelle Korrektur des Z-Abstands beeinflusst die Funktion. Beim Test mit 01.38.01 hat der Z-Offset-Scan (zufällig?) ein brauchbares Ergebnis geliefert und ich musste nicht eingreifen. Bei 01.38.18 war dies nicht der Fall und ich musste den Abstand manuell verringern (sonst wäre ich auch nie an die Digit-Schwelle vom Sense-Offset gekommen).
• Das Homing via G28 scheint irgendwo später kauptt gegangen zu sein, ich habe das jetzt aber nicht weiter eingegrenzt. Meine Vermutung ist, dass das Problem nur im Zusammenhang mit einem anschließenden G92 auftritt. Ich brauche diese Kombination, weil ich später mit G92 einen Offset in Y einführen will, damit der Origin vorne links auf dem Bett liegt (und nicht 2cm davor). Diesen Offset muss ich am Anfang ggf löschen, sonst addiert er sich bei aufeinanderfolgenden Druckaufträgen ohne Neustart des Druckers.

[Nibbels]

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.

• Nur manchmal braucht der Scan etwas länger.
• Ich fahre auch wenn ich eine Kraft aufgebaut habe zurück, bis diese wieder fehlt.
• Es werden einige Fehler untersucht und abgefangen, die früher zum Abbruch führen konnten(?)

Wir haben mal die Homing-Direction optimiert und diese ganzen verstreuten Funktionen vereinheitlicht.

Repetier-Firmware/Repetier/Printer.cpp

Line 1802 in 70f4da2

char nHomeDir = Printer::anyHomeDir(Z_AXIS);

Repetier-Firmware/Repetier/Printer.cpp

Line 1383 in 70f4da2

int8_t Printer::anyHomeDir(uint8_t axis){

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:

Repetier-Firmware/Repetier/RF1000.h

Line 689 in 70f4da2

#define ENDSTOP_Z_BACK_MOVE float(0.3f+Z_ENDSTOP_DRIVE_OVER) //0.3mm sind theoretische maximale hysterese beim Schalter loslassen. Original RF1000: 0.01

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.

Repetier-Firmware/Repetier/Printer.cpp

Line 1846 in 70f4da2

for(uint16_t step = 0; step < axisStepsPerMM[Z_AXIS] * ENDSTOP_Z_BACK_MOVE; step += 0.1f * axisStepsPerMM[Z_AXIS]){

###########

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]

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]

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]

Ich halte das mit dem Scan nicht für unmachbar.
Vermutlich müssten wir jetzt nur noch mit den Anpress-Drücken spielen.

Repetier-Firmware/Repetier/RF1000.h

Line 1075 in 70f4da2

#define SEARCH_HEAT_BED_OFFSET_CONTACT_PRESSURE_DELTA 40 // [digits]

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]

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]

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.

• 1x Mein Startcode
• 1x Dein Startcode

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]

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]

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]

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

[mhier]

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]

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 :

• Dann konnte es anschließend sein, dass die Z-Kompensation gehangen hat, weil die Stepper-Richtung gegenläufig zur Kompensation sein kann. (Das ist u.U. dann ein Problem, wenn gerade sonst keine Bewegungen laufen, die diesen Zustand korrigieren hätten können.)
• Und diese Regel, dass eine positive Matrix ein Sicherheits-Offset produziert, wenn gehomed ist ist rausgeflogen.
  Denn das hätte ich überall abfangen müssen, wo man was in Z misst. Es mag sein, dass das unter Umständen bei mehren Z-Scans mit Popel reingefunkt hatte.
• Ich konnte einen Zustand erzeugen, da blieb mir eine Funktion einfach hängen, die nur hätte homen sollen. Weil die Z-CMP gehangen hat und weil dann "waitUntilEndOfAllMoves" auf die zCMP warten wollte. waitUntilEndOfAllMoves prüft nun immer auf diesen Zustand und ignoriert ihn notfalls. (Wenns auch nicht mehr vorkommen dürfte.)
• moveZ, gibt nun immer den Stepper wieder frei, also macht die Stepperdirection = 0.

Nebensächliches:

• beim y-homing wird nun auch ENDSTOP_Y_RETEST_REDUCTION_FACTOR und nicht mehr ENDSTOP_X_RETEST_REDUCTION_FACTOR verwendet. Auch wenns eigentlich egal war. (->RF1000 per PN)
• wir können nun hinschreiben, dass wir Repetier Protocol-Version 3 unterstützen. Wenn auch (noch) nicht nutzen.

:)

[mhier]

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]

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:

• zcompensation (Z verfahren, wenn die Achse zufällig in der Wunschrichtung steht.)
• directSteps
• queueMove
• directMove (Zielkoordinate hinterhertickern, wenn sonst nichts läuft. -> z.B. Extrusion über Knöpfe)
• moveZ

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]

Wenn ich das richtig verstehe ist hier der Bug mit dem Z-Offsetscan noch offen:
-> #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]

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]

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]

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.