LabVIEWForum.de

Hallo Bernd1,

ich hab mir Dein abgespecktes Beispiel mal näher angeschaut.

Damit wirst Du noch mehr Probleme kriegen:
- die Logik Deiner STOP buttons ist ziemlich kompliziert. Es ist nicht leicht, das Programm anzuhalten
- die 'elapsed time' Express-VI verhält sich nicht so, wie man naiverweise denken würde. Probiers aus. (Jetzt spiel ich mal Betreuer: lass die Finger generell von Express-VIs. Sie gaukeln Dir Einfachheit vor, wo keine ist.)
- schwerwiegendstes Problem: Synchronisation! Deine obere loop (die Daten'senke' kriegt nur einen kleinen Bruchteil der Messdaten mit, da in dem Beispiel die Messloop irrsinnig schnell läuft, die Auswerteloop aber nur einmal pro msec.

Das Synchronisationsproblem wirst Du immer haben, wenn Du locals ohne weitere Vorkehrungen benutzt, selbst wenn Deine Prüfloop in Wirklichkeit viel langsamer läuft. Queues vermeiden genau das: alles was man vorne in die Q reinschiebt, holt sich die Datensenke hinten wieder raus.

Kann natürlich sein, dass es bei Deinem Messproblem egal ist, wenn einige Messwerte verloren gehen. Kann auch sein, dass Dein Betreuer das so will. Dann brauchst Du natürlich keine Synchronisation.

Ich habe jedenfalls mal eine primitive Q-lösung (nach dem Q Multiplexer.VI aus dem examples Verzeichnis) in Dein Beispiel hineingebastelt. Ist ohne jegliche Fehlerprüfung, zeigt aber hoffentlich das Prinzip (und kommt natürlich ohne locals für die Messwerte aus):

[attachment=2786]

' schrieb:Finde ich auch komisch, dass sich dein Betreuer gegen Cluster und Event Strukturen ausspricht.

<div align="left">
Cést la vie!

Gruß
Bernd
</div>

' schrieb:Hallo Bernd1,

ich hab mir Dein abgespecktes Beispiel mal näher angeschaut.

Damit wirst Du noch mehr Probleme kriegen:
- die Logik Deiner STOP buttons ist ziemlich kompliziert. Es ist nicht leicht, das Programm anzuhalten
- die 'elapsed time' Express-VI verhält sich nicht so, wie man naiverweise denken würde. Probiers aus. (Jetzt spiel ich mal Betreuer: lass die Finger generell von Express-VIs. Sie gaukeln Dir Einfachheit vor, wo keine ist.)
- schwerwiegendstes Problem: Synchronisation! Deine obere loop (die Daten'senke' kriegt nur einen kleinen
Bruchteil der Messdaten mit, da in dem Beispiel die Messloop irrsinnig schnell läuft, die Auswerteloop aber nur einmal pro msec.

Das Synchronisationsproblem wirst Du immer haben, wenn Du locals ohne weitere Vorkehrungen benutzt, selbst wenn Deine Prüfloop in Wirklichkeit viel langsamer läuft. Queues vermeiden genau das: alles was man vorne in die Q reinschiebt, holt sich die Datensenke hinten wieder raus.

Kann natürlich sein, dass es bei Deinem Messproblem egal ist, wenn einige Messwerte verloren gehen. Kann auch sein, dass Dein Betreuer das so will. Dann brauchst Du natürlich keine Synchronisation.

Ich habe jedenfalls mal eine primitive Q-lösung (nach dem Q Multiplexer.VI aus dem examples Verzeichnis) in Dein Beispiel hineingebastelt. Ist ohne jegliche Fehlerprüfung, zeigt aber hoffentlich das Prinzip (und kommt natürlich ohne locals für die Messwerte aus):

[attachment=28739:attachment]

<div align="left">
Hallo Franz,

nochmals vielen Dank für die vielen Hilfen.

Ich sehe da kommt wohl noch einiges auf mich zu.
Express-Vis benutze ich zum Glück nicht (mein Fehler-hätte ich von Anfang an sagen sollen) -finde die Dinger überflüssig- .

Mit der Syncronisation muß ich nochmal schauen. Scheint etwas größeres zu sein.

Ich weiß, daß es mit den Stop-Button ein Problem gibt.
Aber ich weiß leider keine Möglichkeit, wie ich den Status eines Buttons an eine andere Schleife übergeben kann, wenn der Knopf im "Latch-Modus" ist.

Schaue mir mal alles in Ruhe an, und frage meinen Betreuer.
Melde mcih gebenfalls nochmal hier oder unter einem neuen Thema ( falls es noch keine Lösungen dazu gibt).

Ich wünsche bis dahin erstmal eine schöne Woche.

Gruß
Bernd
</div>

Hab das Beispiel nochmal nachgefeilt, läuft jetzt ganz gut.

Liefert eine Lösung (fast) ohne lokale Vars.
Durch Q Verwendung gibt es keine Datenverluste. Queues haben noch einen anderen schönen Nebeneffekt: Eine Q wird ja immer in mehreren Schleifen genutzt (das ist sozusagen ihr Daseinszweck), und dass kann man ausnutzen um von einer (Master)Schleife die anderen (Slave)Schleifen anzuhalten: Wenn der Master fertig ist, 'tötet' er die Q, und die Slaves (die natürlich Q Fehler abfragen müssen) wissen dann, dass auch für sie Feierabend ist. Ist 'ne ganz normale Technik, um abhängige Schleifen zu beenden, und im mitgelieferten Beispiel demonstriert.

Viel Spass noch bei der Diplomarbeit!

[attachment=2791]

So, hab Dir mal eine eingermaßen professionelle Version geschrieben (Cluster-Tabu hin oder her):


[attachment=2800]


unterschied zu vorher:
- nur noch eine Q ('One Q to rule them all'
- klarere Struktur der Eingabe/Mess-Schleife
- nur noch eine (pro Schleife) unvermeidliche local
- einigermaßen konsequente Modularisierung mit subVIs
- Diagramm passt auf eine Seite (zumindest bei nur zwei loops)

Schau mal, ob man durchsteigt!