Das wird gerinfügig komlizierter.Zitat von zerebrator
In dem von mir Skizzierten Konstrukt dreht er ja bis die Bedingung des us-Sensors nicht mehr erfüllt ist.
Jetzt hast Du ja us-Sensor Bedingung erfüllt, Entscheidung der Drehrichtung, Bedingung 90° Drehen setzen
Drehen bis 90° Bedingung erfüllt ist unabhängig davon ob us-Sensor Bedingung weiterhin erfüllt ist.
Der Case Abschnitt, darf also nicht mehr selbst das Dehen ausführen sondern muß variablen setzen, die den Systemzustand speichern und über die dann im nächsten Schritt verhindert wird das der us-Case Teil erneut angesprungen wird dafür aber ein 90° Case Teil.
dort wird dann gedreht bis der Winkel entsprechend klein wird und dann mit geringerer Geschwindigkeit weitergedreht bis der Winkel 0 ist.
Wenn die Bedingugn erfüllt dit, werden die Merker wieder gelöscht und der Teil verlassen.
Dann kann wider normal weitergearbeitet werden.
Das Ziel ist dabei halt so Geschickt die Logik aufzubauen, das man sich nicht in endlosen hin und her Springen verzettelt.
Deshalb macht es Sinn sich vor dem Programmierne zu überlegen wass will man denn alles machen und welche Bedingunge nmüssen erfüllt werden.
Asl zweites mauß man sich darüber im klaren sein, daß, damit Sensoren immer wieder eingelesen werdne können das Programm ständig weiterlaufen muß.
Also Endlosschleife.
Damit wird auch der Code wärend einer Aktion tausende male durchlaufen.
Also wo halte ich wie, welchen Systemzustand fest, und verhindere damit das Entscheidungsbäume während einer Aktion immer wieder durchlaufen werden und sich so Werte verschieben oder Aktionen vorzeitig Terminiert werden, weil Eingangsbedingungen mittleriweile nicht mehr erfüllt sind.
delay sollte im Code nirgendswo vorkommen, sondern durch Timer ersetzt werden. so kann der Code durchlaufen werden und während einer Aktion auch andere Eingaben und Ausgaben verarbeitet werden.
Wenn etwas wirklich genau sein soll, muß man über Interrupts nachdenken.
Unter Umständen kann es notwendig sein den gesammten bisher erstellten Code auf den Prüfstand zu stellen und mit dme auge des neu erworbenen wissens zu überlegen ob ein kompletter Neubau nicht sinnvoller ist um schwächen und ausuferndes Volumen auszubügeln.
Wenn das ganze erst mal zu komplex ist, kannst Du Dir auch Anleien bei UML holen und z.B. auf einem Sück Hartschaum mit kleinen Papierkarten die einzelnen Funkionsblöcke mit Stecknadeln feststecken sowie mit bunten Fäden die Abhängigkeiten (alternativ auch ein UML Programm am Computer) aufzeigen.
Nach und nach eränzt man auf den Karten dan ndie Variabeln und erkennt so ob ein vorrausgehendes Modul die auch liefert oder ob eine Variabel nach dem Setzen auch irgendwo wieder gelöscht wird. Oder als Zombie das System blockiert.
Das dann in Code zu bringen ist dann meist der einfachere Teil, da man da schon den meisten Denksport hinter sich hat und (fast) nur noch auf Syntax achten muß.
Zitieren
Lesezeichen