Zitat Zitat von Petje
Links wird nach wählen von der richtigen schnittstelle der text "Break empfangen 1" angegeben.
Im Hyperterminal sehe ich aber das daten empfangen werden.
Mache ich etwas falsch?
Hallo Petje, eigendlich kann man nicht viel falsch machen. (War zumindest mein Wunsch bei dem Programm.)
Die von dir angegebene Fehlermeldung für das MSComm-Element heißt bei Microsoft Visual Basic (VB5 Copyright 1987-1997) wörtlich: "comBreak 1001 Es wurde ein Anhaltesignal (Break-Signal) empfangen.".
(Das Internet hilft mir da leider nicht weiter, was das denn nun eigendlich heissen soll.)
Die dahinterstehende 1 sagt nur, dass das Break-Signal auf der Schnittstelle COM 1 empfangen wurde.

Hast du die COM-Schnittstelle 1 ausgewählt?
An welcher Schnittstelle ist dein IR-Empfänger?
Welche der 10 möglichen COM1 bis COM10 sind bei dir aktiviert?
Ich Suche bis zu 10 Schnittstellen ab, ob sie aktivierbar sind und lasse dann die letzte gefundene Schnittstelle aktiv. Ist bei dir COM 1 aktiv?

Da du das Hyperterminal erwähnst:
Es darf NICHT auf die Schnittstelle zum IR-Empfänger zugreifen, da das ASURO-Windows-Programm diese Schnittstelle dann NICHT benutzen kann.
(Hyperterminal offline oder beenden, danach erst das ASURO-Windows-Programm starten.)

Zitat Zitat von inka
- unterschied der gemessenen werte:
bei go 12er - 20740 /18er - 14115
bei rurn 12er - 147 / 18er - 227
... ist die gefahrene strecke aber kürzer und der winkel nicht 90, sondern ca.70 grad.
Hallo inka,
mir kommen deine angegeben Werte ganz ok vor.
Mit dem guten alten Dreisatz bei deinen go-Werten komme ich mit der Rechnung: 12 / 14115 * 20740 auf 17,63 was also recht nahe an 18 liegt.
Bei den turn-Werten gerechnet: 12 / 147 * 227 = 18,53 anstatt 18, also auch 'halbwegs' dicht dran.
Bei meinem Asuro mit den 16er-Scheiben rechnet sich das dann so:
go 16er - 15150 --> 12 / 15150 * 20740 = 16,42 (akzeptabel)
turn 16er - 212 --> 12 / 147 * 212 = 17,3 (würde ich ein bisschen in Frage stellen)

Du sagst sowohl bei der Strecke, als auch beim Winkel, das der Asuro zu wenig fährt. Wie geht das? Der Asuro hört ja auf die Räder zu drehen, wenn er 'meint' genügend Tik's gesehen zu haben.
Da wir bei Go() eine Division durch den ermittelten Wert machen, um die zu fahrende Tik-Anzahl zu berechnen, ist es also schon mal richtig, dass der Wert bei der 18er-Scheibe kleiner werden muss. Schließlich wird dadurch die zu fahrende Tik-Anzahl mathematisch größer, was ja auch zu erwarten ist bei mehr SW-Wechseln auf der Scheibe.

Somit müssen 'irgendwie' mehr Tik's gesehen werden, als eigendlich zu erwarten sind. Hätte ich jetzt irgendwie anders erwartet.
Allerdings hatte ich dieses Problem auch schon mal nachgewiesen beim 'Nikolausfahren'. Ich bin dort darauf gekommen, dass man nur 94% der zu erwartenden Tik's vorgeben darf. Also auch da schon: Es kommen mehr Tik's als erwartet!
Wie groß sind denn die Werte für MY_ODO_???_Value_[L|R] bei dir?
Ist der Unterschied klein? Das würde auf eine große Fehlerrate, und damit auf mehr Tik's schliessen lassen.

Es wäre aber echt interressant, mal das von ehenkes vorgeschlagen Programm von Arexx-Henk aus dem Beitrag zu testen und ein Bildchen aus den Messdaten machen.

Oder war es doch die Platte im Netz? [-o<

@inka
Ich sehe gerade deine Frage zu den Winkelminuten.
Nein, das geht nicht, da der Winkelwert ja nur als int-Variable an die Funktion weitergegeben wird.
Hochgenaue Präzisionsfahrten erwarten wir nur bei Mars-Robotern, und nicht bei Asuros ohne Raketenantrieb, die 18er-Scheiben drauf haben