Übersichtlichkeit des Blockdiagramms

Hallo liebes Forum!

Erst einmal: vielen Dank für die bisherige Hilfe (deswegen hab ich mich glatt angemeldet).

So, nun zu meinem Problem:
Ich suche nach einer Möglichkeit, das Blockdiagramm übersichtlich zu gliedern. Z.B. mit Rahmen o.Ä.
Leider habe ich keine Möglichkeit (außer evtl. die Rechtecke des Frontpanels zu missbrauchen) gefunden. Das hat aber leider den Nachteil, dass beim automatischen Aufräumen um den Bereich herum aufgeräumt wird.
Bisher hatte ich es mit einer flachen Sequenzstruktur gelöst, da ich nur für den NXT (Roboter von LEGO; Programmierbar mit dem LabVIEW NXT Module) programmiere und der sowieso keine parallelen Ausführungsstränge kann. Allerdings unterstützt der NXT keine flachen Sequenzstrukturen mit mehreren Rahmen (zumindest nicht, wenn man es auf den NXT laden will und nicht vom PC aus), wodurch diese Methode leider wegfällt.

Die flache Sequenzstruktur war eigtl optimal dafür, da ich sehr viele Werte durchschleifen muss und durch Anfügen eines neuen Rahmens automatisch alle Anschlüsse weitergeführt werden. Außerdem kann man jeden Rahmen einzeln beschriften (mittels Kommentaren) und so ist das ganze sehr übersichtlich, da die Kommentare nur innerhalb des Rahmens verschoben werden, so kann man aber immer noch jedem Rahmen einen Kommentar zuordnen.

Ich hoffe, mein Problem halbwegs verständlich beschrieben zu haben.
Falls es noch nachfragen gibt, helfe ich gerne - muss allerdings erst einmal ein wenig den PC verlassen.

Ich wünsche eine erholsame Nacht (oder was davon übrig bleibt) und nachträglich noch ein gesundes neues Jahr!

(03.01.2012 03:12 )BioLauri schrieb:  Hallo liebes Forum!

Erst einmal: vielen Dank für die bisherige Hilfe (deswegen hab ich mich glatt angemeldet).

So, nun zu meinem Problem:
Ich suche nach einer Möglichkeit, das Blockdiagramm übersichtlich zu gliedern. Z.B. mit Rahmen o.Ä.
Leider habe ich keine Möglichkeit (außer evtl. die Rechtecke des Frontpanels zu missbrauchen) gefunden. Das hat aber leider den Nachteil, dass beim automatischen Aufräumen um den Bereich herum aufgeräumt wird.
Bisher hatte ich es mit einer flachen Sequenzstruktur gelöst, da ich nur für den NXT (Roboter von LEGO; Programmierbar mit dem LabVIEW NXT Module) programmiere und der sowieso keine parallelen Ausführungsstränge kann. Allerdings unterstützt der NXT keine flachen Sequenzstrukturen mit mehreren Rahmen (zumindest nicht, wenn man es auf den NXT laden will und nicht vom PC aus), wodurch diese Methode leider wegfällt.

Die flache Sequenzstruktur war eigtl optimal dafür, da ich sehr viele Werte durchschleifen muss und durch Anfügen eines neuen Rahmens automatisch alle Anschlüsse weitergeführt werden. Außerdem kann man jeden Rahmen einzeln beschriften (mittels Kommentaren) und so ist das ganze sehr übersichtlich, da die Kommentare nur innerhalb des Rahmens verschoben werden, so kann man aber immer noch jedem Rahmen einen Kommentar zuordnen.

Ich hoffe, mein Problem halbwegs verständlich beschrieben zu haben.
Falls es noch nachfragen gibt, helfe ich gerne - muss allerdings erst einmal ein wenig den PC verlassen.

Ich wünsche eine erholsame Nacht (oder was davon übrig bleibt) und nachträglich noch ein gesundes neues Jahr!

Herzlich Willkommen BioLauri

Ich weiss nicht, welche Funktionen bei diesem Modul möglich sind. Grundsätzlich würde ich dir aber zu einer state machine raten.

Vorteil gegenüber deiner Lösung mit der flachen Sequenz ist, dass zusätzlich der Case bzw der Rahmen noch sinnvoll benennt werden kann. Auch ist die Erweiterbarkeit wesentlich erhöht, da du einfach nur den Ablauf der Enums ändern musst und nicht die ganze Sequenz umstellen musst.

Der Rest ist so wie du es dir wünscht, genug Platz um die einzelnen Funktionen zu beschreiben. Zudem kann ein gut gewählter state-name schon vieles selbst erklären.

Hoffe das hilft dir weiter!

Gruss Marc

Hallo Lauri,

Zitat:Ich suche nach einer Möglichkeit, das Blockdiagramm übersichtlich zu gliedern.

Die allererste Möglichkeit einer Gliederung stellen subVIs dar. Sollte eigentlich im unten verlinkten Tutorial erläutert sein...

P.S.:
@Marc: Man erkennt doch recht deutlich den Beginn der "üblichen" Arbeitszeit

(03.01.2012 08:15 )GerdW schrieb:  @Marc: Man erkennt doch recht deutlich den Beginn der "üblichen" Arbeitszeit

Voll ins Schwarze

Gruss Marc

Unterstützt denn die Programmierung für den NXT SubVIs?

Ansonsten denke ich, dass der NXT schon parallele Tasks verarbeiten kann: Der laufende Roboter zeigt auf dem Display ein schlagendes Herz während parallel dazu die Füße bewegt werden.

Ansonsten hilft noch ein strukturierteres Vorgehen bei der Programmentwicklung und manuelles Blockdiagramm Aufräumen, so dass das automatische Aufräumen nicht angewendet werden muss.

Für Labview-Anfänger, wenn sie hier im Forum ihr VI posten, sind drei Sachen typisch:

1. Exzessive Verwendung von Sequenzstrukturen
2. Riesenhafte BDs in vielfacher Bildschirmgröße, oft mit ganz wenig Code drin, aber den im wüsten Durcheinander.
3. Flächenfressende Strickmuster mit immer dem gleichen Code
   

zu 1.
Man begreift das Datenflußprinzip und die parallele Verarbeitung nicht als Vorteil und Chance, sondern man versucht damit Labview in das Korsett einer normalen, am Programm-Textfluß orientierten Sprache zu zwingen.
zu 2.
Das liegt u.a, daran, daß man sich mit den Werkzeugen "Objekte anordnen", "Objekte ausrichten", "Verdrahtung bereinigen" noch nicht vertraut gemacht hat oder diese Werkzeuge überhaupt nicht kennt. Ich arbeite z.B ständig damit, nicht erst bei der finalen Verschönerung.
zu 3.
Das läßt sich mit Scheifenstrukturen, Cluster- oder Arraybidung oder speziellen Funktionen fast immer vermeiden. Es ist auch Anfängern zu wenig bekannt, daß die meisten Funktionen polymorph sind. Um mathematische Operationen an einem Array auszuführen, braucht man z.B. keine Schleifenstruktur.

Anzeige

Vielen lieben Dank allen Antwortern für ihre Antworten.
Ich bin sehr erfreut überrascht, wie schnell das geht.

Den Artikel über die State Machine lese ich mir noch durch - hab aber gerade nur Zeit für eine kurze Antwort.

Sub-VIs setze ich schon sehr eifrig ein. Sind äußerst praktisch und vereinfachen den Code enorm.
Das NXT Modul unterstützt Sub-VIs vollkommen, sofern sich innerhalb auch nur NXT-kompatibler Code befindet.

Bzgl. der Parallelität: Der NXT kann Quasi-Parallelität. Er hat nur einen Prozessor und schaltet bei Parallelen Programmen zwischen den einzelnen Threads hin & her. Da das Hin & Herschalten allerdings mehr Zeit kostet, als wenn alles nacheinander ausgeführt wird, verwende ich eben keine Parallelität.
Wirkliche Parallelität funktioniert mit den Motoren, da an diese nur einmalig der Befehl gesendet werden muss, alles weitere führen die Motorcontroller durch. Dadurch kann man auch wirklich parallel eine Display-Anzeige und bewegende Füße verwenden.

Selber aufräumen und anordnen finde ich sehr nervig, da ich es wichtiger finde, dass das Programm funktioniert, als dass es schön aussieht. Ich dachte mir, dass es eine relativ einfache Lösung gäbe.

Bezogen auf den letzten Post:
Zu 1.: Das Problem ist, dass es beim NXT keinen Vorteil gibt, wenn er quasiparallel rechnet. Zudem ist es bei meinen Programmen nicht notwendig. Daher "zwinge" ich ihn dazu. Ist übrigens vom NXT Modul von vornherein vorgesehen, dass man sequenziell arbeitet, da alle (brauchbaren) NXT-VIs einen Sequence-Flow Ein- & Ausgang haben, durch den automatisch die Parallelität unterbunden wird.
Dieser hilft mir aber leider nicht bei der Übersichtlichkeit...

Zu 2.: Diese Funktionen habe ich mir tatsächlich noch nicht näher angeschaut. Ich werde es aber heute abend gleich einmal tun!

Zu 3.: Ja, ich habe sehr viele Datenleitung (16 Stück an der Zahl), aber es bringt mir nichts, wenn ich da welche zu einem Array zusammenfasse, weil der NXT dann für die Array-Operationen länger braucht und das kostet mich Zeit.

Es sind übrigens alles konstante Werte.


So: Vielen lieben Dank für die bisherige Hilfe. Ich hoffe, es gibt noch ein paar weitere Tips!

(03.01.2012 17:53 )BioLauri schrieb:  ...
Selber aufräumen und anordnen finde ich sehr nervig, da ich es wichtiger finde, dass das Programm funktioniert, als dass es schön aussieht. Ich dachte mir, dass es eine relativ einfache Lösung gäbe.
..

Nun, um den Code später noch einmal nachzuvollziehen oder wenn jemand anderes ihn verstehen soll, ist Ordnung und eine gewisse Ästhetik notwendig. Das solltest nicht vernachlässigen.

Mir ist im Gegenteil schon aufgefallen, dass Code, der sich nicht ästhetisch anordnen lässt auch schlechter Code war. Also die Ästhetik des Blockdiagramms ein Maß für die Qualität des Codes ist.

(03.01.2012 17:53 )BioLauri schrieb:  ..
Es sind übrigens alles konstante Werte.
..

Dann braucht es aber auch keine flache Sequenz!

---

(03.01.2012 10:24 )Lucki schrieb:  Für Labview-Anfänger, wenn sie hier im Forum ihr VI posten, sind drei Sachen typisch:

1. Exzessive Verwendung von Sequenzstrukturen
2. Riesenhafte BDs in vielfacher Bildschirmgröße, oft mit ganz wenig Code drin, aber den im wüsten Durcheinander.
3. Flächenfressende Strickmuster mit immer dem gleichen Code
   

zu 1.
Man begreift das Datenflußprinzip und die parallele Verarbeitung nicht als Vorteil und Chance, sondern man versucht damit Labview in das Korsett einer normalen, am Programm-Textfluß orientierten Sprache zu zwingen.
..

Oftmals sind die Sequenzen völlig überflüssig, weil die Werte über Drähte ohnehin weitergereicht werden oder werden könnten.

zu 2.
Oder durch das automatische Wachsen der Strukturen riesengroß werden. Das sollten Anfänger besser abschalten und sich lieber über das manuelle Platzmachen ärgern, bis sie merken, das Code nicht kopiert sondern in SubVIs gepackt wiederverwendet werden sollte.

(03.01.2012 21:53 )unicorn schrieb:  

(03.01.2012 17:53 )BioLauri schrieb:  ...
Selber aufräumen und anordnen finde ich sehr nervig, da ich es wichtiger finde, dass das Programm funktioniert, als dass es schön aussieht. Ich dachte mir, dass es eine relativ einfache Lösung gäbe.
..

Nun, um den Code später noch einmal nachzuvollziehen oder wenn jemand anderes ihn verstehen soll, ist Ordnung und eine gewisse Ästhetik notwendig. Das solltest nicht vernachlässigen.

Ja, natürlich. Ich finde übersichtlichen Code auch sehr wichtig. Ich meinte das nur als relative Angabe. Und zwar, dass mir der Aufwand für das manuelle Anordnen viel zu groß ist.
Ich habe bis jetzt immer mit der automatischen Bereinigungsfunktion gearbeite und fand die bis jetzt super.
Nur sie verschiebt leider meine Kommentare in vollkommen falsche Ecken und das nervt dann, wenn ich dann immer durch das komplette Diagramm durchgehen darf um zu schauen, wo welcher Kommentar hingehört.
Und ja, ich kommentiere mal 'ausnahmsweise' meine Programme

(03.01.2012 21:53 )unicorn schrieb:  Dann braucht es aber auch keine flache Sequenz!

Wieso nicht? Was hat das beides miteinander zu tun?

(03.01.2012 21:53 )unicorn schrieb:  

(03.01.2012 10:24 )Lucki schrieb:  Für Labview-Anfänger, wenn sie hier im Forum ihr VI posten, sind drei Sachen typisch:

1. Exzessive Verwendung von Sequenzstrukturen
2. Riesenhafte BDs in vielfacher Bildschirmgröße, oft mit ganz wenig Code drin, aber den im wüsten Durcheinander.
3. Flächenfressende Strickmuster mit immer dem gleichen Code
   

zu 1.
Man begreift das Datenflußprinzip und die parallele Verarbeitung nicht als Vorteil und Chance, sondern man versucht damit Labview in das Korsett einer normalen, am Programm-Textfluß orientierten Sprache zu zwingen.
..

Oftmals sind die Sequenzen völlig überflüssig, weil die Werte über Drähte ohnehin weitergereicht werden oder werden könnten.

zu 2.
Oder durch das automatische Wachsen der Strukturen riesengroß werden. Das sollten Anfänger besser abschalten und sich lieber über das manuelle Platzmachen ärgern, bis sie merken, das Code nicht kopiert sondern in SubVIs gepackt wiederverwendet werden sollte.

Tut mir Leid, wenn das im vorigen Post untergegangen ist, aber ich habe meinen Code in Sub-VIs gepackt. Es ist nur nicht möglich, noch mehr Code in Sub-VIs auszulagern, da sich immer kleine Dinge ändern.

Achja, mit den manuellen Aufräum-Funktionen komme ich i-wie nicht zurecht. Gibt es da vllt Hilfestellungen?


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.

---

Ich habe jetzt mal das/die VI(s) als *.llb angefügt. Version 9.0.1.
main.vi ist das Hauptprogramm. Die anderen drei sind Sub-VIs. Ausführen kann das hier wohl leider keiner, daran haperts aber auch nicht. Ich hoffe, man kann es trotz nicht vorhandenem NXT Modul öffnen. Wenn nicht, dann kann ich mal dranmachen, das Problem in ein Test-VI zu exzerpieren.
Ein paar Erklärungen:

• Drehen.vi lässt den NXT um eine Gradzahl drehen
• Distanz.vi lässt den NXT um cm vorwärts fahren (evtl mit Lenkung)
• Liniefolgen_Graustufen.vi lässt den NXT einer Linie folgen. Das besondere hierbei ist, dass es mit einem Sensor funktioniert
• Die Knicke in den Leitungen sind noch aus der Zeit, als noch die flache Sequenzstruktur hatte: An jedem Einschnitt begann ein neuer Rahmen. Die meisten Kommentare beziehen sich immer auf einen solchen (unsichtbaren) Rahmen
• Die Anzeigeelemente sind nur zur Orientierung, damit ich weiß, welche Leitung was überträgt. [Offtopic: gibt es eine Möglichkeit, Datenleitungen zu beschriften, dass beim Hover ein Tooltip erscheint?]
• Die am Ende langgezogenen Leitungen sind dort, weil ich da noch weiterprogrammieren will
• 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. Ansonsten müsste ich an jedem VI die Konstanten ändern. Bräuchte außerdem mehr Ressourcen, da noch mehr Konstanten definiert werden müssten und der NXT ist kein Hochleistungsrechner
  Außerdem wird das so schon vom NXT Modul mit den Motor- und Sensorreferenzen gehandhabt (dup-Ausgänge)
• "Stapler" und "Ratte" haben etwas mit dem aktuellen Roboter, sowie dessen Aufgaben zu tun
  

Ich sehe grad, ich habe sehr viel geschrieben. Aber ich dachte mir, besser zu viel und ausführlich, als zu wenig. Wen was nicht interessiert, der kann es ja 'überlesen' ;D
Falls trotzdem noch etwas unklar sein sollte, einfach bitte melden, ich schau, wie ich helfen kann!

Und jetzt einen schönen Abend noch und viel Spaß!


EDIT: Liste von nummeriert in ungeordnet verändert.

Mir tun die Augen weh. Hast Du schon mal an Arrays oder Cluster gedacht?
Außerdem ist Dein Blockdiagramm viel zu breit.
Dass man Blockdiagrammelemente wie Frontpanelelemente ausrichten kann geht, soweit ich weiß, erst seit LabVIEW 2011.
   
Die Drähte aufräumen geht so: Rechtsklick auf den entsprechenden Draht und dann "Clean up wire" auswählen.

Gruß Markus