Konfigurationshinweise für Steppermotoren

Steppermod und Freqmod

Für Steppermotoren gibt es 2 Ausgangsmodule:

• steppermod.o
• freqmod.o

Steppermod ist das historisch ältere Modul und gibt ohne jede Regelung die Takte aus. Weil Steppermod keine Regelparameter benötigt, ist es sehr einfach zu konfigurieren. Es braucht keine Werte für p,i,d, ff0, ff1, ff2 usw. Ein minimale Steppermod-Konfig im Abschnitt EMCMOT sähe so aus:

; Motion control section ------------------------------------------------------
[EMCMOT]

; Platform for motion
PLAT =                  realtime

; Name of motion control program
EMCMOT =              steppermod.o

; Key for real OS shared memory, e.g., for simulated motion
SHMEM_KEY =             100

; Base address for physical shared memory, e.g., for real-time motion.
; Note that if you change this, you may need to change OS parameters, e.g.,
; /etc/lilo.conf
SHMEM_BASE_ADDRESS =    0x1F00000

; Address for parallel port used for steppers
IO_BASE_ADDRESS =    0x378

; Timeout for comm to emcmot, in seconds
COMM_TIMEOUT =          1.0

; Interval between tries to emcmot, in seconds
COMM_WAIT =             0.010

Der einzige Wert, der einzustellen ist, ist die IO_BASE_ADDRESS, 0x378 für LPT1 und 0x278 für LPT2.

Schön und gut, wozu dann noch Freqmod? Freqmod benutzt intern einen PID-Regler. Weil keine äußeren Istwertgeber vorhanden sind, wird dies intern simuliert. Wozu eine Regelung, wenn man gar nicht wirklich etwas regeln kann? Auch wenn man keine Istwertgeber hat, so kann man doch über die Einstellung von P, I, D die Charakteristik der Pulsausgabe an den Stepper beeinflussen. Und damit kann man z.B. die Motoren zu einem besseren Lauf verhelfen, z.B. wenn Resonanzprobleme auftreten.

Theoretisch sollte also Freqmod die bessere Alternative sein, die mehr kann. In der Praxis ist jedoch Freqmod sehr schwer zu konfigurieren. Man braucht Basiswissen über PID-Regler. Auch sind verschiedene Parameter schlecht beschrieben (FF0, FF1, FF2). Fehlkonfigurationen führen zu völlig unbrauchbarem Motorverhalten. Wie sämtliche Parameter miteinander zusammenhägen und wie man sie genau einstellen muss, dass scheint niemand richtig zu wissen. Zumindest findet sich nichts wirklich ausführliches im Netz.

Wer sich den ganzen Ärger mit der Konfiguration erstmal sparen will, setzt also Steppermod ein. Leider ist es nun so, dass gerade auf der Live-CD Steppermod fehlt. Das liegt an der Umstellung des Realtime-Kernels von rtlinux auf RTAI. Mit RTAI läuft steppermod nicht. Ich hoffe, es findet sich bald jemand, der steppermod auch wieder unter RTAI lauffähig macht. Wer trotzdem Steppermod einsetzen will, sollte die derzeitige Installationsversion BDI 2.20b verwenden (04/2004).

Wer doch freqmod einsetzen möchte, hier ein paar Hinweise von WinfriedMueller:

• Beginne mit P = 1000 oder höher, I=0, D=0, FF0=0, FF1=0, FF2=0, MAX_OUTPUT=1000, MIN_OUTPUT=-1000
• DEADBAND sollte etwas größer als 1/OUTPUT_SCALE sein
• INPUT_SCALE und OUTPUT_SCALE müssen immer gleiche Werte haben
• FERROR = 1.000, MIN_FERROR = 0.500
• P, I, D, FF0, FF1, FF2 lassen sich direkt auf der TKEMC Oberfläche (Calibration) für jede Achse verstellen, das ist gut zum ausprobieren. Später muss man sich von Hand in die emc.ini speichern.
• Maximale Achsengeschwindigkeit einstellen, die man fahren möchte und dann den P-Wert soweit verringern, bis following Errors auftreten. Dann wieder ein wenig erhöhen, so dass keine Fehler mehr auftreten. Dies bewirkt, dass die Ausgangssignale viel sauberer und genauer werden, was man am Motorsound hört.
• FF0, FF2 scheinen keine positiven Effekte zu haben. Mit FF1 kann man rumspielen und schauen, ob sich irgendwelche Verbesserungen einstellen.
• MAX_OUTPUT und MAX_INPUT (nur über emc.ini erreichbar) setzt man so klein, dass noch keine following errors bei maximaler Geschwindigkeit auftreten.
• DEADBAND muss so eingestellt werden, dass die Motoren in Ruhe nicht um einige Schritte wackeln sondern wirklich stehen. Auf jeden Fall etwas größer als 1/OUTPUT_SCALE.
• FERROR und MIN_FERROR kann man noch weiter verringern, so dass noch keine following errors auftreten.
• Ein geringer D-Wert könnte sinnvoll sein, da dieser die Schrittmotoren schneller loslaufen lässt. Schrittmotoren können ja auch eine gewissen spontanen Geschwindigkeitsänderung folgen, ohne abzureißen.

Unipolare Schrittmotoren (Four-Phase-Mode)

Mindestens freqmod.o und steppersegmod.o unterstützen die direkte Ausgabe des Schrittmusters für unipolare Schrittmotoren auf den Parallelport. D.h. man braucht keine "intelligenten" Treiber ICs sondern nur eine Endstufe. Den bisher einzigen Hinweis darauf, das das möglich ist, habe ich im Integrators Handbook bei den Anschlussbelegungen, und natürlich im Sourcecode gefunden. Deshalb hier ein Paar Tipps, wie man das zum laufen bekommt.

Aktiviert wird das Feature über den STEPPING_TYPE=3 in der EMCMOT Sektion. Die Schrittmuster werden für die Achsen X und Y über die normalen Datenleitungen des Parallelports ausgegeben. Dabei bedeutet ein High auf der Leitung, das die entsprechende Phase eingeschaltet sein soll. Für die Z-Achse kommen die Schritte aus 4 Steuerleitungen (sh. Integrators Handbook). Dabei ist dem Programmierer aber anscheinend ein Fehler unterlaufen, denn die Bits für die Z-Achse sind invertiert (im Gegensatz zu denen für X und Y). Mann muss also beim Bau der Treiber darauf achten, das diese 4 Bit nochmal invertiert werden. Sonst hat man sehr wenig Drehmoment auf der Z-Achse und verbrät eine Menge Strom.

Es wird immer der Halbschrittbetrieb benutzt, ein Blick in den Sourcecode gab keine Hinweise darauf das man das ändern könnte.

Ansonsten konfiguriert sich das ganze genau wie jeder andere STEPPING_TYPE.

Minimill oder Bridgeport

Es gibt zwei unabhängige Task- und IO-Module:

• bridgeportio und bridgeporttask
• minimillio und minimilltask

Diese müssen immer zusammenpassend definiert werden (minimillio läuft nicht mit bridgeporttask). Wenn man nur eine parallele Schnittstelle hat, braucht man die Minimill-Module. Möchte man die erweiterten Funktionalitäten, die über die zweite parallele Schnittstelle verfügbar werden, braucht man Bridgeport.

Ein typischer Anfangsfehler ist, nur eine parallele Schnittstelle zu haben, aber bridgeport zu nutzen. Dann bekommt man die Maschine nicht aus dem Estop heraus, weil versucht wird, den Notaus auf LPT2 zu lesen.

PERIOD-Wert

Wenn man das Module Freqmod verwendet, muss PERIOD richtig eingestellt sein. Nutzt man steppermod, darf es nicht in der in der emc.ini auftauchen.

Es scheint so zu sein, dass die maximale Ausgangsfrequenz, die freqmod erzeugen kann = 1/(PERIOD * 2) ist. Hat man also PERIOD auf einen typischen Wert von 0.000020 eingestellt, wären das 25000 Hertz. PERIOD definiert, wie oft in die Interrupt-Routine eingesprungen wird, die die Impulse ausgibt. Wird der Wert zu klein gewählt, ist der Rechner nur noch damit beschäftigt, diese Interrupt-Routine abzuarbeiten. Sobald er dort rausspringt, ist schon wieder genug Zeit vergangen für den nächsten Einsprung. Damit legt man den Rechner lahm, weil kein anderer Prozess mehr Zeit hat, was zu tun. Friert also der Rechner ein, ist das ein Zeichen, dass die Zeitspanne zu klein gewählt wurde.

Interessanterweise hängt es nicht proportional von der Rechnergeschwindigkeit ab, wie klein man den Wert machen kann. Eine 300MHz CPU kommt z.B. mit 0.000020 gut zurecht, während eine 1400MHz Rechner bei 0.000010 schon einfriert. Wer hier Feintuning betreiben möchte, um mit der Ausgangsfrequenz höher zu kommen, sollte bei laufendem emc mal mit dem Befehl top auf einer Konsole nachschauen, wie hoch die CPU-Last im Bereich System ist.

Offene Fragen

Wie stelle ich ein, wieviele Steps pro Millimeter an die Steuerung ausgegeben werden sollen ?

Das soll wohl die Erklärung dazu sein:

• INPUT_SCALE = 40000 0
  • These two values are the scale and offset factors for the axis input from the raw feedback device, e.g., an incremental encoder. The second value (offset) is subtracted from raw input (e.g., encoder counts), and divided by the first value (scale factor), before being used as feedback. The units on the scale value are in raw units (e.g., counts) per user units (e.g., inch). The units on the offset value are in raw units (e.g., counts). Specifically, when reading inputs, the EMC first reads the raw sensor values. The units on these values are the sensor units, typically A/D counts, or encoder ticks. These units, and the location of their 0 value, will not in general correspond to the quasi-SI units used in the EMC. Hence a scaling is done immediately upon sampling: input = (raw - offset) / scale The value for scale can be obtained analytically by doing a unit analysis, i.e., units are [sensor units]/[desired input SI units]. For example, on a 2000 counts per rev encoder, and 10 revs/inch gearing, and desired units of mm, we have [scale units] = 2000 [counts/rev] * 10 [rev/inch] * 1/25.4 [inch/mm] = 787.4 counts/mm and, as a result, input [mm] = (encoder [counts] - offset [counts]) / 787.4 [counts/mm] Note that the units of the offset are in sensor units, e.g., counts, and they are pre-subtracted from the sensor readings. The value for this offset is obtained by finding the value of counts for which you want your user units to read 0.0. This is normally accomplished automatically during a homing procedure.

Meine Motoren machen 200 Schritte pro Umdrehung, das Kugelgewinde macht 5 mm pro Umdrehung, die Treiber 1/8 Mikroschritt.

Muss ich also INPUT_SCALE = 200 * 8 / 5 = 320 setzen setzen ? Den Faktor 1/25.4 in der Anleitung verstehe ich nicht. --ThomasKalka

• 1/25.4 hört sich nach Zollumrechnung in mm an. Ansonsten: Ja, genauso ist es: Du brauchst in deiner Konfiguration 200 * 8 = 1600 Impulse, um die Spindel eine Umdrehung zu bewegen. Das wären dann 5mm Wegstrecke. Für 1mm wären es dann 1600 / 5 = 320. Damit muss INPUT_SCALE auf 320 gesetzt werden. Ebenso OUTPUT_SCALE, was glaube ich bei Steppern immer identisch mit INPUT_SCALE sein muss. -- WinfriedMueller

Tipps