search

RF1000community / Repetier-Firmware

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

RF1000 + Z-Endstop Circuit: Drive-Free #44

Closed Nibbels closed 1 year ago

Nibbels commented 7 years ago

Wieder gabs Ärger damit. Wir sollten das rausschmeißen...

mhier commented 7 years ago

Von mir gerne :-)

Nibbels commented 7 years ago

Weißt du genau, wo man das Skalpell ansetzen müsste?

Ich hab das noch nie live gesehen und könnte zwar irgendwas abklemmen, aber nichts testen.

mhier commented 7 years ago

Ich kann mir das demnächst mal ansehen, aber wohl erst nächste Woche...

Nibbels commented 7 years ago

Vermutlich würde es reichen, wenn wir bei https://github.com/RF1000community/Repetier-Firmware/blob/community_stable/Repetier/RF.cpp#L7246

die Stelle char driveFree = 1; auf 0 setzen, dann wird es niemals aktiv.

Wenn Freifahren aus anderen Gründen ein Problem sein könnte, (weil es irgendwelche Z-Fahr-Verbote mit oder ohne Homing, Z-Compensation oder sonstwas geben könnte) können wir die Funktion freeZ( -Printer::axisStepsPerMM[Z_AXIS] ); auch auf einen Menüpunkt legen.

Nibbels commented 7 years ago

Soll ich das killen, ich weiß inzwischen wie?

Nur testen ob der millingmode/printermode irgendwie doch davon abhängig ist, kann ich leider nicht. (Testen ob es dann einen Zustand gäbe, in dem Z durch keinen Trick verfahrbar wäre... etc.)

mhier commented 7 years ago

Sorry, ich komm im Moment nicht dazu. Wenn du weißt wie, mach es gerne und ich teste es demnächst mal. Sonst mach ich es irgendwann später :-)

Nibbels commented 7 years ago

In der Development ist das nun raus. Ob das Auswirkungen auf den Betrieb der RF1000 hat, kann ich selbst nicht beantworten.

mhier commented 7 years ago

Ich habe gestern einen ersten Druck mit der neuesten Version gemacht und schon mal keine nervigen "Drive Free"s mehr beobachtet. Ich hatte trotzdem aber noch einmal den Bug, dass das Z-Homing nicht korrekt funktioniert hatte. Ich muss das noch mal genauer analysieren.

Nibbels commented 7 years ago

Wenn du was rausfindest, aber nicht gleich weißt, wo es im Code schiefgeht, sags mir :) Ich schau da parallel gerne drüber.

Beim RF2000 scheint das nichts auszumachen. Mein Drucker funktioniert perfekt. Notfalls müssten wir mal jemand anders überreden das zu installieren, um einzugrenzen ob es nur im Modus Circuit fehlerhaft ist.

Nibbels commented 7 years ago

Wenn z.B. mit der neuen Version das Z-Homing besser läuft können wir das schließen.

mhier commented 7 years ago

Mir ist gerade aufgefallen, dass jetzt, wenn der Z-Schalter als "Circuit" konfiguriert ist und der Drucker bei gedrücktem Endschalter aufwacht, beim ersten Homing das Bett direkt nach oben fährt. Das würde den Endschalter zerstören, wenn er am oberen Endschalter steht. Hängt das evtl. zusammen mit dieser Änderung? Ich finde leider den Commit gerade nicht, um es mal testweise zu reverten...

mhier commented 7 years ago

Ok, Problem behoben, siehe fb9207e51d411e11f53e725b53e2db6f8a502510

Nibbels commented 7 years ago

Das Richtungs-Problem, dass wenn der Drucker mit gedrücktem Schalter aufwacht war die Ursache für den Bug mit Drive-Free.

Ich sehe du hast ein paar Commits, darum warte ich erstmal ab. Danke!!

Um den richtigen aktuell gedrückten Endschalter herauszufinden, würde ich eine Art "Sinus in Z" anlegen der linear größer wird. Abbrechen, sobald der Endschalter losgelassen wurde. Dann wäre die Erkennung absolut zerstörungsfrei und zuverlässig, wenn der Knopf nicht mehr als halb durchgedrückt war.

mhier commented 7 years ago

Im Prinzip kann man immer gefahrlos nach unten fahren, weil der untere Z-Schalter das ab kann. Das ist offiziell so von Conrad vorgesehen. Mit einem Sinus in Z würde man gefahr laufen, den oberen Schalter zu weit zu überfahren und ggf. sogar mit dem Extruder ins Heizbett zu fahren, wenn der sich gerade über dem Bett befindet. Für mich hat es jetzt gut funktioniert bei ersten Trocken-Tests, mal sehen, ob es auch zuverlässig läuft. Ich hab in nächster Zeit noch Einiges zu drucken. Ich lass das Ticket hier erstmal offen.

mhier commented 6 years ago

Für mich hat das jetzt gut funktioniert, sowohl beim Fräsen als auch beim Drucken. Der Fehler, dass bei mir das Z-Homing beim Drucken gelegentlich schief geht, weil er zu früh wieder nach oben fährt (bevor der Z-Schalter losgelassen wurde), habe ich aber immer noch, wenn der Z-Schalter auf Circuit konfiguriert ist. Das ist wohl ein Problem unabhängig von driving free...

Nibbels commented 6 years ago

Kannst du das genauer erklären?

Der fährt im Druckmodus in Richtung Schalter unten, kommt an, fährt etwas zurück und wieder etwas langsamer nach an den Schalter. Dort bleibt er zum Schalterkontakt stehen. So sollte es sein, oder?

Es gibt in der RF1000.h/RF2000.h soeine Einstellung:

/** \brief If during homing the endstop is reached, how many mm should the printer move back for the second try */
#define ENDSTOP_X_BACK_MOVE                 5
#define ENDSTOP_Y_BACK_MOVE                 5
#define ENDSTOP_Z_BACK_MOVE                 0.5

und

/** \brief When you have several endstops in one circuit you need to disable it after homing by moving a
small amount back. This is also the case with H-belt systems. */
#define ENDSTOP_X_BACK_ON_HOME              0
#define ENDSTOP_Y_BACK_ON_HOME              0

weil homeX(){ ..}

#if defined(ENDSTOP_X_BACK_ON_HOME)
        if(ENDSTOP_X_BACK_ON_HOME > 0)
            PrintLine::moveRelativeDistanceInSteps(axisStepsPerMM[X_AXIS] * -ENDSTOP_X_BACK_ON_HOME * X_HOME_DIR,0,0,0,homingFeedrate[X_AXIS],true,false);
#endif // defined(ENDSTOP_X_BACK_ON_HOME)

Ist es möglich, dass dieser Backmove was damit zu tun hat?

Nibbels commented 6 years ago

AtlonXP hat im Printmodus ziemlich alles durchgetestet: Er hat nur einen "Single"-Schalter am RF1000 und kann nun eine Z-Matrix ertasten, die im Bereich bis -12mm liegt.

Homing funktioniert immer, auch von dieser Tiefe heraus.

Das Extra-#define für Z_ENDSTOP_DRIVE_OVER und die Abhängigkeit der anderen Werte davon ( https://github.com/RF1000community/Repetier-Firmware/commit/2704206ead75fa777c6e5c1503b00f9a8ae15272#diff-42d04a53302d660aad46837650f4ff9dR633 ) ist ne gute Sache :)

Die Hysterese beim Schalter loslassen des RF2000 ist kleiner 0.01. Harry hat mit seinem optischen Eigenbau-Spezialschalter ca. 0.06mm Hysterese. Die Einstellung, dass wir 0.2 oder 0.3mm Backmove (+ Tiefste mögliche Überfahrtiefe) verwenden scheint in Ordnung zu sein.