Im klassischen Schreinerbetrieb werden Verbindungen über Eck oft als Fingerzinken ausgeführt. Man kann sie mühsam von Hand sägen, mit einer Schablone und einer Oberfräse ausfräsen oder aber auf auf der Kreissäge erzeugen. Im amerikanischen Umfeld werden dafür gerne dado blades (Nutsägeblätter) verwendet. Das sind mehrere Sägeblätter im Stapel, die in einem Durchlauf gleich einen ganzen Zentimeter Breite raussägen können.

Dado Blade auf Wikipedia

In Deutschland sind die dado blades meines Wissens nach nicht zulässig. Aber man kann es mit etwas mehr Mühe auch mit einem normalen Kreissägeblatt hinbekommen. Es sind dann eben mehrere Durchläufe notwendig, die jeweils um die Breite des Sägeblatts versetzt vorgenommen werden. Die Schwierigkeit liegt dabei in dem korrekten Versatz, denn die Fingerzinken müssen relativ genau gearbeitet werden.

Ich habe mir dabei gedacht, dass sich um den Versatz ein Microcontroller kümmern kann. Man stellt die Breite der Zinken ein und der Controller verschiebt bei jedem Durchgang den Anschlag um den benötigten Betrag. Dieser Versatz ist nicht immer gleich. Bei meiner Säge beträgt die Breite des Sägeblatts 3 Millimeter. Ein 8 Millimeter breiter Spalt wird also durch einen Sägeschnitt erzeugt, gefolgt von zweimal einem Versatz von jeweils 2,5 Millimeter. Danach müssen 8 Millimeter stehen bleiben, der nächste Versatz beträgt also 11 Millimeter. Der Anschlag muss also immer um die Beträge 2,5 – 2,5 – 11 – 2,5 – 2,5 – 11 … Millimeter verschoben werden.

In der Bastelkiste habe ich einen alten Schrittmotor aus einem 5 1/4 Zoll Floppy Disk Laufwerk gefunden. Er hat fünf Anschlüsse, ein gemeinsamer Plus Pol und dann vier versetzte Spulen. Obwohl ich kein Datenblatt dafür habe, konnte ich die Anschlüsse relativ schnell mit einem Ohmmeter ermitteln.

Der Anschluss an einen Microcontroller ist recht einfach. Für solche Fälle hat man immer ein paar ULN 2003 rumfliegen. Das sind 8 Darlingtontransistoren mit Vorwiderständen in einem DIL Gehäuse. Da der Schrittmotor aus einem Floppy Laufwerk stammt, gehe ich von einer Betriebsspannung von 12 Volt aus. Tests haben gezeigt, dass ab etwa 8 Volt eine ausreichende Kraft zur Verfügung steht und auch 16 Volt nach längerer Arbeit nicht zu einem heißen Motor führt.

Der Microcontroller wird über die USB Leitung mit Spannung versorgt, kann aber auch eine externe Spannungsquelle haben. Der Schrittmotor bezieht seine Versorgung aus einem Labornetzteil (über die grün/ weiße Leitung). Man sieht, dass die komplette Schaltung im Prinzip nur aus einem IC besteht.

Nachdem ich einen laufenden Motor hatte, habe ich zuerst die Schrittzahl für eine volle Umdrehung ermittelt. Das muss nicht übermäßig genau sein, da Schrittmotoren typischerweise eine Schrittzahl von 24, 200 oder 400 besitzen. Ich habe noch keinen Motor gesehen, der 197 Schritte pro Umdrehung im Datenblatt angegeben hat. Ein kleiner Test mit einer Markierung auf der Achse zeigt, dass ich ein Modell mit 200 Schritten habe.

Als nächstes musste ich die Geschwindigkeit des Motors ermitteln. Ein Schrittmotor dreht sich exakt so schnell, wie es über die Schrittfolge vorgegeben ist – zumindest im Normalbetrieb. Wenn man den Motor mechanisch zu stark belastet, verliert er Schritte, d.h. er dreht sich nicht weiter. Wenn man eine langsame Schrittfolge wählt, wird der Vorschub sehr langsam. Die verwendete M6 Gewindestange hat eine Steigung von einem Millimeter pro Umdrehung. Wenn ich 10 cm vorrücken will, sind also 100 Umdrehungen notwendig. Zur Ermittlung der maximalen Schrittrate habe ich die Geschwindigkeit beginnend von 50 Schritten pro Sekunde nach und nach auf 1000 Schritte pro Sekunde erhöht. Wenn die maximale Geschwindigkeit erreicht ist, kann der Motor einen Schritt nicht mehr vollständig ausführen bevor der nächste Schritt kommt. Das führt dazu, dass der Motor mit einem heftigen Brummen stehen bleibt. Von der Maximalgeschwindigkeit habe ich dann noch mal eine ordentliche Portion abgeschnitten. Als Sicherheitsmarge, denn bei dieser Geschwindigkeit ist die Kraft gerade noch ausreichend, um die Gewindestange zu drehen. Aktuell verwende ich maximal 500 Schritte pro Sekunde. Das ergibt 2,5 Umdrehungen pro Sekunde und somit einen Vorschub von nur 2,5 Millimeter pro Sekunde. Da ich jeweils nur kurze Strecken zurücklegen muss, ist das für den Einsatzzweck akzeptabel.

Da die Port-Pins des Microcontrollers nicht in einer Reihe liegen, habe ich sie so verdrahtet, wie es am einfachsten ist. Um zur Schrittgenerierung eine 1 durchzuschieben habe ich ein Array der Länge 4 angelegt, welches dann das jeweilige Port Bit enthält. Es müssen also im Kreis alle vier Werte vorwärts oder rückwärts ausgegeben werden.

Wenn man bei einem Schrittmotor im Ruhezustand direkt auf volle Geschwindigkeit geht, führt das zu Schrittverlusten, da der Motor nicht so schnell reagieren kann. Im schlimmsten Fall läuft er gar nicht an. Deshalb wird die Geschwindigkeit langsam hochgefahren. Der Abstand vom ersten zum zweiten Schritt beträgt 13 Millisekunden. Er wird bei jedem Schritt um eine Millisekunde verkürzt, bis zur maximalen Geschwindigkeit mit einem Abstand von 2 Millisekunden. Beim Abbremsen passiert das gleiche umgekehrt, die Abstände werden über 10 Stufen langsam verlängert. Wenn weniger als 20 Schritte ausgeführt werden sollen, besteht die Sequenz nur aus einer Teilrampe zum Beschleunigen und Abbremsen.

Die Funktion für den schrittweiten Vorschub wartet auf das nächste Kommando. Wenn es zum nächsten Anschlag weitergehen soll, holt sie sich die nächste Schrittzahl aus dem Feld stepValues über den hochgezählten Index globalStep und führt diese Anzahl von Schritten aus. Die Anzahl wird auch in einem Summenspeicher gemerkt, damit der Linearvorschub über ein zweites Kommando wieder zum Startpunkt zurückfahren kann.

Eine weitere Funktion dient zur Einstellung des Nullpunkts. In diesem Fall fährt der Schrittmotor in eine Richtung, bis diese über einen Tastendruck gewechselt wird.

Erstaunlicherweise gibt es in meiner Bastelkiste einen auffälligen Mangel an Drucktastern. Also musste ich das „User Interface“ auf ein Minimum begrenzen. Auf der Microcontroller Platine gibt es einen User Button – das war alles, was mir zur Verfügung stand.

Der Zustand des User Buttons wird alle 10 Millisekunden geprüft. Zur Entprellung wird ein kurzer Tastendruck gewertet, wenn der Zustand mindestens 50 Millisekunden auf 1 stand.

Wenn er eine Sekunde lang gedrückt wurde, dann wird das als langer Tastendruck gewertet.

Wenn beim Start des Programms der User Button gedrückt ist, geht das Programm in den Null-Einstellungsmodus. In diesem Fall läuft der Schrittmotor in eine Richtung bis der User Button gedrückt wird. Dann wird die Drehrichtung umgeschaltet.

Ist er beim Start nicht gedrückt, geht das Programm in den normalen Vorschubmodus. Bei jedem kurzen Button Klick wandert der Vorschub bis zum nächsten Stopp weiter. Bei einem langen Button Klick geht es zur Startposition zurück.

Was würde ich jetzt anders machen?

Da es sich nur um ein Bastelprojekt handelt, habe ich für den Linearvorschub keine Trapezgewindespindel gekauft sondern einfach eine Gewindestange aus dem Bestand verwendet. Diese hat leider einen deutlichen Schlag, was zu störenden Bewegungen seitlich und nach oben und unten führt. Für den geplanten Einsatzzweck ist das zwar egal, es sieht aber einfach nicht gut aus. Zudem könnte man die Trapezgewindespindel mit einer höheren Steigung kaufen und somit einen schnelleren Vorschub erreichen. Die aktuelle Positionierungsgenauigkeit, von rechnerisch 5 Mikrometer, kann ich ohnehin nicht ausnutzen.

Nachtrag vom 27.12.

Ein kurzer Test zeigt: Prinzipiell funktioniert das System – aber leider nicht mit der Präzision, die ich erhofft hatte. Es ist schwierig, die zu sägenden Teile exakt Senkrecht am Anschlag zu halten. Schon ein kleiner Winkelfehler führt zu unterschiedlich breiten Zinken.

 

Von einem anderen Bastelprojekt hatte ich noch 4 Siebensegment Displays übrig. Daraus wollte ich einen 4-stelligen Zähler machen. Da die einzelnen Elemente 25 mm hoch sind, bestehen sie intern aus zwei LEDs pro Balken. Das macht eine Ansteuerung mit üblichen TTL Pegeln etwas unhandlich (Durchlass Spannung laut Datenblatt ca. 4,4 Volt). Zudem sollte die Anzeige in der Helligkeit regulierbar sein, ein einfacher 7447 reicht also nicht aus.

Zuerst hatte ich gedacht, die Segmente über eine Schieberegisteransteuerung mittels Open Collector bzw. Open Drain anzusprechen. Dazu hatte ich in meiner Bastelkiste aber nichts brauchbares und Schieberegister mit Open Collector sind auch nicht leicht zu bekommen.

Der nächste Gedanke war HCT statt TTL Typen zu verwenden. Die vertragen mehr als 5 Volt Betriebsspannung. Der 74HCT595 ist bis zu 7 Volt zugelassen. Das würde zur Ansteuerung reichen. Die Inputs würden auch bei 7V sicherlich noch zuverlässig mit normalen TTL Pegeln zu schalten sein. Allerdings ist die zusätzliche Versorgungspannung etwas unhandlich.

Deshalb habe ich mich dazu entschlossen, die Ansteuerung bei 5 Volt, dafür aber ohne Vorwiderstand auszuführen. Für eine kommerzielle Schaltung sicherlich eine unzulässige Vorgehensweise, da sie so sehr stark auf Bauteil- und Versorgungsspannungs-schwankungen reagiert.

Mein Microcontroller liefert auf der 5 Volt Schiene nur 4,8 Volt. Die LEDs benötigen 4,4 Volt und der Mosfet aus dem Treiber benötigt laut Datenblatt zwischen 0,15 und 0,4 Volt. Alles zusammen gibt einen Strom, der zwar noch unterhalb der zulässigen 20 Milliampere liegt (das Display erreicht nicht die volle Helligkeit) aber doch eine gute Anzeige erzeugt. Und es spart noch den Platz für 32 Widerstände. Die Schaltung wird dadurch deutlich kompakter.

Der 74HTC595 bringt noch einen weiteren Vorteil mit: er hat einen Enabled Eingang, den ich mit einem Pulsweitenmodulationsausgang des Controllers verbinden kann. Darüber kann ich ohne weiteren Hardwareaufwand eine Helligkeitssteuerung aufbauen. Im Testprojekt habe ich  die Steuerung dafür verwendet, bei einem Wechsel der Anzeige nicht einfach hart umzuschalten. Statt dessen wird die alte Anzeige kurz ausgeblendet, der Wert gewechselt und die neue Anzeige eingeblendet (ca. 200 Millisekunden). Es ergibt sich daraus eine altmodische Glühlampen-Anmutung.

Damit das Gesamtmodul möglichst klein bleibt, habe ich die Siebensegmentanzeige auf die eine Seite der Platine gesetzt und die Schieberegister auf die andere Seite. Das war ein wenig fummelig, hat aber doch ganz gut funktioniert.

Jetzt fehlt nur noch die Ansteuerung. Ich habe hierfür ein mbed Modul LPC 1768 verwendet. Dieses setze ich gerne für temporäre Aufbauten zum experimentieren ein. Der Vorteil der mbed Umgebung ist, dass es eine sehr komfortable Software zur Ansteuerung der verschiedenen Ein- und Ausgänge gibt.

Das Hauptmodul ist trivial. Es wird pro Anzeigestelle eine Struktur initialisiert, welche die Daten für einen endlichen Automaten enthält. Zudem wird eine Interruptroutine aufgesetzt, die alle 5 Millisekunden läuft und den Automaten weiter schaltet.

Jedes Display „kennt“ die Ziffer der aktuellen Anzeige sowie die Ziffer, welche beim Wechsel nach Aus- und Einblenden angezeigt werden soll.

Damit nur die Stellen dunkler werden, die sich verändern, hat jede Stelle seine eigene Pulsweitenmodulation.

Nach der Initialisierung geht das Hauptprogramm in eine Endlosschleife, die einen Zähler weiter schaltet (setInt) und danach jeweils eine Sekunde lang wartet.

Beim Hochzählen muss für jede Anzeigestelle der neue Wert berechnet werden. Wenn er vom aktuellen Anzeigewert abweicht, wird der neue Wert im Feld nextView gespeichert und der endliche Automat gestart, der die Anzeige langsam Aus- und wieder Einblendet. Diese Funktion ist also nach wenigen Mikrosekunden wieder beendet.

Die Aktualisierung der Anzeige sowie das Aus- und Einblenden findet in der Interruptfunktion statt. Diese wird über eine Timer-Variable alle 5 Millisekunden aufgerufen und prüft für alle vier Anzeigestellen den aktuellen Status.

• 0: normale Anzeige, keine Änderung des Status-Werts.
• 56 – 105: Anzeige ausblenden. Die Helligkeit ist bei 105 maximal, bei 55 minimal. Bei jedem Schritt den Status um eins herunter zählen.
• 55: den Wert „nächste Anzeige“ in die aktuelle Anzeige übernehmen und den Inhalt des Schieberegisters aktualisieren.
• 50 – 1: Anzeige wieder einblenden. Die Helligkeit ist bei 50 minimal, bei 1 maximal. Bei jedem Schritt den Status weiter um eins herunter zählen.

Im normalen Betrieb ist der Status 0, es findet keine weitere Aktion statt. Sobald der Ein-Sekunden Timer den Anzeigewert hochschaltet, wird für jede Displaystelle der neue Wert berechnet und im Feld nextView eingetragen. Der aktuelle Anzeigewert darf noch nicht überschrieben werden, da die Anzeige mit dem alten Wert ja langsam ausgeblendet werden soll.

Jede Stelle, die sich verändert hat, bekommt einen Statuswert 105. Daraufhin zählt der Automat bis 55 herunter und verringert dabei die Helligkeit auf Null.

Bei 55 wird das Schieberegister mit dem neuen Wert geladen und der Automat zählt weiter runter. Ab 50 beginnt er damit, die Helligkeit wieder herauf zu setzen. Bei 0 ist dann wieder die maximale Helligkeit erreicht und der Status bleibt bei 0 stehen.

Leider kommt meine kleine Digitalkamera nicht gut mit den stark schwankenden Helligkeitswerten klar und der Autofocus macht sich selbstständig. Ich richtigen Leben ist das Aus- und Einblenden glatter. Das wird wohl teilweise durch die automatische Helligkeitskorrektur der Kamera weggebügelt. Aber man kann den gewünschten Effekt trotzdem noch erkennen.

 

Ich habe vor einiger Zeit mal mit einem „Netduino“ herumgespielt. Für ein embedded System ist das eine ungewöhnlich komfortable Sache.Es handelt sich dabei um ein ARM System mit dem Anspruch, ähnlich einfach wie ein Arduino zu sein.

Auf des Desktop bin ich kein großer Freund vom Visual Studio. Im ebedded Bereich ist das aber mit weitem Abstand die komfortabelste und problemloseste Umgebung die ich kenne. Software installieren, Netduino an den USB Port anschließen und los geht’s. Inclusive eines komfortablen deployments und debuggers.

Mich persönlich hat jedoch der Overhead der .Net Umgebung gestört. Zu diesem Zeitpunkt gab es noch keinen JIT Compiler für die ebedded Variante (hat sich das geändert?). Ein einfaches Port-Bit setzen hat etwa 5,5 Mikrosekunden gedauert. Zugegeben, es waren ausgesprochen komfortable logische Port-Pins mit vielen Möglichkeiten. Aber es war einfach zu langsam. Über 350 Takte nur um einen Port zu setzen, das ist als würde man seine Pommes Frittes mit dem Lastwagen abholen. Damit konnte ich noch nicht mal einen einfachen digitalen Dreh-Encoder ohne Schrittverluste abfragen. Deshalb habe ich dieses schöne Projekt nicht weiter verfolgt.

Vor einem Jahr bin ich auf die mbed Umgebung gestoßen. Sie erlaubt ebenfalls einen extrem einfachen Einstieg. Einfach ein online Konto einrichten und die einfache aber ausreichende Entwicklungsumgebung läuft im Browser. Der Compile Button löst einen Browser Download der Binärdatei aus, welche man direkt in dem Controller speichern kann, der sich über den USB Port als Massenspeicher anmeldet.

http://developer.mbed.org/platforms/ST-Nucleo-F401RE/

Der Source Code wird in C++ erstellt – kein Problem, ich habe über 20 Jahre mit C und C++ gearbeitet. Als routinemäßiger Java Mann lag mir das C# vom Netduino aber eher. Die Hoffnung war, dass der C++ Compiler besseren Code erzeugt.

Also einfach mal ein kleines Programm geschrieben – Port auf 1 gesetzt, zurück auf 0 und das ganze in eine Schleife gepackt und das Oszilloskop dran gehangen. Hier komme ich nun auf Zeiten von 260 Nanosekunden zum setzen und zurücksetzen. Die Schleife selber erzeugt übrigens keine messbare Verzögerung.

Ein kurzer Blick in das Datenblatt – der F401RE hat einen Takt von 84 MHz – dann sind das ca. 22 Takte. Das ist ein sehr viel besserer Wert. Ein schöner Nebeneffekt: ein Board kostet gerade mal 8 Euro. Dafür bekommt man einen 32 Bit ARM Prozessor mit 84 MHz Takt, ordentlich RAM und Flash Speicher sowie einen 12 Bit A/D Wandler.

Der Nachteil: der einfache Einstieg über den Browser ist gleichzeitig die größte Beschränkung für die Entwicklung. Debugging ist nicht. Ich habe verschiedene Entwicklungsumgebungen ausprobiert und habe für Debugging-Zwecke eine freie Version von Keil behalten. Diese ist aber in keiner Weise mit der Visual Studio Entwicklung vergleichbar. Schade – aber man kann nicht alles haben.

Jetzt habe ich schon mal eine schöne Lösung, ich muss mir nur noch ein Problem dafür suchen…