Günstige Komponenten für CNC-Fräse gesucht

**robots4-ever** · 01.04.2013, 01:18

Also ich muss sagen, ich habe mich jetzt so in ca. eine Stunde komplett in dieses Thema eingelesen und ein richtig FETTES RESPEKT an die Community. Nur mal so neben bei. Ich bin jetzt auch dabei mir eine kleine CNC zu bauen.
Und nur mal so eine kleine Frage an dich wie hast du den Code für das Arduino geschrieben? Also wie sieht der aus?
Wäre cool wenn du den vielleicht einfügen könntest.

**robin** · 01.04.2013, 10:51

@Cysign: kannst du mal ein Bild von der Seite deines Aufbaus zeigen? evtl kann man dir ja helfen, ein Paar Fehlerquellen zu finden, nicht dass später noch eine Version 3 nötig ist

Auf Anhieb ist mir der Tisch aufgefallen, hier würde ich zumindest noch Schienen unten drunter machen um in alle Richtungen halt zu haben.

Dein Portal würde ich zumindest nicht so aus 3 Brettern bauen, würde es aus 3 Kästen ausbauen und Multiplex oder MDF nehmen, aber das wirst du schon selbst wissen.

Für den ersten Versuch ist es aber schonmal nicht schlecht.
Deine größte Schwachstelle dürfte aber aktuell dein PC sein

**Cysign** · 03.04.2013, 14:07

@robots4-ever: Der Arduino braucht einen G-Code-Interpreter. Hier kannst du z.B. GRBL nehmen. Da der Arduino aber für uns vorläufig nur zum Testen der Schrittmotorkarten hergehalten hat, möchte ich darauf an dieser Stelle weniger eingehen. Schließlich soll die Steuerung über EMC2 erfolgen. Ich hoffe, dass ich gegen Ende der Woche endlich funktionierenden Ram bekommen werde.

@Robin: Ja, da hast du recht. Wenn die Schinen unter dem Tisch wären, hätte die Konstruktion mehr Halt.
Ist aber nicht schlimm, hier geht es uns um die Ansteuerung der Motore und Schalter. In Version 2.0 gibts richtige Linearführungen, womit wir eine Sorge weniger hätten.
Weitere Fotos kann ich gerne machen, sobald wir weiter basteln - ich denke mal spätestens am Wochenende.

**Cysign** · 25.11.2013, 22:44

So, nachdem es mal wieder lange still war um mein Hobby, haben zwei Freunde und ich vor einigen Tagen zum ersten Mal alle drei Achsen vom Computer aus verfahren.
Ich muss zugeben, ich hab zwar verdammt viel Zeit in diese Bastelei gesteckt...dafür aber auch sehr viel gelernt, seit ich mich im Roboternetz rumtreibe und aktiv den Lötkolben in die Hand nehme

Unser Aufbau aus Schubladenschienen, Gewebeschlauch als Kupplulng zwischen Gewindestangen und 0,2Nm-Schrittmotoren hat eben zum ersten Mal eine Frässpindel verschoben.
Da wir zwar inzwischen den Bau von zwei größen Fräsen planen, die wesentlich kräftiger sind (3Nm und 13Nm), haben wir dennoch unseren ersten Prototypen nicht abgeschossen.
Die Schlauchstücke sollen gegen Wellenkupplungen ersetzt werden, die Endschalter (wir haben Öffner...Grbl nutzt jedoch Schließer...deshalb haben wir nen Pulldown-Widerstand (kann auch ein Pull-up sein...verwechsel ich immer

) pro Endschalter-Satz (pro Achse zwei) eingebaut. Jedoch fällt der Strom beim Betätigen der Endschalter lediglich auf 0,3V ab, was GRBL jedoch noch zu viel ist.

Außerdem läuft momentan eine der L297/l298-Karten nur im Halbschrittmodus...was irgendwo ne fehlerhafte Lötstelle sein muss - da ist ne kleine Multimetersession angesagt

**Cysign** · 26.11.2013, 17:29

So, heute hab ich mich mal dran gemacht, die 12V des PC-Netzteils gegen 40V zu tauschen. Das Ergebnis lässt sich echt sehen:
https://www.youtube.com/watch?v=TC8-L4KaUfs

Allerdings ist das Projekt nun schon wieder ausgebremst...bis neue, günstige Komponenten aus Hong Kong hier sind.
Die Zahnräder, die um die Motorwelle waren, hatte ich dran gelassen und Druckluftschlauch mit Schlauchschellen befestigt. Prinzipiell keine schlechte Idee - wenn die Zahnräder nicht den Geist aufgegeben hätten. Von X- und Z-Achse haben sich die Zahnräder leider an der Innenseite rund gedreht.

**Cysign** · 29.11.2013, 20:43

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

**Cysign** · 08.01.2014, 11:22

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)

**Cysign** · 02.05.2014, 19:59

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.

**021aet04** · 02.05.2014, 20:07

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

**Cysign** · 17.05.2014, 18:15

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.