(04.01.2012 07:58 )Y-P schrieb: Mir tun die Augen weh. 
Tut mir Leid. Ich hoffe, es ist reversibler Schaden?
(04.01.2012 07:58 )Y-P schrieb: Hast Du schon mal an Arrays oder Cluster gedacht?
Das Problem ist, dass der NXT nicht alle Cluster- & Array-Methoden kann. Z.B. Die ganzen "ByName"-Funktionen sind nicht verfügbar.
Außerdem weiß ich nicht, wie schnell der NXT Cluster bearbeitet, bzw. sie aufsplittet für einen bestimmten Wert. Hat da jemand eine Ahnung?
(04.01.2012 09:06 )M Nussbaumer schrieb: Dieser zusätzliche (kleinen) Aufwand nehme ich gerne jederzeit auf mich, wenn ich dadurch meinen Code besser strukturieren kann. Ich persönlich finde den Aufwand etwa dein Blockdiagramm zu analysieren viel grösser
Falls das ganze als Sequenz abgearbeitet wird kannst du es auch über eine solche Pseudo-Statemachine lösen:
Vorteil ist, dass du die einzelnen Schritte beliebig umordnen und oft verwenden kannst ohne Code zu duplizieren (Wie etwa deine Lichtsensor-Abfrage). Ausserdem sind die Cases mit guten Namen schon ein Teil der Dokumentation (meine Meinung), oder zumindest lässt sich dein Code wesentlich besser verstehen und ist platzsparender
Die Idee mit der Pseudo-Zustandsmaschine gefällt mir nicht mal schlecht.
Danke!
Allerdings sieht die Realisierung deutlich schwieriger aus, das der NXT nur wenige Strukturen zur Verfügung stellt:
For-Schleifen sind ihm z.B. unbekannt, wäre nicht allzu tragisch, da kann man mit der While-Schleife rumfrickeln.
Aber er kennt keine Enums. D.h. ich müsste mit einer Ring-Konstante arbeiten, was aber sehr viel mehr Aufwand ist, da sich die Case-Struktur nicht daran anpasst. Da wird außerdem sehr schlecht durchschaubar, an welchem Zustand ich gerade arbeite. Zudem wird es viel Frickelarbeit, wenn ich noch einen Zustand dazwischen einfügen muss.
Zustand hab ich hier aufgrund der Zustandsmaschine mit Case/Fall gleichgesetzt.
(04.01.2012 09:06 )M Nussbaumer schrieb: Rechtsklick auf die Datenleitung und "Description and Tip..." klicken
Danke, zeigt aber kein Tooltip an. In der Kontexthilfe ist ein kleiner Vermerk. Der ist aber nicht markant, d.h. man muss ihn erst suchen. Das Eingabefeld "Tip" ist ausgegraut...
(04.01.2012 09:28 )GerdW schrieb: 1) Bisher arbeitet dein Programm auch schon alles "eins nach dem anderen" ab, ohne dass da irgendeine Verzweigung aufgrund irgendwelcher Entscheidungen angedacht ist.
2) Du musst bisher auch schon jeden Schritt deines Roboters programmieren, dies bleibt bei der Statemachine gleich. Aber wenn du das einmal gemacht hast, kannst du jeden Schritt beliebig oft in beliebiger Reihenfolge aufrufen - und das ganze auch noch mit übersichtlichen Strukturen a la "Befehl; Parameter"...
Es ist so beabsichtigt und erwünscht, dass ich keine Verzweigung habe. Deswegen habe ich die Zustandsmaschine anfänglich auch abgelehnt.
Das Problem ist, dass ich fast keine Wiederholung habe (mit Ausnahme der bisherigen Sub-VIs). Insofern habe ich nur den Übersichtlichkeitsvorteil der Zustandsmaschine, wenn da nicht die NXT-Einschränkungen wären...
(04.01.2012 09:28 )GerdW schrieb: Alle Grundparameter, die sich womöglich während des Programmlaufs nicht mehr ändern, gehören in einen (gut benannten und am besten typdefinierten) Cluster. Nur noch eine einzige Leitung mit allen Parametern, auf die im subVI per UnbundleByName zugegriffen wird!
Ja, das ist prinzipiell eine gute Idee.
Ich hoffe, ich bin nicht zu müde und übersehe die wichtigsten Dinge?!
