LabVIEWForum.de

Hallo,

ich bin denke ich nun bei der alles entscheidenden Frage angekommen, wie bringe ich alles übersichtlich unter ein Dach! (Ja ich weiss man soll sowas vorher überlegen!) Mir wachsen nämlich schön langsam die Programme über den Kopf, und ich möchte es bevor ich aufgrund der Größe nichts mehr ändern kann in ein handliches Format bringen. Ich wollte eigentlich schon zu Beginn an "richtig" bauen, aber irgendwie ist es als Anfänger recht schwer.

Ich fasse kurz zusammen was ich genau machen möchte:

1) Vorhandenes TXT-File einlesen
2) Optionen aus der 2. Spalte filtern und dementsprechend verarbeiten
3) Nach Optionen die Hexwerte auf die DIOs meiner Schnittstellenkarte schreiben (also mit Chipselect usw.)
4) Gelesene Werte in neues TXT-File abspeichern

All diese Dinge funktionieren bereits, aber halt im Einzelgebrauch, jetzt geht es ums "Zusammenführen". Funktionen von fertigen (Sub)-VIs, welche bereits funktionieren bzw. wo mir auch dankenswerter Weise im Forum geholfen wurde:

- Lesen/Schreiben der Hexwerte auf DIO der I/O Karte mittels DAQmx
- Aufsplitten des Hexwertes in seine Bestandteile
- Codierung/Modulation des codierten Streams (für nachfolgendes) Schreiben
- Decodierung/Demodulation des gelesenen codierten Streams (für nachfolgendes) Schreiben und Lesen

Sprich ich habe alles was ich brauche, nur weiss ich noch nicht wirklich welche Struktur ich als Grundstein nehmen soll. Userinteraktionen gibt es so gut wie keine, man liest das File ein, das Programm soll die SPIs beschicken und am Ende bekomme ich ein TXT mit den gelesenen Werten. Ich denke dabei daran eine State Machine zu nehmen, und eben all diese Funktionen irgendwie "hineinzuverwursten", die folgende States beinhalten soll:

- Initialisierung
- File I/O (TXT-File)
- Überprüfung der Optionen (ob SPI1, 2, 3 oder auf alle geschrieben wird)
- Codierung des Signals (ich muss ja das Signal zusammensetzen)
- Lesen & Schreiben

Es geht mir hier um den grundlegenden Aufbau, die Einzelteile funktionieren alle bzw. habe ich sie teilweise schon zu größeren Programmen zusammengebaut. Aber da ich Übersichtlichkeit doch schätze, denke ich daran es in eine große Struktur umzubauen. Und es soll ja auch erweiterbar sein, das jetztige Programm wird immer unübersichtlicher.

Danke für jede Meinung
Chris

Am besten fände ich natürlich eine State Machine. Ich würde hier wahrscheinlich einfach auf die Pattern von JKI zurückgreifen. Der einfachste Weg dahin fängt damit an, dass du den VIPM herunterlädst, die benötigten Pakete zu Labview hinzufügst und nach Neustart von LAbview verwendest. VIPM ist ein Paketmanager, der dir eine einfache Möglichkeit in die Hand gibt, zusätzliche VIs aus verschiedenen Quellen nachzuladen. Die meisten sind kostenlos oder sogar Open Source, manche hingegen kostenbehaftet.Die JKI- ustandsmaschine umfasst bereits ein große Funktionalität, die du beliebig erweitern kannst. Auch eine Zustandsqueue ist realisiert, in welche du sowohl vorne als auch hinten Aktionen einfügen kannst. Weiterhin kann die Queue für jede Zustand auch Argumente übergeben. Probiers aus, es wird dir gefallen

[url=http://www.google.de/search?q=jki+state+machine&ie=utf-8&oe=utf-8&aq=t&rls=org.mozillae:official&client=firefox-a]JKI State Machine[/url]

State machine ist eine gute Idee. JKI State Machine ist super. Kann Schrotti nur zustimmen.

Wenn Du Deine 4 oder 5 Schritte jeweils in einem SubVI hättest und sich der Ablauf immer so seine soll, könntest Du die 4 oder 5 SubVIs auch in einem Haupt-VI einfach hintereinander setzen. Die Reihenfolge wird über die weitergereichten Daten oder einen Errorcluster gewährleistet.

Moin,

das JKI Teil ist ganz nett, ist meiner Meinung nach aber nur für sehr kleine Anwendungen brauchbar. Für den Usecase den du beschrieben hast, könnte es passen.
Wenn du es einsetzt, tue dir den gefallen und mach einen Typedef für den Cluster. Ich vermute JKI hat diesen Mist nur drinnen, damit das Ganze so hübsch als MergeVI/SnippetVI (oder wie die gerade heissen) funktioniert.

In der NI Nomenklatur ist das JKI Teil auch keine state machine sondern eine queued message handler, nur falls jemand so 'ne Frage in 'ner Zertifizierungsprüfung gestellt bekommen sollte.

Das Cluster ist typdefiniert. In ein Snippet gehts nicht rein, da SubVI dabei sind.

' schrieb:Das Cluster ist typdefiniert. ...

Nein.

[attachment=31950]

Cluster ohne Typedef inkl. Bundle ohne Namen... naja...