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)