So, nach dem ganzen Rumspielen haben uns die Kunststoffzahnräder an zwei Motorachsen verlassen. Sie haben sich an der Innenseite einfach rundgedreht.
Was ein Glück, dass ich mir heute nach der Arbeit einfach einen hochwertigeren Ersatz dafür bauen konnte
http://www.cysign.net/pics/milling/m...machine_14.jpg
Nachdem es mal wieder ein bisschen ruhig um das Thema wurde, möchte ich ein paar Bilder ergänzen:
http://www.cysign.net/pics/milling/m...machine_15.jpg
http://www.cysign.net/pics/milling/m...machine_16.jpg
http://www.cysign.net/pics/milling/m...machine_17.jpg
http://www.cysign.net/pics/milling/m...machine_18.jpg
http://www.cysign.net/pics/milling/m...machine_19.jpg
http://www.cysign.net/pics/milling/m...machine_20.jpg
http://www.cysign.net/pics/milling/m...machine_21.jpg
Eine der Schlauchkupplungen haben wir gegen ne Asia-Wellenkupplung ersetzt. Hierbei mussten wir feststellen, dass diese nicht ganz maßhaltig war und an der Gewindestange durchgerutscht ist. Ein kleines Stückchen Schleifpapier hat hier Wunder vollbracht
Da aber prinzipiell bisher von der Druckluftschlauchlösung kein Nachteil gegenüber den kommerziellen Wellenkupplungen ausgeht, werden die übrigen zwei Achsen zunächst nicht umgerüstet. Sollten sich Probleme ergeben, kann man da immer noch Zeit investieren.
Auch haben wir es inzwischen geschafft, die Endschalter richtig einzubinden.
Hierzu musste die Codezeile 178 in der https://github.com/grbl/grbl/blob/master/config.h auskommentiert und der Code neu kompiliert werden.
Leider funktionierten die Schalter danach immer noch nicht. Sie lösten willkürlich aus, auch wenn wir weit von einem Schalter entfernt waren.
Das Problem war die Einstreuung der neben den Leitungen für die Endschalter liegenden Stromleitungen zu den Motoren.
Die Induktion war scheinbar so hoch, dass sie Probleme ausgelöst hat.
Nach ner kleinen Bastelaktion waren die Kabel gegen alte USB-Kabel (da geschirmt!) getauscht, die Probleme aber immer noch nicht beseitigt. Es funktionierten 3 der 6 Schalter (2 pro Achse), was allerdings sehr merkwürdig war, da jeweils zwei Schalter zwischen Gnd und dem Arduino-Pin sind.
Das neu verursachte Problem war, dass ich die geschirmten Kabel an Gnd angeschlossen hatte. Nachdem ich diese Verbindung dann getrennt hatte, funktionierten endlich alle Endschalter und ich brauche keinen Bruch (außer bei Z negativ) mehr zu fürchten
Da wir inzwischen einen reproduzierbaren Fehler in Universal-Gcode-Sender gefunden haben (bereits der Git-Community des Projekts berichtet und ne Lösung wird gesucht), erübrigen uns die endlich funktioneirenden Endschalter ne Menge Bastelarbeit beim Wiederankleben/Wiederanlöten selbiger.
Unsere ersten C-Godes haben wir mittels Adobe Illustrator als DXF-File exportiert und mit CamBam folglich als Maschinencode gewandelt. Für die ersten Tests und zum groben Planfräsen des Tischs eine einfache Lösung.
Da wir nun allerdings (wie auf einem der letzten Bilder zu sehen ist) noch einen Laser (natürlich nur unter Verwendung von Schutzbrillen!) verwenden möchten, benötigen wir eine Alternative zu CamBam. Das kann zwar wunderschönen G-Code zum Fräsen oder auch Gravieren ehrstellen, jedoch leider haben wir bisher keine Möglichkeit gefunden, G-Code zum Lasern zu erzeugen.
Evtl. wäre SheetCam für uns interessant. Da ein Wechsel der Software in diesem Falle jedoch mit Kosten oder dem wohlwollenden Sponsoring des Herstellers verbunden ist (von CamBam haben wir eine Vollversion gesponsort bekommen!), werden wir nun erstmal abwägen, welche Cam-Lösung für den Sonderfall Fräsen + Lasern in Frage kommt und wie wir den Laser mit dem GRBL beladenen Arduino ansteuern.
Eine denkbare Lösung wäre es, den Spindle-Direction-Pin umzufunktionalisieren. Lieber wäre mir jedoch eine völlige Pinumbelegung von Grbl, um einen PWM-Pin des Arduinos für die Ansteuerung des Lasers nutzen zu können.
Auch schielen wir derzeit auf eine GRBL-Fork namens Lasaur, welche sich der Steuerung von Lasern auf CNC-Maschinen verschrieben hat. Leider sind die Infos diesbezüglich etwas mau gesät.
Falls jemand von euch Erfahrungen zum kombinierten Ansteuern von Laser + Frässpindel (wobei letztere nur ein- und ausgeschaltet werden muss) hat, wären wir also über Input dankbar =o)
Nach einer kleinen Pause hats mich gestern Abend mal wieder dazu getrieben, das Fräschen in die Hand zu nehmen.
Leider hab ich immer noch nicht die Lösung auf das Problem mit der spontanen Endschalterselbstauslöäsung gefunden.
Nachdem ich zunächst alle Kabel zu den Endschaltern gegen geschirmte getauscht hatte (Anlegen von Masse an die Schirmung = lösen sofort aus, Anlegen von 5V auf Schirmung = löst überhaupt nicht aus, Schirmung ohne irgendwas dran angeklemmt dachte ich zunächst funktioniert...aber tuts nun doch nicht, die spontane Selbstauslösung ist nur wesentlich seltener geworden) hab ich jetzt noch angefangen mit Aluklebeband sämtliche auf den ersten und zweiten Blick relevanten Leitungen voneinander abzuschirmen. Aber leider läuft der Gerät immer noch nicht ohne spontane Selbstauslösungen der Endschalter durch.
Das Experiment 5V über ein 20K-Poti anzulegen hat jedoch scheinbar eine Verzögerung der Auslösung gebracht.
Das Erstaunliche: Selbst wenn ich die abgeschirmten Kabel mit den Endschaltern vom Arduino trenne, gibts spontane Selbstauslösungen.
Kann es sein, dass die internen PullUps im Arduino Nano nicht zuverlässig arbeiten? Bzw. irgendwie eine zu große Restwelligkeit haben?
So langsam gehen mir die Ideen aus, wie ich die spontanen Selbstauslösungen der Endschalter verhindern, die Referenzierung jedoch dennoch ermöglichen kann.
Zumindest das Referenzieren (Homingcycle) funktioniert nun und ich habe somit einen festgelegten Maschinennullpunkt.
Wenn die Störungen von der Steuerung kommen könntest du einen Pullup verwenden und zusätzlich mit einem Kondensator gegen Masse. Wenn das auch nichts nutzt gibt es im Programm des Arduino einen Fehler oder der Arduino hat selbst einen Fehler.
MfG Hannes
Ich hab mal ein wenig mit einem 20K-Poti rumgespielt, was leider keine Besserung brachte.
Deshalb hab ich mich entschlossen, gestern/heute die abgeschirmten Kabel (von 2 der 3 Achsen) zu tauschen (was ein bestimmtes, rekonstruierbares Problem gelöst hat). Außerdem habe ich den Arduino irgendwie (vermutlich durch nen Kurzen beim Basteln) in die ewigen Jagdgründe geschickt. Gut, dass ich noch zwei Reserve-Nanos heir hatte
Weiterhin hab ich die Endschalter von Öffnern zu Schließern umgebaut.
Aber auch das hat nichts gebracht.
Auch hab ich die Fläche zwischen allen stark strahlenden Leitungen/Motoren mit Aluklebeband abgeschirmt - ohne Erfolg.
Inzwischen scheinen die Abstände zwischen den plötzlichen Auslösungen der Taster geringer geworden zu sein, aber ganz weg sind sie immer noch nicht.
Mit nem Multimeter konnte ich die Quelle nicht ausfindig machen.
Als nächstes werde ich, nachdem das GRBL-Setup auf dem neuen Nano nun wieder die richtigen Werte hat, ein GCode-Programm abfahren und dabei die Leitungen des noch nicht getauschten Endtasterkabel trennen, um sicherzustellen, dass es nicht an den Kabeln der Endtaster der X-Achse liegt.
Sollte das auch nichts bringen, hab ich vor, die Endtaster mal unterm Oszilloskop zu betrachten.
Und meine letzte Idee wäre dann noch, dass der Nano einfach nicht dafür geeignet ist, weil im Design irgendwelche Leitungen zu dicht beieinander sind, was das Problem verursachen könnte.
Dann müsste ich meinen Nano überreden, GRBL zu sprechen.
Berechtigungen
Zitieren
Lesezeichen