Closed Nibbels closed 6 years ago
Ich denke, du hast recht, das darf an der Stelle nicht homeDir abhängig sein, es soll ja immer nach unten gehen. Wenn mein Drucker wieder frei ist, kann ich mal kurz ausprobieren, ob das wirklich falsch ist im Milling Mode. Das kann aber gut sein, denn im Milling Mode kann man eigentlich gar nicht an den oberen Endschalter kommen, deswegen ist das eigentlich unkritisch (aber irgendwie trotzdem falsch ;-)).
Ich hatte das zumindest in meiner persönlichen neuen Alpha für eine mögliche 1.41 geändert. https://github.com/Nibbels/Repetier-Firmware/commit/05369cd14fa16a0a9bf6bec1778c62513890c780#diff-9aca95228b7ddf147d2220465e7e6e05L1812
Ich habs dann x mal durchgedacht und immer wieder die vorzeichen geprüft: ich kam zu dem schluss dass es falsch sein müsste. Die Info, dass immer zuerst nach unten gefahren werden muss habe ich von RF1000 in einer PN erhalten. Das gilt für den Fall Printer::ZEndstopUnknown == 1. So sieht zumindest die strategie aus.
Was ich aber vermutlich tun müsste, wäre, den Überfahrweg zu limitieren. Aber ich habs mal erfragt: Knopf drücken +0.8mm sollte beim normalen Schalter gehen.
https://github.com/RF1000community/Repetier-Firmware/blob/4b176392023c1b1ce510fe1d7877c5a95911dbc9/Repetier/RF1000.h#L698 https://github.com/RF1000community/Repetier-Firmware/blob/4b176392023c1b1ce510fe1d7877c5a95911dbc9/Repetier/RF1000.h#L641
RF1000:
Der würde aktuell also bis zu 1,1mm überdrücken. Und hoffentlich steht er dann nicht schon weit im unteren Schalter drin, wenn er runterfährt.
Andere Idee: Ich hab schon mal gedacht, ob ich nicht automatisch den Z-Strom voll runternehme hin und herfahre und langsam erhöhe bis ich frei bin. Dann kann der im Notfall nicht so viel drücken. Weiß aber nicht, ob das bescheuert ist oder nicht funktioniert. Es gibt halt leider eine unbekannte Stromstärke, da bewegt sich die Achse einfach noch nicht.
LG
Achso, ne gegen den unteren Endschalter kann man ruhig mit voller Kraft fahren. Der kann das ab. Das hat RF1000 im Forum auch mal bestätigt.
Ich habe gerade getestet, im Fräsmodus fährt er wirklich erstmal kurz nach oben statt nach unten, sofern der Endschalter schon betätigt ist. Allerdings würde er andernfalls auch nicht korrekt homen, jedenfalls wenn man sonst nichts ändern würde. Wenn ich den Endschalter permanent von Hand drücke und den Drucker im Fräsmodus neu starte und dann home, fährt er aktuell ein Stückchen nach oben und dann permanent nach unten. Wenn wir das jetzt umdrehen, müssten wir auch sichergehen, dass der Drucker weiß, dass der untere Endschalter bereits gedrückt ist, wenn er dieses Stückchen runter gefahren ist und der Endschalter ist immer noch gedrückt. Ich überblicke aber nicht im Code, was da passiert... Steigst du da durch, ob das dann korrekt wäre, oder was wir dafür noch ändern müssten?
Andererseits: Wie gesagt kann im Fräsbetrieb der obere Endschalter eigentlich nie gedrückt sein, in so fern ist das aktuelle Verhalten gar nicht so schlecht...
Super!! Dieser Text hilft mir.
Ich habe ehrlich gesagt den ganzen Abend nichts anderes gemacht als das homing etc. besser aufzuräumen ^^. (Ich arbeite inzwischen an einer Version die bei mir auf der Nibbels-development 1.41 heißt. Ich will da drin, wenn RF1000 die 1.41 rausbring sofort die Conrad-Patches einbauen und die Version gleich halten.)
Vorneweg: Wenn man den Fräser nicht in den unterne Z-Schalter reinfährt, ist der automatisch direkt nach dem Z-Home schon freigefahren. Es gibt dafür LEAVE_Z_MAX_ENDSTOP_AFTER_HOME Heißt, das Bett müsste im Fräsmodus sofort wenn es weiß wo der untere Endstop ist 2mm hochfahren. Dann werden die Koordinaten genullt. Erst dann ist das homing fertig.
Hier meine (jetzt) aktuelle development als Permalink: https://github.com/Nibbels/Repetier-Firmware/blob/9541e3f6614a1271458147d3f098ad039dcd9595/Repetier/Printer.cpp#L1786
1) Wacht der Drucker im Endschalter auf, weiß er nicht wo. Ist es ein RF1000 mit Circuit, dann ist ZEndstopUnknown == 1. Sonst nie. In diesem Fall fährt er nun genau ENDSTOP_Z_BACK_MOVE nach unten. Er müsste damit aus dem oberen Endschalter rauskommen. Oder er fährt in den unteren Schalter richtig rein.
Es gibt dabei irgendeinen Trick, sodass durch die Funktionen Printer::isZMinEndstopHit() oder Printer::isZMaxEndstopHit() der Schalter erkannt werden müsste. Ich bin dort aber noch nicht durchgestiegen.
2) Alle möglichen Dinge werden genullt. 3) Der Koordinatenachse wird vorgegaukelt, sie ist genau auf der gegenüberliegenden Seite. 4) Man fährt einfach maximal die doppelte Achslänge los. Abbruchbedingung ist der Schalter. -> Entweder kommt man genau 0/1 Step weit, weil da schon der Schalter ist. -> Oder man fährt eben bis zum ersten Schalterkontakt mit homingFeedrate (Neuerdings 80mm/s) 5) wir stehen am Schalter und wissen nicht ob wir beim apprupten Bremsen einen Fehler gemacht haben. ODER wir stehen voll im Schalterkontakt drin, weil der Drucker vorher schon da war. 6) Wir fahren Schrittweise aus dem Schalter raus und zwar genau gegen die Homing-Richtung. Das passiert so lange bis der Endschalter losgelassen wurde. Und wir gehen davon aus, dass der Schalter in jedem Fall innerhalb ENDSTOP_Z_BACK_MOVE (= Max. Überfahrweg + Max. Hysterese annahme) verlassen haben. 7) Haben wir den Schalter verlassen, fahren wir nochmal Z_ENDSTOP_MAX_HYSTERESIS weiter weg. Wir könnten ja genau auf 0 stehen, wenn wir vorher direkt auf 0 gefahren sind. 8) Wir fahren sehr langsam nochmal ran. 9) Nur im Milling-Mode: Wir fahren LEAVE_Z_MAX_ENDSTOP_AFTER_HOME 2mm + Z_ENDSTOP_MAX_HYSTERESIS weg vom Schalter. 10) Wir nageln die Null-Koordinate für Z dort fest. (Auf Max-Axis=Zahl oder Min-Axis=0)
Homing ist fertig.
(ZEndstopUnknown = false; wird dann erst angenommen. Wobei ich hier denke, dass eigentlcih der erste Move diese zuordnungs Arbeit schon übernommen haben müsste. Ich denke daher dass dieser ZEndstopUnknown = false; oben unter dem ersten Move stehen müsste?? Das weiß ich dann, wenn ich genau weiß wie das Erkennen abläuft. Das stimmt nicht, wenn der schalter absichtlich mehrmals angefahren und verlassen sein muss um die Erkennung abzuschließen, dann bräuchten wir alle Homingfahrten bis wir das ZEndstopUnknown = false; annehmen dürfen.)
Ich habe nun viel wirrwarr aufgeräumt, aber keine Ahnung warum bei dir was schiefgelaufen sein könnte.
Wenn du mit Cmake compilierst und ich mit Arduino. Ist bei dir am Ende sicherlich noch ca. über 1kb freier Ram verfügbar? Arduino erzählt uns das immer. Zumindst könnten wir damit einen saublöden Fehler ausschließen.
Denn grob 1000byte Ram oder leicht weniger brauchen wir!
Die Richtungsfrage ist mir nun absolut klar. Das muss immer nach unten gehen und es löst mir auch noch andere Denkprobleme diesbezüglich.
Closed.
Frage: https://github.com/RF1000community/Repetier-Firmware/commit/fb9207e51d411e11f53e725b53e2db6f8a502510
bezüglich axisStepsPerMM[Z_AXIS]-ENDSTOP_Z_BACK_MOVE nHomeDir
Printer::ZEndstopUnknown gibts nur als 1==true, wenn der RF1000-Drucker mit gedrücktem Endschalter aufwacht und nicht weiß an welchem Endschalter er klebt. Hier https://github.com/RF1000community/Repetier-Firmware/commit/fb9207e51d411e11f53e725b53e2db6f8a502510#diff-9aca95228b7ddf147d2220465e7e6e05R1461 wird nicht Millingmode vorausgesetzt.
Laut RF1000 fährt man eher nach unten, wenn man nicht weiß wo man hinfahren soll. Unten hält der Schalter das aus, eher als oben.
define ENDSTOP_Z_BACK_MOVE 0.5
homeDir ist von fall zu fall (milling vs. printing) unterschiedlich. Eigentlich müssten wir das
* nHomeDir * -1
doch einfach streichen, oder? Dann würde der drucker einfach immer ins Plus fahren? Oder hast du dir damals, wenn du das noch weißt, was spezielles überlegt?(Ich bräuchte echt "son verdammten" RF1000, sodass ich mir nicht ständig über den FEATURE_CONFIGURABLE_Z_ENDSTOPS-Mist den Kopf zerbrechen muss und einfach ausprobieren kann. Oder ich finde einen Weg, um das zu simulieren, indem ich einfach das Feature aktiviere ^^.)
LG