Himmelsrichtug ausrechnen aus X+Y Wert

[deHarry]

Für x = 0.0195 und y = 0.2951 (deine Werte) sagt Bascom bei mir übrigens 86.219429015(°)

Hi Malte,

Super Service, vielen Dank für´s schnelle Ausprobieren!!! (ich hoffe, das war wirklich schnell...)

So, da haben wir doch schon mal ein Schweinderl...
Auf meiner Hardware errechnet Bascom als Winkel 186°. Ich hoffe inständig, dass zwischen Simulation und Hardware kein Unterschied besteht.

Ich tue mich mit meinem Programm etwas schwer mit der Simulation, weil ich mich durch meterweise Menus kämpfen muss und die Navigation im Menu per Hardware-Taster erledige. Das ist Frust erzeugend, wenn man mehrere Werte im Hunderter-Bereich über den Debugger eingeben muss... Das sind die Ausgangswerte, aus denen das Programm die X- und Y-Werte berechnet, aus denen dann der Winkel abgeleitet werden soll.
Ich werde mal ein kleines Testprogramm erstellen müssen, jetzt, wo ich weiß, dass Bascom offenbar auch richtig rechnen kann...

Meine Idee, dass ich durch falsche Deklarationen Speicherbereiche überschreibe, die die Ausgangswerte für die Berechnung halten... Kann ich in Bascom irgendwie (z.B. in einem Listung der Speicherbelegung) überprüfen, ob sowas passiert? Kommen da idealer Weise Warnungen?

[deHarry]

Hallo Malte,

ich habe eben den Fehler gefunden. Mein Gott, kann ein einzelner Mensch vernagelt sein...

Das ist ein Auszug aus meiner Berechnung in BASCOM:

   Part2 = Atn2(yresult , Xresult)
   Korrekturwinkel = Rad2deg(part2)                ' Umrechnung von Radian in Grad

   Winkelint = Korrekturwinkel                     ' Single -> Integer
   Winkel = Str(winkelint)
   C = Len(winkel)
   C = 4 - C                                       ' ein bisschen Voodoo um den Doppelpunkt immer an der gleichen Stelle zu halten

' Werte ausgeben
   Locate 2 , C
   Lcd Korrekturwinkel ; "{223}: " ; Masse ; " - q:" ; Quadrant

Und jetzt des Rätsels Lösung:
Den auszugebenden Winkel will ich als Integer (nur Vorkommastellen) haben. Daher die Umwandlung in einen String, einen besseren Trick kenne ich nicht.
Den Offset "C" errechne ich, damit der Doppelpunkt hinter dem "°"-Zeichen ("{223}") immer in der gleichen Spalte steht.
Habe ich einen zweistelligen Vorkomma-Wert in der Single-Variablen Korrekturwinkel (86,22 z.B.), dann startet die Ausgabe folglich in Spalte 2.
Bei einem einstelligen Wert startet die Ausgabe in Spalte 3.

Jetzt die Stelle, wo es mir den Trick zerrissen hat...
Im Menu-Framework wird die zweite Zeile mit einem Dummywert beschrieben:

Data "Korrekturmasse"
Data "133{223}: 0,333            {003}"         ' "133°: 0,333"

...was zur Laufzeit dann so aussieht:
1. Zeile: "Korrekturmasse"
2. Zeile: "133°: 0,333"

Diese zweite Zeile steht dann im Display, wenn meine Routine bei dem Locate 2, C ankommt.
Das tut sie dann auch, sprich, der Schreibzeiger des Display wird auf Spalte 2 gestellt, und dort wird dann "86" ausgegeben, anschließend noch "°" und der Rest der Werte.
Im Display steht aber "186°:...", weil die "1" einfach stehen geblieben ist
Bei einstelligen Ergebnissen stand dann schon mal einhundertpaarunddreißig im Display (139 statt 9, Differenz 130!!! ) und mein Glaube an das Gute im Atmel ist so nach und nach zwischen die Parkettbohlen diffundiert.

Ich habe mich schon sehr früh über die Differenz von 100 gegenüber den Excel-Ergebnissen gewundert, bin aber immer vor der finalen Erkenntnis irgendwo falsch abgebogen. 100 im Zusamenhang mit Winkeln (nicht Neugrad) erschien mir suspekt, aber es ist ja alles errechnet, also erst mal richtig...

Danke Malte, dass du meine Denke wieder in die richtige Richtung gebogen hast!
Ich habe vor lauter Winkeln und Kreisen den Gesamtblick verloren und nur noch an der Mathematik gezweifelt.