Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
13.10.2010, 09:07 (Dieser Beitrag wurde zuletzt bearbeitet: 13.10.2010 09:43 von jg.)
ich bin jetzt gerade neu angemeldet, habe aber in letzter zeit schon viel Hilfe durch das Anschauen anderer Threads bekommen. Bei meinem aktuellen Problem habe ich bisher aber noch keine Lösung gefunden.
Ich habe angefangen VIs mit Ereignisstrukturen zu bauen. Momentan habe ich ein Listenfeld, in welchem ich Einträge markiere und diese dann an die Ereignisstruktur übergebe, welche diese wiederum in eine Tabelle überträgt. Leider funktioniert das immer erst korrekt, wenn ich das entsprechende Ereignis zweimal auslöse. Vorher übergibt er nur die zuletzt, aber nicht aktuell markierten Einträge. Weiß jemand woran das liegt? Das entsprechende VI hängt an.
In dem VI sieht man übrigens noch ein anderes Problem: ich wollte die Einträge in die markierte Zelle schreiben lassen. Ich dachte ursprünglich, dass ich an die Koordinaten der markierten Zelle über den Eigenschaftsknoten "Aktive Zelle" gelange. Dies ist aber nicht der Fall. Ich habe jetzt eine extra Ereignis eingebaut, welches die Koordinaten bei einem Mausklick in ein Tabellenelement speichert. Das funktioniert zwar, aber ich vermute es geht auch eleganter. Wäre super, wenn da auch jemand Rat weiß.
Viele Grüße und schon mal vielen dank,
devilsdoormat
Die Umwandlung in eine Matrix ist nicht ganz überflüßig. MatrixSize funktioniert zwar mit 2D-Arrays, aber da ich hier nur ein 1D-Array habe, müsste ich das auch erst in ein 2D-Array umwandeln. Ob so oder so, ich brauche einen Zwischenschritt. Es wäre höchstens für die Perfomance interessant zu wissen, was schneller geht, wobei das in dem Fall wahrscheinlich total egal ist
die Ereignisstrukturen ärgern mich immer noch und haben mich in den letzten Tagen enorm viel Zeit gekostet.
Ich habe 3 Listen. Eine dient als Datenquelle mit der ich per drag&drop die beiden anderen füllen möchte. Diese Daten schreibe ich dann fortlaufend in 2 2D Arrays. So ist zumindest der Plan. Ich habe aber das Problem, dass nicht immer (und ich kann dabei derzeit keine Regel feststellen) das entsprechende Ereignis ausgelöst wird, wenn ich Daten verschiebe . Ich vermute, dass es daran liegt, dass ich über eine Wertänderung der beiden Listen gehe, dies aber gar nicht (direkt) damit zusammenhängt, dass neue Elemente hinzukommen oder entfernt werden. Im Anhang ist der entsprechenden Bildausschnitt des VIs. Mit dieser Meldung habe ich herausbekommen, dass es daran liegt, dass das Ereignis nicht immer ausgelöst wird, wenn ich Elemente in die Listen ziehe.
Eine alternative, die zunächst einmal besser klingt wäre ja "Ziehen=>Ablegen". Das Problem ist, dass LabView dann weder die Daten aus der alten Liste entfernt noch in die neue Liste schreibt. Mit "Verschobene Daten ermitteln" hatte ich auch schon mal ein VI gebastelt, welches die Daten dann in die Liste schreibt. Aber die markierten Daten aus der ursprünglichen Liste wurden dabei nicht entfernt.
... wie ihr seht Probleme über Probleme. Ich frage mich langsam, ob ich mit LabView überhaupt zurecht komme
Kannst du mal ein Muster-VI posten, in dem der unerwünschte Effekt auftritt und aus dem hervorgeht, wie du s haben willst.
Zitat:Ich frage mich langsam, ob ich mit LabView überhaupt zurecht komme
Hier wie bei jeder anderen Programmiersprache gilt: Erst Eigenheiten lernen (hier also der explizite Datenfluss, etc.) und verinnerlichen und dann die erforderlichen Elemente finden - oder programmieren.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
17.10.2010, 09:39 (Dieser Beitrag wurde zuletzt bearbeitet: 17.10.2010 11:03 von jg.)
ich habe schon befürchtet, dass ich etwas wirr daher geschrieben habe. Ein Minimalbeispiel hängt an.
Was ich erreichen will: sobald ein neues Element in die Listen "Ziel 1" oder "Ziel 2" verschoben werden, soll ein Ereignis ausgelöst werden, welches die dann aktuell in der Liste vorhandenen Objekte in ein Array schreibt.
Was dabei nicht funktioniert: Ich versuche dies über eine Wertänderung des Listenfeldes zu erreichen. Ich bin insofern inzwischen schlauer als dass ich mir bewusst gemacht habe, dass der Wert des Listenfeldes ein Array mit den Indizes der markierten Elemente ist. Wenn sich diese beim Verschieben der Daten nicht ändern, wird mein Ereignis nicht ausgelöst. Ich bräuchte also ein Ereignis, welches direkt registiert, wenn sich das "Objektnamen"-Array der Ziel-Liste ändert. So etwas finde ich in dem Ereignisdialog allerdings nicht.
die 3 subvis, die ich geschrieben habe, erfüllen den Zweck, dass die "Objektnamen"-Daten vernünftig in das Ziel-Array geschrieben werden. Vielleicht gibt es da auch elegantere Varianten, aber das soll hier auch nicht der Gegenstgand sein.
Zitat:Hier wie bei jeder anderen Programmiersprache gilt: Erst Eigenheiten lernen (hier also der explizite Datenfluss, etc.) und verinnerlichen und dann die erforderlichen Elemente finden - oder programmieren.
Das ist sicherlich der sauberste Weg. Nur habe ich derzeit ein konkrete, recht umfangreiche Aufgabenstellung und muss es irgendwie bewerkstelligen die nötigen Funktionen von LabView im Kontext zu erlernen.
' schrieb:Was ich erreichen will: sobald ein neues Element in die Listen "Ziel 1" oder "Ziel 2" verschoben werden, soll ein Ereignis ausgelöst werden, welches die dann aktuell in der Liste vorhandenen Objekte in ein Array schreibt.
Ja, das hab ich verstanden. Außerdem soll ein Ereignis ausgelöst werden, wenn ein Element herausgeschoben wurde.
Zitat:Was dabei nicht funktioniert: Ich versuche dies über eine Wertänderung des Listenfeldes zu erreichen. Ich bin insofern inzwischen schlauer als dass ich mir bewusst gemacht habe, dass der Wert des Listenfeldes ein Array mit den Indizes der markierten Elemente ist. Wenn sich diese beim Verschieben der Daten nicht ändern, wird mein Ereignis nicht ausgelöst.
Das ist richtig. Und halt, ich sag mal so, ein spezielles Feature von LabVIEW.
Zitat:Ich bräuchte also ein Ereignis, welches direkt registiert, wenn sich das "Objektnamen"-Array der Ziel-Liste ändert.
Das sehe ich auch so.
Zitat:So etwas finde ich in dem Ereignisdialog allerdings nicht.
Stimmt.
Und jetzt ein allgemeiner Kommentar:
LabVIEW ist in erster Linie hervorragend geeignet, Messwerte zu sampeln (mittels Messwertkarten von NI), weiterzuleiten, zu verarbeiten, anzuzeigen, zu speichern. Da musst du andere Systeme schon wie die Nadel im Heuhaufen suchen, die hier NI das Wasser reichen können. Nur ein Stichwort: integrierter DAQmx.
Dafür ist LabVIEW - eigentlich - völlig ungeeignet, was die reine Manipulation von Datenstrukturen angeht wie eben jetzt deine Listen. Hier sind reine OOP-Sprachen, C# sei nur als Beispiel genannt, im Vorteil. Das liegt einfach daran, dass es eben so schöne Events wie OnObjChange etc. etc. etc. in LabVIEW (noch) nicht gibt. Meistens gibt es eben nur den Event "Value changed" (hier muss man natürlich genau wissen, was bei welchem Element (Zahlen, Strings, TabSheets, Listen, Graphen, etc.) jeweils der "Value" ist).
Will man ein Event auf irgendeiner anderen Methode/Eigenschaft liegen haben, muss man entweder suchen, ob denn schon mal jemand was programmiert hat - oder eben selber programmieren. Sprich: auch dein spezieller Fall ist in LabVIEW nur eine Aufgabe, kein Problem.
Lösung:
Deine Aufgabe heißt "in einer Liste steht was, das in ein Array soll". Dieses wolltest du bisher dynamisch lösen: Änderung der Liste => Event => Übernahme nach Array. Eine dynamische Lösung hat den Vorteil, dass sie extrem ressourcenschonend ist (eben wegen des "dynamischen" Events). Es geht aber prinzipiell auch statisch: "Was in der Liste steht wird in ein Array übernommen". Lege ganz einfach das, was jetzt im ValueChgd-Event liegt, in den Timeout-Case, der z.B. alle 250 ms aufgerufen wird - und schon sind alle deine Probleme mit den fehlenden Events gelöst. Diese statische Methode hat zwar den Nachteil, dass sie nicht gerade ressourcenschonend ist. Dafür ist aber das algorithmische Ziel erreicht. Und so kritisch sehe ich das mit den zusätzlichen (Zeit-)Ressourcen in deinem Falle nicht.
Noch ein Hinweise:
Bei der statischen Methode ist natürlich zu verifizieren, dass der verwendete Algorithmus (innerhalb des Timeoutcases) auch tatsächlich "statisch-sicher" ist (ein reines Inkrementieren "Anzahl der Wertänderungen" wäre z.B. nicht "statisch-sicher", weil dann die Anzahl der Timeoutcase-Aufrufe gezählt werden nicht nicht die "Aufrufe ObjChgd-Events").
"Statische Abläufe" unterstützen das Verständnis für "Datenfluss-Steuerung" (in einem Fluss gibt es keine Events).
Ob deine Aufgabe mit LVOOP einfacher zu lösen geht als statisch, weis ich nicht. Ich mach kein LVOOP.
Zitat:Das ist sicherlich der sauberste Weg. Nur habe ich derzeit ein konkrete, recht umfangreiche Aufgabenstellung und muss es irgendwie bewerkstelligen die nötigen Funktionen von LabView im Kontext zu erlernen.
Da sind wir natürlich beim Hauptproblem aller arbeitenden Programmierer. Der Chef verlangt "mach das, aber ohne Kosten zu verursachen". Viel Spaß mit LabVIEW.
Und: Die SubVis kuck ich mir auch noch an. - Später.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Bisher wurde es genauso gehandhabt. Messdatenerfassung mit LabView und Weiterverarbeitung mit MatLab + Origin. Mein Ziel ist nun im wesentlichen die existierenden Routinen zur Auswertung der Daten in LabView einzuarbeiten, damit am Ende ein Programm steht, was im Prinzip Mädchen für (fast) alles ist.
' schrieb:Lösung:
Deine Aufgabe heißt "in einer Liste steht was, das in ein Array soll". Dieses wolltest du bisher dynamisch lösen: Änderung der Liste => Event => Übernahme nach Array. Eine dynamische Lösung hat den Vorteil, dass sie extrem ressourcenschonend ist (eben wegen des "dynamischen" Events). Es geht aber prinzipiell auch statisch: "Was in der Liste steht wird in ein Array übernommen". Lege ganz einfach das, was jetzt im ValueChgd-Event liegt, in den Timeout-Case, der z.B. alle 250 ms aufgerufen wird - und schon sind alle deine Probleme mit den fehlenden Events gelöst. Diese statische Methode hat zwar den Nachteil, dass sie nicht gerade ressourcenschonend ist. Dafür ist aber das algorithmische Ziel erreicht. Und so kritisch sehe ich das mit den zusätzlichen (Zeit-)Ressourcen in deinem Falle nicht.
Das wars. So geht es wirklich einwandfrei. Und da in diesem Fall die Datenmengen wirklich überschaubar bleiben, denke ich auch, dass das nicht zu sehr ressourcenbelastend ist. Zumal bei dieser "Dateneinordnung" nichts anderes parallel läuft.
