(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:
- Exzessive Verwendung von Sequenzstrukturen
- Riesenhafte BDs in vielfacher Bildschirmgröße, oft mit ganz wenig Code drin, aber den im wüsten Durcheinander.
- 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.
