Druckbare Version
Bei mir werden die durch Asuro gesendeten daten nicht von das Windows programm ausgewertet. Links wird nach wählen von der richtigen schnittstelle der text "Break empfangen 1" angegeben. Weiter passiert nichts im Sensoren bereich. Auch nicht wenn ich die tests probiere.
Im Hyperterminal sehe ich aber das daten empfangen werden.
Mache ich etwas falsch?
ich glaube den fehler gefunden zu haben:
auf der netzwerkfestplatte (NAS) stimmte die zeit nicht, weil wir heute mittag einen stromausfall hatten und ich habe die zeit nicht korrigiert.
Kann es sein, dass AVR-studio in so einem fall auch das neuere geändert file nicht nimmt, weil es glaubt bereits ein neueres zu haben (weil das auf dem netz nicht die richtige zeit hat)???
noch eine frage:
kann man in bei der turn() funktion auch winkelminuten angeben?
edit: (90+91)/2 =90,5??
Hallo Petje, eigendlich kann man nicht viel falsch machen. (War zumindest mein Wunsch bei dem Programm.)Zitat:
Zitat von Petje
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.)
Hallo inka,Zitat:
Zitat von 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 :-)
Hallo
Ich verwende zwar nicht die Lib V2.7, aber mir ist schon mehrmals aufgefallen, dass, wenn ich mir Line- oder Ododaten senden lasse, in regelmäßigen Abständen offensichliche Fehllesungen auftreten. Dies passiert sowohl beim direkten Übertragen einzelner Daten sowie auch beim blockweisen Übertragen gespeicherter Werte. Ich vermute, hier spukt irgendein Interrupt rein, ich habe das aber bisher nicht näher untersucht. Vielleicht gibt es da einen Zusammenhang.Zitat:
dass man nur 94% der zu erwartenden Tik's vorgeben darf.
Gruß
mic
@radbruch
In diesem Beitrag ist im Anhang eine EXCEL-Tabelle, mit der Tik's für Bogenfahrten bei beliebigen Winkeln (auch 0 Grad) und Radien berechnet werden. Oben rechts im Blatt (grün hinterlegt) ist diese Prozentangabe. (sind im übrigen 96%).
Erst mit diesen 'Verlusten' konnte ich meinen Asuro dazu überreden die gewünschte Strecke zu fahren.
Auch im Anhang (2 Beiträge vorher), ist das 'Nikolaus'-Programm von mir, wobei dort komplett nur über Interrupts gearbeit wird. Ich bin mir ziemlich sicher, dass in dem Programm keine Probleme mit den Interrupts auftreten, da ich ca. 10 Monate so alles durchgetestet hatte was nur irgendwie geht. (Soll nicht heißen, dass da tatsächlich kein Bug mehr vorhanden ist.)
Von einem Arbeitskollegen, der privat viel mit Lasern und verstellbaren Spiegeln macht, habe ich das gleiche Phänomän gehört, dass seine Positionsgeber (ODO-Scheiben) auch mehr Daten liefern als erwartet. Er hatte mich erst auf die Idee gebracht den Prozentwert im EXCEL-Blatt einzubauen.
Ja. Im moment des anwählen von COM1 erscheint die Meldung. Also direkt.Zitat:
Zitat von Sternthaler
An COM1.Zitat:
Zitat von Sternthaler
Also COM1, 4, 7, 8 und 9 sind aktiv. Beim starten des ASURO-Windows-Programms ist COM9 selektiert. Im moment ich COM1 anwähle kommt auch die Meldung. Aber nur wenn auch der IR-Empfänger angeschlossen ist (logisch). Dabei kann ich auch ausschliessen das der ASURO dieses command sendet denn es passiert auch wenn der ASURO nicht sendet (ausgeschaltet)!Zitat:
Zitat von Sternthaler
Nee, nee, diesen test mit Hyperterminal habe ich gemacht ohne das das ASURO-Windows-Programm aktiv war. Also nur um den IR-Empfänger zu testen. Aber das Ding funktioniert gut weil ich ja ach die ASURO flashen kann ohne probleme.Zitat:
Zitat von Sternthaler
Wie sieht es denn aus mit der Übertragungsgeschwindigkeit der COM1. Hyperterminal muss mann ja auf 2400 baud setzen. Das ASURO-Windows-Programm hat keine einstellungsmöglichkeiten.
Weil ich nie derartige Probleme mit COM1 habe denke ich doch das ASURO-Windows-Programm wertet etwas aus (comBreak) was nicht gesendet wurde.
Könnte es sein das das Programm auf eine spätere VB Runtime Module zugreift die etwas anders funktioniert?
@Sternthaler
die daten sind originalbelassen, absichtlich, weil der asuro (oder ich) anfangs irgendwie mit den werten nicht klarkam.Zitat:
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
definitiv ja. Nachdem ich dort die ortszeit gewählt habe und die zeit extern synchronisieren lasse ist alles wieder so wies sein soll, der asuro fährt sein quadrat...Zitat:
Oder war es doch die Platte im Netz?
mache ich, wenn mich der bevorstehende umzug, alles was in einem 1,5 famileinhaus platz hat in eine - zwar sehr große - wohnung, von Tschechien nach Deutschland (Pirna) am 5/6. juli, dazu kommen lässt. Also werde ich mich vermutlich so in der 2ten dekade juli wieder melden...Zitat:
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.
Habe es jetzt auf meinem Desktop PC probiert und da funktionierte das Programm bis auf Test 5 der Motoausgleich/differenz. Bei diesem Test passiert nichts.
Muss sagen, ein tolles Programm.
Merkwürdig das es auf mein Laptop nicht funktioniert wegen den Combreak Empfang und damit stoppen des Auswerten der Daten.
Hallo Sternthaler,
bei meinen Versuchen mit dem Bluetooth-ASURO bei dem die Encoderwerte über die Funkschnittstelle übertragen werden, konnte ich ein interessantes Phänomen beobachten: Wenn die Motoren ausgeschaltet waren und der ASURO stillstand, gab es trotzdem manchmal den Fall, dass ein Encoder hochgezählt hat. Dies kam nur selten, bei bestimmten Stellungen der Codescheiben vor.Zitat:
Auch im Anhang (2 Beiträge vorher), ist das 'Nikolaus'-Programm von mir, wobei dort komplett nur über Interrupts gearbeit wird. Ich bin mir ziemlich sicher, dass in dem Programm keine Probleme mit den Interrupts auftreten, da ich ca. 10 Monate so alles durchgetestet hatte was nur irgendwie geht. (Soll nicht heißen, dass da tatsächlich kein Bug mehr vorhanden ist.)
Dieser Fehler würde Deine 94% Vorgabe erklären. Bei dem Zählvorgang werden wohl manchmal einige Ticks zuviel gezählt. Vielleicht gibt es doch in der Interruptauswerteroutine ein Problem.
Ein einfacher Test wäre vielleicht, bei jedem Encodertick einen Impuls auf einen Ausgangspin des Atmega8 zu geben und mit einem Speicheroszilloskop zu versuchen, den Ausreißer zu lokalisieren. Falls er regelmäßig kommt, könnte das ja auf einen Konflikt mit anderen Routinen hindeuten.
Immerhin läuft ja der 36Khz Interrupt und der 4Khz? Encoderinterrupt gleichzeitig.
Gruß,
robo