helmut_w
10.07.2007, 11:35
In "encoder.c - V002 vom 27.01.07" von Sternthaler
steht innerhalb der Funktion "go()" unter
"\par Hinweis: ", dass das mit der
'// calculation tics/mm' beim Autor Sternthaler
nicht funktioniert. *)
Wir haben das Ganze für _unseren_ Asuro 'mal
durchgerechnet. Dabei gibt es die folgenden
"Messwerte":
Rad-Durchmesser: 38,5 mm
Untersetzung: 50 Zähne zu 10 Zähne = 5 (: 1)
Schwarze Segmente: 6, also 12er-Teilung
Es stellt sich nun die Frage: "Welche Strecke
fährt unser Asuro bei _einem_ Tic in encoder[0]?
Der Umfang des Rades berechnet sich zu
Durchmesser mal Pi (mit Pi = 3,14..);
und ergibt bei uns ca. 121 mm.
Die Strecke für einen Tic:
************************************************** **
* Umfang : Untersetzung : Gesamt-Teile der Scheibe *
************************************************** **
= 121 : 5 : 12
= 2,0168 mm; also rund 2 mm!
Um nun die Tic's (für "enc_count") für eine
gewünschte Strecke (hier: "distance") zu
bekommen, muss man einfach diese Strecke durch
2 mm (pro Tic!) teilen!
(z.Bsp. 1 m = 1.000 mm : 2 mm = 500 tic's)
Aber warum steht im Programm das Folgende?
// calculation tics/mm
enc_count = abs(distance) * 10000L;
enc_count /= 19363L;
Also "abs(distance)" braucht man, um immer
positive Werte für die Zählung zu bekommen.
Und " : 2 " kann man auch so schreiben: " * 1/2 "
Damit die Berechnung nun _ganz_genau_ wird,
muss ich natürlich auch meine _genaue_ Strecke
für so einen Tic einsetzen, also 2,0168 mm!
Und dass dies auch bei "Integer" funktioniert,
nahm der Programmierer einen "Long-integer"-Wert
(uint32_t mit 4 Byte bzw. 32 bit Länge) und
erweiterte den Bruch "1/2" oben (also im Zähler)
und unten (im Nenner) jeweils mit 10.000L
(um die weiteren 2 Bytes gegenüber dem
"normalen" Int-Wert auszunutzen!)
Damit kommen bei _unserem_ Asuro nun genau 496 tics
'raus; mit den Vorgaben in "encoder.c - V002
vom 27.01.07" sind es 516 tics, weil in diesem
Falle die Strecke pro Tic nicht 2,0168 mm, sondern
1,9363 mm war!:))
*) Vielleicht gibt es beim Asuro von Sternthaler
einen anderen Rad-Durchmesser, oder die zweiten
beigelegten Teilungs-Scheiben wurden verwendet!?
Ich hoffe, dass mit diesen kleinen Ausführungen
nun jeder "Asuro-ianer" sein Programm damit an-
passen kann! (Übrigens gibt es weitere Vorschläge
von SlyD im Arrex-Forum zur _kleinen_ Programm-
Verbesserung unter "[ASURO] Probleme mit der
Variablen 'extern int encoder[2]'".)
cu Helmut
steht innerhalb der Funktion "go()" unter
"\par Hinweis: ", dass das mit der
'// calculation tics/mm' beim Autor Sternthaler
nicht funktioniert. *)
Wir haben das Ganze für _unseren_ Asuro 'mal
durchgerechnet. Dabei gibt es die folgenden
"Messwerte":
Rad-Durchmesser: 38,5 mm
Untersetzung: 50 Zähne zu 10 Zähne = 5 (: 1)
Schwarze Segmente: 6, also 12er-Teilung
Es stellt sich nun die Frage: "Welche Strecke
fährt unser Asuro bei _einem_ Tic in encoder[0]?
Der Umfang des Rades berechnet sich zu
Durchmesser mal Pi (mit Pi = 3,14..);
und ergibt bei uns ca. 121 mm.
Die Strecke für einen Tic:
************************************************** **
* Umfang : Untersetzung : Gesamt-Teile der Scheibe *
************************************************** **
= 121 : 5 : 12
= 2,0168 mm; also rund 2 mm!
Um nun die Tic's (für "enc_count") für eine
gewünschte Strecke (hier: "distance") zu
bekommen, muss man einfach diese Strecke durch
2 mm (pro Tic!) teilen!
(z.Bsp. 1 m = 1.000 mm : 2 mm = 500 tic's)
Aber warum steht im Programm das Folgende?
// calculation tics/mm
enc_count = abs(distance) * 10000L;
enc_count /= 19363L;
Also "abs(distance)" braucht man, um immer
positive Werte für die Zählung zu bekommen.
Und " : 2 " kann man auch so schreiben: " * 1/2 "
Damit die Berechnung nun _ganz_genau_ wird,
muss ich natürlich auch meine _genaue_ Strecke
für so einen Tic einsetzen, also 2,0168 mm!
Und dass dies auch bei "Integer" funktioniert,
nahm der Programmierer einen "Long-integer"-Wert
(uint32_t mit 4 Byte bzw. 32 bit Länge) und
erweiterte den Bruch "1/2" oben (also im Zähler)
und unten (im Nenner) jeweils mit 10.000L
(um die weiteren 2 Bytes gegenüber dem
"normalen" Int-Wert auszunutzen!)
Damit kommen bei _unserem_ Asuro nun genau 496 tics
'raus; mit den Vorgaben in "encoder.c - V002
vom 27.01.07" sind es 516 tics, weil in diesem
Falle die Strecke pro Tic nicht 2,0168 mm, sondern
1,9363 mm war!:))
*) Vielleicht gibt es beim Asuro von Sternthaler
einen anderen Rad-Durchmesser, oder die zweiten
beigelegten Teilungs-Scheiben wurden verwendet!?
Ich hoffe, dass mit diesen kleinen Ausführungen
nun jeder "Asuro-ianer" sein Programm damit an-
passen kann! (Übrigens gibt es weitere Vorschläge
von SlyD im Arrex-Forum zur _kleinen_ Programm-
Verbesserung unter "[ASURO] Probleme mit der
Variablen 'extern int encoder[2]'".)
cu Helmut