[Asuro] Berechnmung der Tic's in 'go()'

[helmut_w]

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

[Sternthaler]

Hi,
hier dann mal meine Asuro-Dimensionen:

Rad-Durchmesser: 38,2 mm --> *PI = 120 mm/Umdrehung
(Ist das Ding schon abgefahren? Oder muss ich mal Luft nachfüllen?)
Untersetzung auch 5/1
Schwarze Segmente: hoppla, nicht 6, sondern 8, also 16er-Teilung
(Die 2.te beigelegte Scheibe hat 4 mal schwarz, also 8er-Teilung. Den Asuro hatte ich vor ca. 2 Jahren gekauft.)

Damit also bei mir:
Die Strecke für einen Tic:
= 120 : 5 : 16
= 1,5 mm
Nun ist also klar warum bei meinem Asuro die Strecken nicht passten.

Aber genau dafür gibt es ja den Thread ASURO emittelt Werte für Lib V2.70 myasuro.h selber

Das Programm liefert mir, bei pingeliger Streckenmessung, 15150 als Wert für den Umrechenfaktor.
Liegt also dann bei 1.515 mm/Tik. Kann man echt nicht meckern.

Hier noch eine Anmerkungen zu deinem Eintrag im AREXX-Forum:
- Die Variable encoder[] als volatile zu definieren ist richtig. Wird in der Lib neue Asuro Lib V2.70 (Release Candidate 3) geändert.