Praxisbeispiel: Motorsteuerung

Wenn wir z. B. mit einem Arduino einen DC-Motor ansteuern, so geschieht das im einfachsten Fall über zwei Signale:

• PWM-Signal für die Geschwindigkeit des Motors
• Signal für die Auswahl der Richtung

Das PWM-Signal wird dann vom Motorregler verstärkt und mit dem Richtungssignal werden die Transistoren der H-Brücke angesteuert und somit die Polarität am Ausgang des Motorreglers bestimmt.

Für unser Praxisbeispiel wählen wir einen einfachen Arduino-Sketch aus den Bespielprogrammen für unseren Experimentier-Roboter RoverRom B3000, der aber auch mit jedem Arduino funktioniert. Standardmäßig werden dabei die folgenden IO-Pins verwendet:

Wir verbinden die entsprechenden Pins des Arduinos über Jumper-Kabel mit den Kanälen 0 bis 3 des LA1016 und stecken eine GND-Leitung des LA1016 auf den Masseanschluss des ISCP-Ports:

Damit wir die Zuordnung der Kanäle auch sofort erkennen können, vergeben ich für die Kanäle noch entsprechende Bezeichnungen:

Da wir die Taktfrequenz des PWM-Ausgangs nicht kennen, lassen wir die Abtastrate von 1 MHz und und 1 MSample Speichertiefe zunächst einmal so wie sie eingestellt ist.

Das Arduino-Programm lässt sich über die serielle Schnittstelle steuern:

Die minimale Geschwindigkeit erzeugt ein PWM-Tastverhältnis von 60:256 also ca. 23,5 %, die maximale Geschwindigkeit natürlich 100 % und für die mittlere liegt der Wert bei 50 %.

Nach dem Starten des Programms sind die Geschwindigkeit und die Richtung auf "0" gesetzt, wir würden also nichts erkennen, deshalb setze ich den rechten Motor mit dem Befehl s auf halbe Geschwindigkeit in Vorwärts-Richtung.

Zurück im Virtual Instruments Studio drücke ich auf "Start" und erhalte das folgende Bild:

Die Richtung ist auf "1" aber die Geschwindigkeit auf "0", das deutet daraufhin, dass die Zeitbasis viel zu klein gewählt ist und ich scrolle mit dem Mausrad, um die Anzeige zu vergrößern. Danach sehe ich das folgende Bild:

Eine Messung des PWM-Signals zeigt: es handelt sich um ein 1-kHz-Signal, das vom Arduino-Befehl "analogWrite" standardmäßig erzeugt wird. Für eine Motorsteuerung ist das nicht gerade ideal, aber für Versuche reicht es durchaus. Aber Sie können sehr schön erkennen, dass wir mit einem Logikanalysator schon ein wenig tiefer in die internen Abläufe einsteigen können. Auch das Tastverhälntis "duty cycle" wird mit 50,43 % angegeben, was den realen Verhältnissen entspricht.

Wir haben jetzt einfach auf Start gedrückt und sind so mitten ins Geschehen gesprungen. Wenn wir aber z. B. genau den Moment unter die Lupe nehmen möchten, wenn der linke Motor eingeschaltet wird, brauchen wir die Triggerlogik. Die finden wir über den kleinen Button mit dem Kreuzchen bei jedem Kanal. Ein Klick darauf öffnet das folgende Fenster:

Ist keine der vier kleinen Boxen aktiviert, ist auch kein Trigger aktiv. wählen können wir (v. l. n. r.) zwischen:

• steigende Flanke
• Pegel auf "1"
• fallende Flanke
• Pegel auf "0"

Warum brauchen wir eine Flanken- und eine Pegeldefinition? Wenn ich auf eine steigende Flanke triggere wäre das doch praktisch auch ein High-Pegel? Anders sieht es allerdings aus, wenn wir Trigger-Bedingungen kombinieren.

Die obige Trigger-Bedingung erreichen wir durch die folgende Einstellung der beiden Trigger-Buttons für Kanal 0 und 1:

Jetzt müssen wir den Logkanalysator erneut starten und es passiert zunächst nichts, bis auf die Tatsache, dass die Status-LED am LA1016 schnell blinkt. Damit signalisiert sie uns, dass der Trigger schaft geschaltet ist und der Analysator auf ein passendes Event wartet. Im VIS wird das durch die folgende Anzeige sichtbar gemacht:

Um zu testen, ob das Ganze klappt, gebe ich jetzt den Befehl "j" ein, mit dem der linke Motor mit langsamer Geschwindigkeit gestartet werden sollte. Der Trigger löst aus und wir sehen das folgende Ergebnis:

Kurz bevor die Geschwindigkeit auf ca. 23,8 % eingestellt wird (der theoretische Wert war 23,5 %) geht das Richtungssignal auf "high". Es läuft also alles so, wie wir uns das in der Theorie auch gedacht hatten. Der Zeitpunkt des Triggerns wird im Logikanalysator bei "0 s" angegeben, 1/10 des Speichers wird als Pretrigger verwendet, 9/10 enthalten die Messwerte, die nach dem Auftreten des Triggers aufgezeichnet wurden.