LabVIEWForum.de

Hallo
Mein Wunsch:
so soll es im FP ungefaehr ausschauen:
[attachment=24831]

Problem 1: Ich moechte nicht, dass Cluster 1, Cluster 2, Cluster 3 angezeigt wird. Klar, Haekchen bei Visibility weg, und schon passts. Aber wenn ich so ein Element dann kopiere, hat es auch im Blockdiagramm keinen Namen mehr. Das ist natuerlich untragbar. Ich gehe davon aus, dass das es ein LabVIEW 7.1 Bug ist. Muss ich hier jetzt also wirklich bei jedem Ding einzeln den Haken wegmachen?

Problem 2: Die ganzen Cluster schauen fuerchterlich im Blockdiagramm aus. Wenn ich alle in ein Arraystecke habe ich aber keine Spalten mehr. Also mache ich fuer jede Spalte im FP ein Array und fuege dann alle zusammen?

Frage 1: Bleiben die individuellen Cluster-Inhalt-Bezeichnungen (Write AI1, Write AI2,...) wirklich immer erhalten, wenn ich die Cluster in ein Array packe?

Frage 2: Control und Indicator in einem Cluster kann nicht gehen - is das richtig?


..hm...passt evtl. hierzu:
Mein Wunsch: Nochmal 10 von den Teilen nur kleiner:
[attachment=24832]
Der Menu ring zur Auswahl hat immer denselben Inhalt - abhaengig von der Auswahl soll ein anderes Element eines Arrays im Chart erscheinen. Schoen und gut. Auch das gibt eine riesige Anzahl von Terminals im Blockdiagramm.

Laesst sich das irgendwie vermeiden. Ich meine ring in ein Array, Charts in ein Array wuerde das Blockdiagramm leeren, aber dafuer hat man dann im FP keine schone und zusammen gehoerige Platzierungsmoeglichkeit.

Frage 3: Kann man Arrays erstellen, deren Inhalte im FP nicht nebeneinander liegen (muessen)?

Sonstige Hinweise und Tipps hoere ich mir natuerlich auch gerne an
Danke!!

' schrieb:Muss ich hier jetzt also wirklich bei jedem Ding einzeln den Haken wegmachen?

Bug hin oder her.
Das ist kein algorithmisches Problem und keines, das der Anwender sieht - also irrelevant.

Zitat:Also mache ich fuer jede Spalte im FP ein Array und fuege dann alle zusammen?

Nein, das gibt glaub ich Probleme.
Arbeite programmintern mit einen 1D-Array und wandel das nur für die Anzeige in ein 2D-Array um - siehe Palette Array "Array umformen".

Zitat:Frage 1: Bleiben die individuellen Cluster-Inhalt-Bezeichnungen (Write AI1, Write AI2,...) wirklich immer erhalten, wenn ich die Cluster in ein Array packe?

Nein.
Arrays kennen nur identische Elemente. In jedem Array-Index heißen entsprechende Element immer gleich.

Zitat:Frage 2: Control und Indicator in einem Cluster kann nicht gehen - is das richtig?

Jein.
Ob ein Clusterelement vom Typ Control oder Indicator ist, hängt alleine vom Typ des Clusters ab: Control oder Indicator. In einem Indicator-Cluster kann man keine Eingabeelemente haben. In einem Eingabe-Cluster kann man aber durch Deaktivierung eines Control-Elementes ein Indikator-Element simulieren.

Zitat:Ich meine ring in ein Array, Charts in ein Array wuerde das Blockdiagramm leeren

Array of Clustor of (Ring, Chart);

Zitat:Frage 3: Kann man Arrays erstellen, deren Inhalte im FP nicht nebeneinander liegen (muessen)?

Ich lass mich mal zu einem Ja hinreisen.
Man kann auch in LV einen Datensatz von FP trennen. Demzufolge kann ein Datensatz als (1D-)Array aufgebaut sein (das ist besser für einen Algorithmus), aber als verteilter Cluster of Cluster am FP erscheinen (das sieht schöner aus).
Mach eine FGV. Die hat ein Schieberegister, in der sich die Daten befinden, mit denen überall in der Applikation gearbeitet wird. Außerdem hat die FGV eine Funktionalität "Anzeige" (Funktionalitäten werden per Enumerator aufgerufen). Nach jeder Datenmanipulation innerhalb der FGV werden die Daten per Referenz auf ein FP geschrieben. Wie komplex man die Anzeige gestaltet, ist völlig unerheblich: Die Referenz auf das Anzeigeelement (Haupt-Cluster) wird einmalig an die FGV übergeben. Mittels einer FOR-Schleife und diversen Dereferenzierungen kann man nun die Index-Inhalte des Arrays auf die einzelnen Unter-Cluster verteilen.

Zitat:Das ist kein algorithmisches Problem und keines, das der Anwender sieht - also irrelevant.

Jaja, immer schoen LabVIEW verteidigen. Ist das bei hoeheren Versionen immer noch so?

Zitat:Nein. Arrays kennen nur identische Elemente. In jedem Array-Index heißen entsprechende Element immer gleich.

Jo eigentlich klar. Das war ja das was ein Array ausmacht...

Zitat:Jein.
Ob ein Clusterelement vom Typ Control oder Indicator ist, hängt alleine vom Typ des Clusters ab: Control oder Indicator. In einem Indicator-Cluster kann man keine Eingabeelemente haben. In einem Eingabe-Cluster kann man aber durch Deaktivierung eines Control-Elementes ein Indikator-Element simulieren.

Ah, welch mieser Trick

Zitat:Arbeite programmintern mit einen 1D-Array und wandel das nur für die Anzeige in ein 2D-Array um - siehe Palette Array "Array umformen".

Das 2D Array dient hier dann lediglich der Anzeige als Spalte (und nicht als Zeile) im FP?

Zitat:Ich lass mich mal zu einem Ja hinreisen.

Ohje, das geht ja gut los

Hab FGVs noch nie gehoert- hab mir das hier mal durchgelesen:
http://decibel.ni.com/content/docs/DOC-2143
Ist interessant, aber ich verstehe wenn ich ehrlich bin trotz deinen Erlaeuterungen nicht so ganz - bzw. ich wollte ja ehrlich sein- gar nicht wie mir das helfen koennte.

' schrieb:Ah, welch mieser Trick

Das ist kein mieser Trick, das ist offizielle Vorgehensweise.

Zitat:Das 2D Array dient hier dann lediglich der Anzeige als Spalte (und nicht als Zeile) im FP?

Ein 2D-Array erscheint ja als Zeilen und Spalten am FP.
Ich gehe davon aus, dass du eine bestimmte Anzahl Cluster anzeigen willst. Eine optimale Anzeigeform ist dann also ein Matrix aus X-mal-Y Elementen. Diese Matrix wird mit einem 2D-Array realisiert.

Zitat:Hab FGVs noch nie gehoert- hab mir das hier mal durchgelesen:

Naja, jetzt kennst du sie ja. Und weißt, was man mit ihnen machen kann.

Zitat:Ist interessant, aber ich verstehe wenn ich ehrlich bin trotz deinen Erlaeuterungen nicht so ganz - bzw. ich wollte ja ehrlich sein- gar nicht wie mir das helfen koennte.

Was ich geschrieben habe, waren wiedermal nur prinzipielle Sachen.

Du willst ja zwei Sachen haben. Auf der einen Seite möchtest du ein einfaches Datenhandling haben, um einen möglichst einfaches Sourcecode schreiben zu können. Der ist dann nämlich übersichtlich, einfach zu debuggen, leicht erweiterbar usw. Die Datenhandling ist das, was du im BD siehst, nämlich ein Wire. Auf der anderen Seite möchtest du aber auch ein ansprechendes Erscheinungsbild für das FP haben. Nun hat aber LV den dummen Nachteil, dass das FP und das BD immer gekoppelt sind: Zu jedem BD-Datum gehört ein FP-Element (und umgekehrt). Hier verträgt sich gerade bei komplexen Datenstrukturen (1) eben das einfache Datenhandling (2) mit dem ansprechenden FP oft nicht. Man muss oft einen Kompromis finden, der beide Seiten etwas einschränkt, aber beiden Seiten noch genügt. Stimmst du mir bisher zu? Hat einer Einwände?

Findet man den Kompromis nicht, kann man ein "Wrapper-VI" schreiben, das eine Anpassung zwischen einfachem Handling und schöner Anzeige macht. Du willst als Management ja ein 1D-Array of Cluster, als Anzeige aber verteilte Cluster haben. Verteilte Cluster können aber nicht als Array dargestellt werden. Die Lösung könnte also ein "Wrapper-VI" sein. Könnt ihr mir hier folgen?



(1): Hier ist der Aufbau eines Datensatz bemeint. Der kann ja z.B. 1DArr of Cluster(1DArr, Cluster(Value)) sein. Dieser Aufbau soll am FP sichtbar sein.
(2): Hier ist gemeint, wie der Datensatz im BD erscheint: nämlich als 1 Wire, also lediglich das äußere Array.

Zitat:Stimmst du mir bisher zu?

Denke, dass es noch sehr, sehr lange nicht in meinem Aufgabenbereich liegen wird, dir nicht zuzustimmen-. natuerlich stimm ich dir zu !

Zitat:Die Lösung könnte also ein "Wrapper-VI" sein.

Cool!

Zitat:Könnt ihr mir hier folgen?

Nein

Aber ist auch nicht so wichtig, ich werds halt in dem Fall mit Wire-Chaos loesen.

...hm...kannst du ein Wrapper VI bauen aus dem ersichtlich wird, wie es geht? - Das ist ja evtl. fuer die Allgemeinheit interessant-
Wenns viel Aufwand ist oder du keine Zeit fuer sowas hast, dann natuerlich nicht. Is nur ne Frage aus Interesse fuer das naechste LabVIEWprogramm.
Ich hab daheim jetzt die EDU-Version von LabVIEW, kann also mir auch Sachen mit hoeheren LabVIEW-Versionen anschauen

' schrieb:Jaja, immer schoen LabVIEW verteidigen. Ist das bei hoeheren Versionen immer noch so?

Nein! Wieder ein Grund für ein Upgrade

' schrieb:...hm...kannst du ein Wrapper VI bauen aus dem ersichtlich wird, wie es geht?

Meine bestehenden FGVs sind hier als Muster ungeeignet. Schau mer mal, ob ich nächste Woche Zeit für ein Muster finde.

' schrieb:Schau mer mal, ob ich nächste Woche Zeit für ein Muster finde.

Muster in.

Bringt ihm wohl leider nur nichts, da er noch 7.1 hat.

Gruß Markus

' schrieb:Muster in.

aufmerksamer Y-P
allerdings:

Zitat:Ich hab daheim jetzt die EDU-Version von LabVIEW, kann also mir auch Sachen mit hoeheren LabVIEW-Versionen anschauen

Zitat:Muster in 8.2

Danke IchSelbst - so schaut es also aus, wenn ein Profi was programmiert. Der Laie wie ich versteht nichts mehr- viele schoene neue VIs.... ich werde mich damit nacher mal vertieft ausseinander setzen - momentan versteh ich nur Bahnhof