INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Übersichtlichkeit des Blockdiagramms



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

04.01.2012, 09:06 (Dieser Beitrag wurde zuletzt bearbeitet: 04.01.2012 09:07 von M Nussbaumer.)
Beitrag #11

M Nussbaumer Offline
Zarathustra
****


Beiträge: 654
Registriert seit: Sep 2009

2009 SP1
2009
EN

6300
Schweiz
RE: Ü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össerBox 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 platzsparenderSmile

...
[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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
04.01.2012, 09:28
Beitrag #12

GerdW Offline
______________
LVF-Team

Beiträge: 17.399
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: Übersichtlichkeit des Blockdiagramms
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!

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
05.01.2012, 03:08
Beitrag #13

BioLauri Offline
LVF-Neueinsteiger


Beiträge: 5
Registriert seit: Jan 2012

9.0.1
2011
DE


Deutschland
RE: Übersichtlichkeit des Blockdiagramms
(04.01.2012 07:58 )Y-P schrieb:  Mir tun die Augen weh. Blink
Tut mir Leid. Ich hoffe, es ist reversibler Schaden? Wink

(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össerBox 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 platzsparenderSmile

Die Idee mit der Pseudo-Zustandsmaschine gefällt mir nicht mal schlecht. Smile 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?!

Viele Grüße,

BioLauri
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
05.01.2012, 09:17 (Dieser Beitrag wurde zuletzt bearbeitet: 05.01.2012 09:19 von GerdW.)
Beitrag #14

GerdW Offline
______________
LVF-Team

Beiträge: 17.399
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: Übersichtlichkeit des Blockdiagramms
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...

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
02.02.2012, 14:53
Beitrag #15

BioLauri Offline
LVF-Neueinsteiger


Beiträge: 5
Registriert seit: Jan 2012

9.0.1
2011
DE


Deutschland
Wink RE: Übersichtlichkeit des Blockdiagramms
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!

Viele Grüße,

BioLauri
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  systematisches ordnen des Blockdiagramms NafeZ 4 3.500 08.07.2009 18:55
Letzter Beitrag: Achim

Gehe zu: