Übersichtlichkeit des Blockdiagramms

(03.01.2012 23:25 )BioLauri schrieb:  ...
Danke für den Link über die State Machine. Das hilft mir aber nichts, da ich mit der State Machine einfach nur einen State nach dem anderen abarbeiten würde. Das bringt m.E. nichts, da das mehr Aufwand ist, als ohne.

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
...
[Offtopic: gibt es eine Möglichkeit, Datenleitungen zu beschriften, dass beim Hover ein Tooltip erscheint?]
...
Rechtsklick auf die Datenleitung und "Description and Tip..." klicken

Hoffe das hilft dir weiter!

Gruss Marc

Anzeige

Hallo Lauri,

Zitat:Das hilft mir aber nichts, da ich mit der State Machine einfach nur einen State nach dem anderen abarbeiten würde. Das bringt m.E. nichts, da das mehr Aufwand ist, als ohne.

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"...

Zitat:Der Grund für die vielen Datenleitung ist der, dass ich ganz einfach die Ports für Sensoren & Motoren, sowie Geschwindigkeit, Raddurchmesser und Fahrtrichtung (für etwaiges Umdrehen der Motoren) für das gesamte Programm ändern kann.

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!

(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?!

Hallo Lauri,

Zitat:Zudem wird es viel Frickelarbeit, wenn ich noch einen Zustand dazwischen einfügen muss.

Eben nicht!
Entweder reicht es, im Befehlsarray (= Liste der aufzurufenden States) einen Befehl an gewünschter Stelle einzufügen oder man definiert einfach einen neuen State und fügt dessen "Befehl" an gewünschter Stelle in die Befehlsliste ein...
Welcher dieser Schritte ist für dich "Gefrickel"?

Zitat:Aber er kennt keine Enums.

Dann würde ich einfache (und evtl. möglichst kurze) Strings empfehlen. Falls das NEXT auch die nicht mit einer Case-Struktur auswerten kann, würde ich einfache U8-Zahlen verwenden, zusammen mit einer schriftlichen Zuordnung von Befehl(-sklartext) und Nummer...

Hallo,

Schande über mich!

Tut mir Leid, dass ich so lange nicht geantwortet habe...
Danke für die Tips.

Das Problem mit der State Machine beim NXT ist eben, dass er nur Ring-Konstanten, keine Enums verstehen kann. Dadurch ist die Beschreibung der Case-Struktur nur eine Zahl und sie passt sich auch nicht automatisch dem Eingangstyp an. Das meinte ich, dass es Frickelarbeit ist, weil man da leicht durcheinander kommt, falls man was dazwischen einfügt.
Ich hab das Problem schon NI Deutschland gesagt. Ich hoffe mal, dass demnächst da was gemacht wird.

Vielen Dank für die Hilfe allen beteiligten!