LabVIEWForum.de - LV - Tapete verhindern

LabVIEWForum.de

Normale Version: LV - Tapete verhindern
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Guten Morgen liebes LV-Forum,

ich arbeite zur Zeit an einer komplexeren Aufgabenstellung, bei der es ein LV Programm zu realisieren gilt. Ich zweifle im Prinzip auch nicht daran, dass ich dies (früher oder später) hinbekomme, nachdem schön langsam endlich klar ist, was man von mir haben willSmile

Allerdings ist durch die Komplexität des ganzen die Gefahr gegeben, dass ich mir hier eine Tapete bastle, was ich vermeiden will, darum hätte ich gerne ein paar Tips, wie ich ein komplexeres Programm aufbauen soll. Ich bin zwar (so bilde ich mir ein) ein recht begabter Laienprogrammierer, aber mit fehlt eben doch eine professionelle Ausbildung auf diesem Thema.

Meine Hauptsorge ist folgende: Ich muss am Anfang (vor der Hauptschleife) etliche Parameter initialisieren, von denen ich dann an verschiedenen Stellen verschiedene wieder auslesen muss. Je nach Einstellung muss ich auch nicht immer auf die selben Parameter zugreifen. Meine Befürchtung ist, dass das ein undurchsichtiger Kabelsalat wird.

Ein Beispiel wäre z.B.: Ich initialisiere Anfangs eine Filterbank. Hier kann zwischen verschiedenen Filtern gewählt werden und je nachdem können auch Koeffizienten gewählt werden. Wie bringe ich nun diese Einstellung am Besten weiter? Dabei gilt es zu beachten, dass ja je nach Filterbankwahl die Koeffizienten unterschiedlich sind. Nicht nur in ihrem Wert, sondern auch andere Variablen/Anzahl/Typ.

- Soll ich doch Referenzen / lok. Variable verwenden von Zeit zu Zeit um den Drahtsalat zu lockern.
- Alles in einen Cluster packen und nur Teile auslesen (je nach Auswahl dann auch Daten im Cluster, die nie gelesen werden).

Über ein paar Anregungen würde ich mich freuen.
Als kleines Beispiel hänge ich noch einen Screenshot der Arbeit meines Vorgängers an. Wobei ich hoffe auch ohne Tips und Ratschläge hier im Forum derartiges zu verhindern.

Grüße
Ich würde eindeutig einen Cluster mit allen Einstellungen vorschlagen. Am besten noch als Typedef, damit man leicht Änderungen an diesem Cluster vornehmen kann.

Du kannst auch VIs und SubVIs die zu einem Bestimmten Gerät (Objekt) gehören so gestalten, dass diese nur Teile (Cluster im Cluster) des gesammten Einstellungsclusters als Eingang haben. Vergiss diese SubCluster nicht auch als Typedefs zu definieren. Durch dieses Vorgehen, verhinderst du die unnötige Datenschieberei, behälst dabei aber den Überblick.

Hier im Beispiel habe ich den gesammten Einstellungen-Cluster genommen, da ich nicht zu viele Einstellungen habe. Ansonsten würde ich nur einen Teil davon nehmen.

[attachment=12506]

Und das hier wäre das gleich Projekt, aber ein anderes Gerät (also andere Task). Du siehst ich nehme überall den gleichen Einstellungen-Cluster.

[attachment=12507]
Man muss nicht unbedingt ein Wire zum Weiterleiten von Daten verwenden. Es geht auch mit einem sog. funktionalen VI. Ein solches VI speichert die Daten - welches Format auch immer - in einem Schieberegister. Gesteuert wird dieses VI durch einen Enumeratoreingang. Der kann folgende Funktionen (Propertys) haben: SetzeDaten, LeseDaten, SetzeTeilDaten, LeseTeilDaten, AddiereZuArray, ResetteDaten etc. Vorteil: Bei vielen und komplexen Daten kann man sich alle Wire sparen. Außerdem sind die Daten quasi global.
' schrieb:Man muss nicht unbedingt ein Wire zum Weiterleiten von Daten verwenden. Es geht auch mit einem sog. funktionalen VI. Ein solches VI speichert die Daten - welches Format auch immer - in einem Schieberegister. Gesteuert wird dieses VI durch einen Enumeratoreingang. Der kann folgende Funktionen (Propertys) haben: SetzeDaten, LeseDaten, SetzeTeilDaten, LeseTeilDaten, AddiereZuArray, ResetteDaten etc. Vorteil: Bei vielen und komplexen Daten kann man sich alle Wire sparen. Außerdem sind die Daten quasi global.


Das finde ich auch sehr interessant! Top1
Erstmal danke für die Antworten soweit.

Ein einzelnen Cluster wäre auch mein Ansatz soweit gewesen. Die Idee mit den Clustern im Cluster wär mir nicht gekommen. Ist aber klasse.

Das funktionale Vi klingt auch wirklich gut.
' schrieb:Man muss nicht unbedingt ein Wire zum Weiterleiten von Daten verwenden. Es geht auch mit einem sog. funktionalen VI. Ein solches VI speichert die Daten - welches Format auch immer - in einem Schieberegister. Gesteuert wird dieses VI durch einen Enumeratoreingang. Der kann folgende Funktionen (Propertys) haben: SetzeDaten, LeseDaten, SetzeTeilDaten, LeseTeilDaten, AddiereZuArray, ResetteDaten etc. Vorteil: Bei vielen und komplexen Daten kann man sich alle Wire sparen. Außerdem sind die Daten quasi global.
Wie kann ich mir das mit sog. funktionalen VIs vorstellen? Kannst da mal bitte ein Beispiel machen.
Ein Muster ohne Wert - sprich also ohne alle Unterprogramme, nur zum kucken.

Lv85_img
Hallo,

inzwischen stecke ich mitten drinnen im Erstellen des Programmes und komme (nicht zuletzt) dank der 2 Tips hier auch gut voran. Für die Allgemeinheit, die vielleicht mal über die Suchfunktion hierauf stößt:

Hauptsächlich verwende ich Cluster in Clustern um meine Einstellungen kompakt zusammenzufassen. Dies hat vorallem auch den großen Vorteil, dass das Programm sehr einfach erweiterbar ist.
Gibt es z.B. eine Einstellmöglichkeit, bei der jede Option eigene Parameter braucht, so erstelle ich einen Cluster, der die gewählte Einstellung enthält, sowie für jede davon einen Cluster mit den Parametern.
Erweitere ich nun die möglichen Einstellungen (TypDefinition), so brauche ich nur einen weiteren Cluster hinzufügen und die CaseStruktur erweitern. Dabei ändert sich gar nichts für die bereits bestehenden Optionen.

Das funktionale Vi verwende ich gelegentlich um "Counter" umzusetzen. Ich habe diverse Arrays mit Parametern, die ich auslesen muss. Bei jedem Auslesen muss dabei der nächsthöhere Index ausgelesen werden. Mit einem funktionalen Vi läßt sich dies hervorragend lösen, ohne dass ich quer durch mein HauptVi einen Zähler mitschleppen muss.

Grüße und schönen Feierabend (den ich jetzt mache)
Referenz-URLs