Reprap schlägt endstop ein

Hallo,
ich baue derzeit einen Wolfstrap mit Gen7 v1.5. Es funktioniert alles soweit der Extruder ist noch nicht dran kommt aber bald. Bei der Firmware habe ich erstmal Teacup genommen. Als Host den Repetier, Betriebsystem Linux Mint KDE. Ich habe Mechanische Endstops und der Endstopp-status wird bei M119 richtig angezeigt. Die Stepps ber mm sind richtig errechnet und nachgemessen.
Wenn ich jetzt das Homing durchführe und den Endstopp von Hand auslöse, bevor er einschlägt. Stockt der Schlitten kurz fährt dann aber weiter. aber mit einem brummen, so als ob die Schritte eines Motors zu hoch wären. Wenn ich den Motor von Handsteuere, auch Rapid-Move mit 300mm/s geht alles gut. Die homing Feedrate ist in der Firmware auf 50 mm/min gestellt, was 0,8 mm/s ergeben dürften, eigentlich nicht viel. Die Kabel von Motor und Endstopp kreuzen sich nie und laufen auch nicht paralell. In der Firmware habe ich die internen Pullups aktiviert. Wo ist also das Problem? Ich werde das komische Gefühl nicht los, dass es an der Firmware liegt. Kann das Jemand bestätigen?

Güße josa

P.S.:
Passiert es euch auch dauernd, dass ihr den Bootloader vom AVR zerschießt, so dass ihr den AVR nicht mehr über die IDE programmieren könnt?

1-mal bearbeitet. Zuletzt am 16.04.14 12:45.

Quote
josa
Wenn ich jetzt das Homing durchführe und den Endstopp von Hand auslöse, bevor er einschlägt. Stockt der Schlitten kurz fährt dann aber weiter. aber mit einem brummen, so als ob die Schritte eines Motors zu hoch wären. Wenn ich den Motor von Handsteuere, auch Rapid-Move mit 300mm/s geht alles gut. Die homing Feedrate ist in der Firmware auf 50 mm/min gestellt, was 0,8 mm/s ergeben dürften, eigentlich nicht viel. [...] Ich werde das komische Gefühl nicht los, dass es an der Firmware liegt. Kann das Jemand bestätigen?

Wenn M119 die Endstops erkennt, werden sie auch vom Rest der Firmware erkannt.

Die Homing Feedrate wird nur verwendet wenn SLOW_HOMING eingestellt ist, ansonsten fährt er mit Höchstgeschwindigkeit auf die Endstops zu (schnelle Grobabschätzung) und danach mit der Homing Feedrate zurück für die Feineinstellung. 50 mm/min ist sehr langsam, das könnte dieses Brummen sein. Lässt Du den Endstop wieder los, sollte das aufhören.

Die Spezialität der Teacup ist, dass sie beim auslösen des Endstops nicht abrupt anhält ( = Schrittverluste, überspringender Zahnriemen, mechanischer Stress), sondern geordnet abbremst. Der Haken daran ist, dass sie damit den Endstop um die Länge des Bremswegs überfährt und wenn die Bauart Deines Endstops das nicht zulässt, kracht es. Siehe auch [github.com]

Die Lösung ist, einen maximalen Bremsweg zu definieren und beim schnellen Homing eben nicht schneller zu fahren als dass der Bremsweg kurz genug ist. Das ist aber noch nicht implementiert. Gut ist, dass ich die nächsten Tage selbst ein paar schnelle Achsen haben werde, ich also nicht drumherum komme, das einzubringen. Es wird eine kleine Formel sein, die MAXIMUM_FEEDRATE_{XYZ} in home.c ersetzt. Zeile 44, 80, 114, 150, 184 und 221. Kannst Du gerne selbst machen oder behelfsweise einen festen Wert einsetzen.

Quote
josa
Passiert es euch auch dauernd, dass ihr den Bootloader vom AVR zerschießt, so dass ihr den AVR nicht mehr über die IDE programmieren könnt?

Hast Du die Fuse für den Brown-Out-Detektor gesetzt? Läuft das Ding bei Unterspannung (entsteht bei jedem ausschalten) weiter, wenn auch nur für eine Millisekunde, gibt's Chaos im Flash.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
josa
Wenn ich jetzt das Homing durchführe und den Endstopp von Hand auslöse, bevor er einschlägt. Stockt der Schlitten kurz fährt dann aber weiter. aber mit einem brummen, so als ob die Schritte eines Motors zu hoch wären. Wenn ich den Motor von Handsteuere, auch Rapid-Move mit 300mm/s geht alles gut. Die homing Feedrate ist in der Firmware auf 50 mm/min gestellt, was 0,8 mm/s ergeben dürften, eigentlich nicht viel. [...] Ich werde das komische Gefühl nicht los, dass es an der Firmware liegt. Kann das Jemand bestätigen?

Wenn M119 die Endstops erkennt, werden sie auch vom Rest der Firmware erkannt.

Die Homing Feedrate wird nur verwendet wenn SLOW_HOMING eingestellt ist, ansonsten fährt er mit Höchstgeschwindigkeit auf die Endstops zu (schnelle Grobabschätzung) und danach mit der Homing Feedrate zurück für die Feineinstellung. 50 mm/min ist sehr langsam, das könnte dieses Brummen sein. Lässt Du den Endstop wieder los, sollte das aufhören.

Die Spezialität der Teacup ist, dass sie beim auslösen des Endstops nicht abrupt anhält ( = Schrittverluste, überspringender Zahnriemen, mechanischer Stress), sondern geordnet abbremst. Der Haken daran ist, dass sie damit den Endstop um die Länge des Bremswegs überfährt und wenn die Bauart Deines Endstops das nicht zulässt, kracht es. Siehe auch [github.com]

Die Lösung ist, einen maximalen Bremsweg zu definieren und beim schnellen Homing eben nicht schneller zu fahren als dass der Bremsweg kurz genug ist. Das ist aber noch nicht implementiert. Gut ist, dass ich die nächsten Tage selbst ein paar schnelle Achsen haben werde, ich also nicht drumherum komme, das einzubringen. Es wird eine kleine Formel sein, die MAXIMUM_FEEDRATE_{XYZ} in home.c ersetzt. Zeile 44, 80, 114, 150, 184 und 221. Kannst Du gerne selbst machen oder behelfsweise einen festen Wert einsetzen.

Kann es sein, dass es zwei verschiedene Arten von Homing gibt? Eine schnelle Variante, die zuerst ausgeführt wird und eine langsame.

Auf jeden Fall ist das bei mir so.
Bei der ersten Variante kommt das von mir bereits beschriebeneVerhalten vor. Die Achse fährt ziemlich schnell los, ich betätige den Endstopp, die Achse stockt kurz fährt aber weiter und kracht in den Anschlag. Was ich jetzt nicht verstehe ist was dannach passiert. Die Achse ist bereits am Anschlag verliert als die ganze Zeit Schritte, aber dort am Anschlag brummt es dreimal über etwa 10sec. Immer ein kurzes brummen (1,5sec) dann Pause und wieder. Das ganze drei mal. Wieso!?!

Die zweite Variante des Homings kann ich auch nicht nachvollziehen, ich starte das homing. Die Achse fährt sehr langsam los und fährt einfach weiter egal ob ich den Endstopp drücke. Sie fährt dabei in die andere Richtung als bei der ersten Variante des homings. Ich breche dann immer ab. Aus diesem Modus mit dem langsamen homing finde ich auc fast kein zurück mehr ein betätigen des Reset-Schalters nützt nichts. Ein deconnect nützt auch nichts. Auch ein Neustart des Host Programmes nützt nichts. Irgendwann "gibt" sich das dann wieder. aber was hat es damit auf sich?

Quote
Traumflug

Quote
josa
Passiert es euch auch dauernd, dass ihr den Bootloader vom AVR zerschießt, so dass ihr den AVR nicht mehr über die IDE programmieren könnt?

Hast Du die Fuse für den Brown-Out-Detektor gesetzt? Läuft das Ding bei Unterspannung (entsteht bei jedem ausschalten) weiter, wenn auch nur für eine Millisekunde, gibt's Chaos im Flash.

Ist das das Fuse-Bit, mit dem man den AVR sperrt? Das habe ich nicht gesetzt, weil ich es immer etwas kritisch finde, wenn man sich mit absicht aus dem AVR aussperrt.
Das mit der Unterspannung kann schon sein ich betreibe die Elektronik an einem PC-Netzteil mit Schalter. Und schalte so auch die Elektronik aus. Eventuell hat das Netzteil Kondensatoren, die die Spannung dann langsam absinken lassen oder eventuel auch der Pufferkondensator auf der Gen7 ? Aber wie könnte man so etwas umgehen?

Grüße josa

Quote
josa
Kann es sein, dass es zwei verschiedene Arten von Homing gibt? Eine schnelle Variante, die zuerst ausgeführt wird und eine langsame.

Welchen G-code schickst Du da eigentlich? Wenn Du da irgendwo in Pronterface oder Repetier Host rum klickst ist das mehr ein Ratespiel. Statt dessen wäre es eine gute Idee, den G-code direkt zu schicken. Idealerweise sogar mit einem Serial Terminal (PuTTY, GtkTerm) statt so einem Host. Homing geht mit G28 für alle Achsen und G28 X / G28 Y / G28 Z für die einzelnen Achsen.

Quote
josa
Ist das das Fuse-Bit, mit dem man den AVR sperrt?

Nein, ein anderes Bit.

Quote
josa
Eventuell hat das Netzteil Kondensatoren, die die Spannung dann langsam absinken lassen oder eventuel auch der Pufferkondensator auf der Gen7 ?

Richtig.

Quote
josa
Aber wie könnte man so etwas umgehen?

Indem man das richtige Bit setzt, siehe Anleitung. Schlauer als der Entwickler zu sein ist nicht so einfach

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
josa
Kann es sein, dass es zwei verschiedene Arten von Homing gibt? Eine schnelle Variante, die zuerst ausgeführt wird und eine langsame.

Welchen G-code schickst Du da eigentlich? Wenn Du da irgendwo in Pronterface oder Repetier Host rum klickst ist das mehr ein Ratespiel. Statt dessen wäre es eine gute Idee, den G-code direkt zu schicken. Idealerweise sogar mit einem Serial Terminal (PuTTY, GtkTerm) statt so einem Host. Homing geht mit G28 für alle Achsen und G28 X / G28 Y / G28 Z für die einzelnen Achsen.

Es ist in beiden Fällen so sowol mit Gcode direkt über die Konsole des Hosts, als auch über den Button.

Quote
Traumflug

Quote
josa
Ist das das Fuse-Bit, mit dem man den AVR sperrt?
Nein, ein anderes Bit.

Quote
josa
Eventuell hat das Netzteil Kondensatoren, die die Spannung dann langsam absinken lassen oder eventuel auch der Pufferkondensator auf der Gen7 ?

Richtig.

Quote
josa
Aber wie könnte man so etwas umgehen?

Indem man das richtige Bit setzt, siehe Anleitung. Schlauer als der Entwickler zu sein ist nicht so einfach

Ich habe jetzt die Brow-Out-Detection auf 4.3v gestellt.
Dannach kann ich das Board auch über die IDE flashen.

EDIT:
Das fehlverhalten beim flashen bleibt aber gleich manchmal gehts manchmal nicht. Meistens aber eher nicht. Wenn ich das hex file, das die IDE erzeugt direkt per ISP flashe geht es auch. Ist aber nicht so komfortabel, denn das muss ich derzeit noch über Windows machen. Da ich meinen Programmer derzeit noch nicht unter Linux verwenden kann.

Grüße josa

1-mal bearbeitet. Zuletzt am 17.04.14 09:39.