Core XY - one axis is always wrong
Hello, I am trying to install the Repetier FW on my CORE XY.
previously was for years Marlin on the printer, but since I also change to TCM drivers I have to I anyway to the FW.
at the moment the old drivers are still on it to not have all the problems at the same time.
For hours I plague with the problem that always runs at least axis Wrong around.
Example X is correct, but Y drives during homing in the wrong direction.
If I change the direction of Y
I trigger a homeing of Y drives the X axis brotal in front of the frame because of course the limit switch of Y can not trigger.
I have the feeling that every change achieves exactly the opposite.
I do not understand the logic behind this.
is there any other point besides INVERT_*_DIR
it can't be the wiring? under Marlin everything ran correctly.
Comments
// ################# XYZ movements ###################
so if you have #define DRIVE_SYSTEM 1 try to change to
#define DRIVE_SYSTEM 2
is for homing to min
Gruß Sebastian
Danke für den Spiegelhinweis.
Kann ich aber gerade nicht testen, weil sich der Bltouch bei den Versuchen zerlegt hat.
Der „Pimmel“ rührt sich nicht mehr. Shit happens. (liegt aber nicht an der FW)
d.h. jetzt muss ich erst mal auf der Bestellung warten…
Ich habe den Sensor zerlegt den Stab durch ein CFK Pin ersetzt.
O wunder es funktioniert (aber für die Dauer ist das nix, weil er spiel hat.)
Auf jeden Fall konnte ich die Situation nachstellen warum das Bett den Sensor gecrasht hat. Diesmal hatte ich ihn nur am Board angeschlossen und schon mit Sicherheitshöhe manuell ausgeht.
Nachdem die Messung abgeschlossen wurde fährt das Bett mit Volldampf weiter in den negativen Bereich für 20mm.
Nehme ich die Invertierung der Z-Achse raus passiert kein Unglück (weil das Bett fährt ja nach unten aber wie erwartet ich dann Z falsch rum.
Ich habe dies Video Tutorial verwendet.
Allerdings ist der da verwendete Drucker ein Kartesischer.
Ich habe viel probiert bin aber ratlos was ich da übersehe.
#define Z_PROBE_Z_OFFSET 0
#define Z_PROBE_Z_OFFSET_MODE 0
#define UI_BED_COATING 0
#define FEATURE_Z_PROBE 1
#define EXTRUDER_IS_Z_PROBE 0
#define Z_PROBE_DISABLE_HEATERS 0
#define Z_PROBE_BED_DISTANCE 10
#define Z_PROBE_PIN ORIG_Z_MIN_PIN
#define Z_PROBE_PULLUP 0
#define Z_PROBE_ON_HIGH 1
#define Z_PROBE_X_OFFSET 35
#define Z_PROBE_Y_OFFSET 20
#define Z_PROBE_WAIT_BEFORE_TEST 0
#define Z_PROBE_SPEED 2
#define Z_PROBE_XY_SPEED 150
#define Z_PROBE_SWITCHING_DISTANCE 4
#define Z_PROBE_REPETITIONS 2
#define Z_PROBE_USE_MEDIAN 0
#define Z_PROBE_HEIGHT 0
#define Z_PROBE_DELAY 0
#define Z_PROBE_START_SCRIPT "M340 P0 S700"
#define Z_PROBE_FINISHED_SCRIPT "M340 P0 S1500"
#define Z_PROBE_RUN_AFTER_EVERY_PROBE ""
#define Z_PROBE_REQUIRES_HEATING 0
#define Z_PROBE_MIN_TEMPERATURE 150
#define FEATURE_AUTOLEVEL 1
#define FEATURE_SOFTWARE_LEVELING 0
#define Z_PROBE_X1 20
#define Z_PROBE_Y1 20
#define Z_PROBE_X2 160
#define Z_PROBE_Y2 20
#define Z_PROBE_X3 100
#define Z_PROBE_Y3 160
#define BED_LEVELING_METHOD 1
#define BED_CORRECTION_METHOD 0
#define BED_LEVELING_GRID_SIZE 3
#define BED_LEVELING_REPETITIONS 5
#define BED_MOTOR_1_X 0
#define BED_MOTOR_1_Y 0
#define BED_MOTOR_2_X 200
#define BED_MOTOR_2_Y 0
#define BED_MOTOR_3_X 100
#define BED_MOTOR_3_Y 200
#define BENDING_CORRECTION_A 0
#define BENDING_CORRECTION_B 0
#define BENDING_CORRECTION_C 0
#define FEATURE_AXISCOMP 0
#define AXISCOMP_TANXY 0
#define AXISCOMP_TANYZ 0
#define AXISCOMP_TANXZ 0
Bei welchem Befehl passiert dieser extra Z Move? G28/G30/G32/G33 ? Ich würde erst mal g30 in der Luft testen. Der sollte ja immer zum Ursprung zurück gehen.
Die anderen nutzen das gleiche nur am Ende können sie sich unterscheiden. G28 fährt ja gerne dann die homing position an und hat auch noch ein paar extra parameter für Z. Bei G32/G33 fällt mir da direkt nicht ein.
G30
Wann genau danach fährt er ins negative? Sofort nach dem letzten Punkt oder noch eine xy verschiebung?
Beim G32 wundert es mich am meisten, weil da nur
G33 R0 würde distortion correction erst mal überall auf 0 setzen.
G33 R0 kennt er gar nicht.
hier das Log vom Server.
https://youtu.be/IwbzN-oCP-A
das Unglück wurde mit einem "Reset" am Display abgebrochen.
Da ist nicht eine Ausgabe der Punkte die gemessen wurden. Ich dachte der Fehler kommt am Ende bis dahin sollten doch x ausgaben von allen Punkten erfolgen? Oder passiert es bei G32 beim ersten Punkt?
G33 distortion hast du dann vermutlich nicht einkompiliert - gut dann können wir den auch auschließen.
Wie gut sind deine Programmierkenntnisse? Da ich du offenbar keinen üblen Wert siehst im eeprom und ich auch nicht und ich keine Idee habe wo es passierte müsste die Stelle gefundne werden wo der falsche Move passiert. Dann weiß man welche Parameter hier reinfließen und warum die Bewegung falsch ist. Dazu BedLeveling.cpp in der Funktion bool runBedLeveling(int s) { anfangen Testausgaben wie
Com::printFLN(PSTR("P1"));HAL::delayMilliseconds(1000);
einzubauen. P1 dann durch P2 P3.. ersetzen. An strategischen stellen. Das delay verzögert 1s damit du die Meldung lesen kannst und zuordnen. So kreise ich immer die Probleme ein wenn ich die selber testen kann.
Wenn man grob die Stelle kennst kann man es dann im nächsten Schritt weiter einkreisen oder man sieht schon welche variable da das Problem ist.
solange ich nichts selber schreiben muss besteht Hoffnung dass ich es hinbekomme.
Versuche heute Abend mal mein Glück.
vielleicht sollte man den Thead umbennen auf "bltouch debugging"?
Umbenennen können wir uns sparen - sind eh nur wir 2 hier am diskutieren und eigentlich klappt es bei den anderen. Abe res gibt immer wieder Kombinationen oder Fälle die man nicht sieht. Ach ja wenn du die stelle findest bitte den code und grobe Zeilenangaben posten. Ich nutze immer 1.0.5dev und Zeilen verscheiben sich immer etwas.
Ich habe wie gewünscht auf meine config in die aktuelle Dev übertragen.
Die Funktion hab ich gefunden und die Zeile darunter eingesetzt. Zeile 334
Neu gebaut und in den Drucker eingespielt.
Im Log erscheint P aber es wird keine Pause gemacht.
Wie hast du das nun gemeint? ich soll die Zeile der Reihe nach in jede if Schleife packen und schauen bis die Sekunde beim Hochfahren auftaucht?
Ich hab das bis Zeile 487 so gemacht bekomme aber nur das Pi wenn ich es ganz Oben bei 334 setze.
Mir ist noch was aufgefallen:
Z_PROBE_REPETITIONS setzt ich da mal 3 fährt er trotzdem nur 2 mal raus.
Fahr ich nach dem Reset das Bett mit Rep Server das Bett 10mm runter um den Sensor wieder gerade zu rücken Fährt das Bett über 100mm runter.
Beim zweiten Klick sind es dann nur 10mm ist bei 1mm das gleiche.
Ich dachte erst die Steps stimmen nicht, aber nach dem ist nicht so.
Wo soll ich das gesagt haben? Hab nirgends Schleifen erwähnt. Su sollst es an strategischen stellen einbauen und den Text ändern damit du nachverfolgen kannst wann er wo im code ist bei G32. Zeig doch mal was du draus gemacht hast, das ist einfacher.
Dann noch einen am ende der Funktion.
dann muss ich mit reset abbrechen.
es wird kein zweiter punkt angefahren.
oder hätte ich eine neue dev Version ziehen sollen und das da machen?
Wenn #if defined(Z_PROBE_MIN_TEMPERATURE) && Z_PROBE_MIN_TEMPERATURE && Z_PROBE_REQUIRES_HEATING
gültig ist müsste P2 erscheine kurz nachdem er eine erste bewegung macht.
Ach ja hast du gehomed bevor du G32 startest? Wenn nicht wird er ja wenigstens noch x und y homen
Aber da sollte eigentlich kein z move sein. Und danach gibt er P3 aus kommt also nicht da an wie du sagst.
Ok seh grade er geht in prepareForHoming
und das erste was er da macht ist alles homen. Also auch Z. Ich meine du sagtest ja das homen auch nicht geht. Dann ist es also das Z homing in G32 das da bereits schief läuft. Ich denke daher sollten wir G28 zuerst fixen weil es womöglich das Problem löst, also in Printer.cpp ungefähr Zeile 2159 in
direkt
Com::printFLN(PSTR("z1"));HAL::delayMilliseconds(1000);
..
Com::printFLN(PSTR("z2"));HAL::delayMilliseconds(1000);
Com::printFLN(PSTR("z3"));HAL::delayMilliseconds(1000);
Com::printFLN(PSTR("z4:"), zCorrection, 4);HAL::delayMilliseconds(1000);
Ich vermute das die bewegung nach z5 die problematische ist, da korrigiert er nach dem homing. Daher hab ich in z4 und z5 auch den Korrekturwert mit ausgeben lassen. Da sehen wir dann wie viel er korrigieren will und auch an welcher stelle der Wert hinzu kommt.
danach geht's in de negativen Bereich und ich muss mit reset abbrechen.
aber scheint mir auch kein Wunder zu sein bei dem Wert.
Com::printFLN(PSTR("z4:"), zCorrection, 4);HAL::delayMilliseconds(1000);
Also kommen die von einem dieser Werte:
EEPROM::zProbeHeight(); - im eeprom gespeichete z probe height
ENDSTOP_Z_BACK_ON_HOME - steht in deine configuration.h sollte bei z min homing 0 sein.
Prüfe also mal welcher der beiden auf 16092 steht. Hast du vielleicht z probe height in schritten statt mm eingegeben?
wo kann de Wert herkommen? noch ein Marlin Relekt im EEPROM?