Das klingt ziemlich vielversprechend. Ich schaue mir das mal bei Gelegenheit an. Eine Frage habe ich zu deinem Pull-Request auf github: Hast du die Änderungen alle identisch in beiden Verzeichnissen (RF1000 und RF2000) vorgenommen? Ich würde vorschlagen, nur eines der beiden Verzeichnisse zur Entwicklung zu verwenden, da der Unterschied eh nur in der Konfiguration liegt. Letzlich ist das Repository, so wie es von der Struktur her ist, nicht gut zur Entwicklung geeignet und gedacht (hatte ich schon mal angemerkt, aber Conrad scheint nicht so ein richtiges Interesse an Community-Entwicklungen zu haben )...

Ich habe in einem ersten Schritt die Änderungen im RF1000 auf den RF2000 übernommen.
Das war im ersten Anlauf absolut Laienhaft.
Im zweiten Anlauf zumindest so übersichtlich gelungen, dass ich mich getraut hatte, das auf den Drucker zu spielen.
Da wusste ich schon ungefähr, was wo hin muss.

Changelog:
###############
Übernahme von RF1000 -> RF2000:

Unterschiede bei den Druckern gibts in:
RF2000/Repetier/Configuration.h
RF2000/Repetier/RF2000.h
(In diese zwei Dateien -musste- ich die Änderungen manuell hinüberschieben.)

Bei anderen Dateien habe ich das versucht, aber dann meist drüberkopiert.

RF2000/Repetier/uilang.h -> nur +scan aborted
RF2000/Repetier/Constants.h -> nur 1.33+mod
RF2000/Repetier/RF.h -> mehrmals +, bool execRunStandardTasks=true

Code des Mods:

RF2000/Repetier/RF.cpp

Änderungen von mir:

RF2000/Repetier/Commands.cpp -> M116-Bugfix: TEMP_TOLERANCE statt 1°K (1 Zeile geändert)
RF2000/Repetier/RF.cpp -> Neue Befehle, neue Funktion, Änderung deiner Z-Offset-Scan-Funktion. (Original nicht gesichert, nur umgeschrieben + Fix für das fehlende Y-Offset der Matrix-Scanpunkte)

Portierung zurück zum RF1000:

RF1000/Repetier/Commands.cpp -> M116-Bugfix: TEMP_TOLERANCE statt 1°K (1 Zeile geändert)
RF1000/Repetier/RF.cpp -> zurückkopiert.

Nebensächliche Änderungen:
README.md
changelog.txt

Neue Datei: StartCode for RF2000 ExtruderRightOnlyT1.txt
########

Ganz grob gesagt, würde man bei zukünftigen Änderungen nur noch in RF.cpp ändern, nehme ich an. Und die kann man, da bin ich mir ziemlich sicher, generell hin und herkopieren.

Man könnte bestimmt die Drucker in einen Ordner RFx000 zusammenlegen, wenn man es schafft, irgendwie die Configuration.h zu ändern.
Was ich dort (Configuration.h) bisher noch nicht nicht übernommen hatte, waren:
RF1000#define SHOW_DEBUGGING_MENU 1 // 1 = show, 0 = hide
RF2000#define SHOW_DEBUGGING_MENU 0

RF1000#define Z_OVERRIDE_MAX (ZAXIS_STEPS_PER_MM * 1)
RF2000#define Z_OVERRIDE_MAX (ZAXIS_STEPS_PER_MM / 2)

RF1000#define DEBUG_HEAT_BED_SCAN 2 // 0 = off, 1 = on, 2 = on with more debug outputs
RF2000#define DEBUG_HEAT_BED_SCAN 0

RF1000#define DEBUG_SHOW_DEVELOPMENT_LOGS 1 // 1 = on, 0 = off
RF2000#define DEBUG_SHOW_DEVELOPMENT_LOGS 0

Und das absolut wichtige:
RF1000#define MOTHERBOARD DEVICE_TYPE_RF1000
RF2000#define MOTHERBOARD DEVICE_TYPE_RF2000

Ich glaube, dass der einzige Unterschied, der verhindert, dass man rein in einem Ordner entwickelt MOTHERBOARD ist. (RF1000.h und RF2000.h sind ja schon getrennt)

LG

Diese Scanvariante läuft bei mir übrigends inzwischen sehr sehr gut.

Ich habe mir G-Codes für:
"HBS Kalibrierung T1 rechts ABS"
"HBS Kalibrierung T0 links ABS"
Im Repetierserver hinterlegt und wenn ich den Drucker kaltstarte, lasse ich das laufen. Dann wärmt er sich ~ 10 Minuten vor und scannt währenddessen das Bett.

Ich glaube eigentlich auch, dass mit deinem Scan schon alles mehr als zufriedenstellend funktionieren würde. Mein Fehler, den ich tagelang verzweifelt gesucht habe und weshalb ich die Firmware geändert habe, war, dass ich ein G28 Homing nach aktiveren des Z-Scans M3001 im kürzlich veränderten Startcode hatte. Also war der Z-Scan sofort wieder aus und ich hab mich ständig nur gewundert, warum der Druck so scheiße wird.

Trotzdem gefällt mir diese neue absolute Kontrolle über meine zMatrix. Ich spare mir beim RF2000 dieses nervige schrauben. Wenn man beim RF2000 einen neuen HBS machen muss, sollte man die Extruder lockern und einen hochhängen.

Jetzt ist mir sonnenklar:
Steht da Z:0.89 CMP -> Z-Compensation ist an
Steht da Z:0.89 -> Z-Compensation ist aus


LG

Danke für die Beschreibungen, ich schaue mir das am Wochenende mal an.

Nibbels hat geschrieben:Im Repetierserver hinterlegt und wenn ich den Drucker kaltstarte, lasse ich das laufen. Dann wärmt er sich ~ 10 Minuten vor und scannt währenddessen das Bett.

Das verstehe ich nicht ganz. Die Idee des Mods ist, nach dem Aufwärmen zu scannen.

Genau, aber ich denke, man muss mit ner Formel wie

Z-Matrix = Z-Matrix + Lernrate*( Offset*Gewichtungsfaktor*Gewichtung(x,y) + Offset*(1-Gewichtungsfaktor) )

Lernrate = {0.00 .. 0.99}
Gewichtungsfaktor = {0.00 .. 1.00}
Gewichtung(x,y) ist Abhängig von der normierten Bettgröße je nach Abstand zum Messpunkt = {1.00 .. 0.00} , 1.00 am Scanpunkt

nicht warten, bis alles 100% eingependelt ist, sondern man scant eben nach.
Ich mach das aktuell folgendermaßen:

- Bett aufheizen ohne warten.
- Extruder 150°C heizen/kühlen
- Warten bis alle Temperaturen stimmen
- Retract 10mm
- Extruder auf Drucktemperatur heizen
- 1x um die Bettmitte scannen
- 2x um die Bettmitte nachscannen (Gewichtungsfaktor = 50% - 90%)
- 4x an jeder Ecke scannen (Abstandsgewichtet, Gewichtungsfaktor = 90%)
- Startmade drucken
- Ende

Wenn ich das in Zahlen ausdrücken wollte, sieht das beispielhaft so aus:
Scan 1: Offset -200 -> effektiv Z-Matrix = EEPROM-Z-Matrix -200
Scan 2: Offset +23 -> effektiv +16
Scan 3: Offset -5 -> effektiv -4
Scan 4: Eckoffset 12 -> effektiv {Ecke+10 bis Gegenüber+0}
Scan 5: Eckoffset -23 -> effektiv {Ecke-20 bis Gegenüber+0}
Scan 6: Eckoffset 23 -> effektiv {Ecke+20 bis Gegenüber+0}
Scan 7: Eckoffset 10 -> effektiv {Ecke+9 bis Gegenüber+0}
(Das ist aber nur ein erdachtes Zahlen-Beispiel, nicht eine echte Messung und über die Vorzeichendefinition könne man sich streiten.)

Der Retract und die mehreren Scans lösen für mich das Filament-Oozing-Problem an den Scanpunkten. Man sieht Anfangs noch eine Druckstelle mit Restfilament von der Düse und bei den nächsten Scans fehlt diese fast.
Das Programm dauert schon seine Zeit und man könnte das Bett auch ganz am Anfang auf +10°K aufheizen und während der additiven Scans um -10°K kühlen lassen. Dann ist die Temperatur schneller verteilt.

Nach diesem Ablauf konnte ich bisher direkt (fehlerfrei) losdrucken. (ABER: Meine Testteile waren klein, die erste Lage ist schnell gedruckt.)
Zwischen dem Start von Teil 1 und Teil 2 ändert sich meist was (ausser ich habe diesen Eindruck aus anderen Gründen).
-> Wenn ich ein Teil gedruckt habe, scanne ich nochmal, vermutlich weil sich das V2-Hotend nachlängt. AtlonXP sprach da glaub mal von bis zu 0,1. Das Ergebnis ist ohne Nachscan zwar manchmal ok, aber ich habe das Gefühl gewonnen, dass nachmessen besser ist. (U.u. reichen weniger Scans)

Aber eins ist klar, ich kann so ein Verhalten unmöglich alleine prüfen und verifizieren
Da wären Zweit und Drittmeinungen interessant.

LG

Hm, also ich heize in der Regel 10 bis 20 Minuten vor, dann längt sich nichts mehr nach. Bei mir hat bisher ein Messpunkt genügt, allerdings habe ich auch eher kleine Teile gedruckt. Wenn sich das ganze Heizbett verschoben/verkippt hat, hilft doch immer noch ein voller HBS am besten. Ich halte das für übertrieben.

Sicher bin ich mir bei diesem Rezept noch nicht, ich lasse mich gerne umstimmen!
Das mit den 10 - 20 Minuten vorheizen, ist sicher nicht schlecht - ich suche auch nur einen funktionierenden und ziemlich gesicherten Prozess.
Es wäre auch kaum eine Änderung, wenn man solche Scans nach dem langen Vorheizen macht.

Durch diese zahllosen Abstands-Tests und der neuen Anleitung ist mir viel klarer geworden, wie das mit dem HBS in Kombination mit den zwei Extrudern ordentlich funktioniert. HBS war bisher ziemlich kacke, weil ich, wie schon geschrieben, ein Loch in der Keramik (an einem HBS-Punkt) habe. Lineare interpolation hätte also zu Düsenkontakt geführt.

Aber da ich nun alle Möglichkeiten offen habe, ...
Testen, testen, testen.

LG

Nibbels hat geschrieben:HBS war bisher ziemlich kacke, weil ich, wie schon geschrieben, ein Loch in der Keramik (an einem HBS-Punkt) habe. Lineare interpolation hätte also zu Düsenkontakt geführt.

Ich denke, solche Hardware-Probleme sollte man anders lösen. Das Loch wird doch ohnehin verhindern, dass du an der Position vernünftig drucken kannst.

Was zwei Extruder angeht, kann ich nicht mitreden. Vielleicht rüste ich irgendwann mal auf, aber erstmal steht für mich ein Umbau auf den E3Dv6 an Ich müsste nur mal die Zeit dafür finden...

Nibbels,

Nibbels hat geschrieben:... HBS war bisher ziemlich kacke, weil ich, wie schon geschrieben, ein Loch in der Keramik (an einem HBS-Punkt) habe. Lineare interpolation hätte also zu Düsenkontakt geführt....

Schon einmal daran gedacht, die Heizmatte vorsichtig zu lösen und die Keramikplatte um 180° zu verdrehen? Damit wäre das Loch vielleicht nicht mehr an einem HBS-Matrixpunkt.
Um das schnell einmal zu testen müsstest du nur mit der Düse zum Punkt fahren. Das Bett senken, die Heizung und den Sensor abstecken, das Bett um 180° drehen, hochfahren und gucken. Genau weiß man es nicht, man kann es aber am X- und Y-Abstand abschätzen, ob der Punkt wieder mit einen HBS-Punkt zusammenfällt.

mjh11

Hallo,


die Punkte, an denen der HBS abtastet kann man quasi beliebig einstellen. Siehe die M-Codes M3020 ... M3025.

Alternativ kann man auch direkt in RF1000.h bzw. RF2000.h die folgenden #defines anpassen:

- HEAT_BED_SCAN_X_START_MM
- HEAT_BED_SCAN_X_END_MM
- HEAT_BED_SCAN_X_STEP_SIZE_MM
- HEAT_BED_SCAN_Y_START_MM
- HEAT_BED_SCAN_Y_END_MM
- HEAT_BED_SCAN_Y_STEP_SIZE_MM

Mit beiden Methoden kann man das gleiche Ergebnis erreichen und es sollte somit recht einfach möglich sein die Positionen der Abtastpunkte so einzustellen, dass ein potentiell vorhandenes Loch in der Druckplatte nicht vom Scan erfasst wird.


mfG
RF1000