Koordinaten ausgeben

Um die Bewegungen der Fräse, die mittels Joysticks impliziert werden, wenigstens zu visualisieren, habe ich der Joysticksteuerung ab Version V5.3 noch ein Interface verpasst, das entweder die Schritte oder die bereits aus der Schrittanzahl abgeleitete Entfernung über USB an den Steuerrechner übergibt.

In letzter Konsequenz könnte so eine Integration der Joysticksteuerung in jede GUI zum Streamen von G-Code erfolgen.

Der erste Ansatz ist, wie oben bereits erwähnt, die Darstellung der Koordinaten mittels SerialComInstruments, einer Toollandschaft, die von Ulrich Maassen entwickelt und kostenfrei zur Verfügung gestellt wurde.

Ab der Version V5.5 der Joystick-Firmware gibt es ein Flag um die Ausgabe der Koordinaten an das Display zu unterbinden. Dieses Flag ist defaultmäßig aktiviert und muss in der Firmware explizit ausgeschaltet werden, falls die Visualisierung erwünscht ist.

Auf dem Entwicklungssystem funktioniert diese Darstellung auf dem Monitor problemlos, nur auf dem Steuerrechner an der Fräse bewirkt die Aktivierung der Dreifach-Anzeige eine Blockade des Programms im Microcontroller, die Joysticks werden nicht mehr ausgelesen und es erfolgt keine Erzeugung von Schrittimpulsen mehr.

Auf der Suche nach dem Problem bzw. dessen Verursacher habe ich Unmengen von println()-Anweisungen in den Code eingebaut, da aber offenbar der Code nicht mehr abgearbeitet wird, ist dieser Ansatz natürlich vergebene Liebesmüh - ohne funktionierenden Code werden auch keine Debug-Informationen auf der Schnittstelle ausgegeben. Der Ansatz, über vorhandene LEDs zu signalisieren, wo der Code im Moment gerade noch vorbeigekommen ist und im nächsten Moment nicht mehr, war ebenfalls erfolglos, zu wenig kommunikativ um zielführend zu sein.

Nachtrag
Inzwischen hat sich der aus 2 mm-Buchsenleisten gebastelte Stecker für den USB 3.0 -Anschluss auf dem Motherboard als Verursacher der Störungen herausgestellt. Die Pins des Steckers auf dem MoBo sind viel dünner als die normalen Pins der 2 mm -Buchsenstecker, folglich haben sich offenbar über die Zeit Kontaktprobleme ergeben.
Durch Einsatz eines im Ersatzteilhandel erhältlichen Adapterkabels von USB 3.0 Motherboard-Stecker auf 8 pin Pfostenstecker hat sich das Kommunikationsproblem in Wohlgefallen aufgelöst.

Die nachfolgende Beschreibung im Zusammenhang mit dem debuggen von Arduinos ist somit nicht mehr notwendig aber dennoch hilfreich, wenn man vor einem ähnlichen Problem steht.

---

Um in den Innereien des blockierten µC nachschauen zu können, was los ist, müsste ein In Circuit-Emulator helfen. Das wohl zur Zeit (Stand 07/2016) beste und zudem noch recht preiswert erhältliche Tool ist wohl der Atmel-ICE, der sich in Atmel Studio oder auch Visual Studio integriert. In beiden Fällen müsste allerdings der Code angepasst werden, damit der jeweilige Compiler mit der angebotenen Syntax zufrieden ist. Im Normalzustand verstehen beide Compiler nicht, was in der Arduino-Umgebung Standard ist.

Hier springt ein PlugIn von Visual Micro in die Bresche, das sowohl Visual Studio als auch Atmel Studio dazu befähigt, unveränderten Arduino-Code zu verstehen, zu compilieren und, wenn alle Angaben der Erfinder auch für die aktuellen Versionen der erwähnten IDEs gelten, den erzeugten Code auch mittels Atmel-ICE in Echtzeit zu debuggen. Als zusätzliches Schmankerl bleibt das Projekt kompatibel zur Arduino-IDE, man kann also problem- und wahlfrei zwischen beiden Welten wechseln.

Die auf der Homepage von Visual Micro erwähnten IDEs sind allesamt bereits etwas in die Tage gekommen (Stand 07/2016), die Zusammenarbeit mit Atmel Studio 7 und Arduino V1.6.x oder höher musste erst verifiziert werden.
Ergebnis: Alles prima, die Toolkette funktioniert problemlos auch mit aktueller Software.

Der weitere Weg ist auf einer eigenen Seite beschrieben.