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!
Hey,
wollt einmal allgemein, ohne dass ich mein "großes" vi hier hochlade ein Sache zum parallelen ablauf von Messung und Ausgabe fragen.
Welche Struktur kann man da am besten verwenden(Melder,Queues, Master/Slave....) ?? Dazu erklär ich einmal worum es geht:
Ziel ist es, alle 45sekunden eine neue Datenausgabe zu starten(ca 10mal). Bei start der Ausgabe, startet gleichzeitig die Messung. Bei dieser Messung ist die Besonderheit, dass sie einmal kontinuirlich am laufen ist UND außerdem alle 50sekunden einen Messwert in ein Array speichert.
Wie ist diese Situation möglich, ohne sich da wild in etwas zu verfangen?
So habe grade mal einen Versuch gestartet mit Queues (Erzeuger/Verbraucher)
Ist dies so möglich oder gibts da noch bessere Möglichkeiten?
Fragen zu dem vi:
Der Stopp button lässt sich nicht betätigen.....wieso?
Bei dem Abschnitt "Messung" wird ja ein Element in der Erzeugerschleife in die Funktion "Elelment einfügen" eingefügt. Leider geht das ja nur mit "einem" Element oder? Wenn man z.B. 10 Analog Eingänge hat muss man ja auch 10 Elemente in diese Funktion einfügen können oder muss man diesen ganzen Abschnitt "Messung" dann 10 mal machen???
' schrieb:Ist dies so möglich oder gibts da noch bessere Möglichkeiten?
Prinzipiell mach ich das auch immer so: Sample-Werte in Queue/Melder schreiben. Wer sie haben will, soll sie aus Queue/Melder auslesen.
Erstens:
Das mit den While-Schleifen im Event-case ist bestimmt nur ein Muster, oder? Event-Case ist für Events da, nicht für dauernd laufende Aufgaben.
Zweitens:
Die "Ausgabe alle 2 Sekunden" ist prinzipiell so machbar. Ob es hier bessere Möglichkeiten gibt, hängt von der Applikation ab.
Drittens:
Bei Messung wird ein Problem auftreten: In Queue können zwar viele reinschreiben, aber immer nur einer auslesen (alles andere ist sinnlos). Wenn also zwei While-Schleifen Daten aus Queue verarbeiten sollen, müssen auch zwei Queues/Melder vorhanden sein. Eine Online-Anzeige (= alle 4 Sekunden messen ...) mach ich immer so: Die sampelnde Schleife (Schleifenraster 50ms) schreibt die gesampelten Daten (Sample-Raster z.B. 1kHz, also 50 Stück Daten) in eine Queue. Der 50te Wert kommt in einem Melder und gilt als Augenblickswert.
Zitat:Der Stopp button lässt sich nicht betätigen.....wieso?
Lässt der doch. Du musst nur 2 Sekunden warten.
Willst du die Sache mit dem Stopp-Button so beibehalten oder ist das jetzt nur wegen dem Versuchs-VI?
Zitat:Bei dem Abschnitt "Messung" wird ja ein Element in der Erzeugerschleife in die Funktion "Elelment einfügen" eingefügt. Leider geht das ja nur mit "einem" Element oder? Wenn man z.B. 10 Analog Eingänge hat muss man ja auch 10 Elemente in diese Funktion einfügen können oder muss man diesen ganzen Abschnitt "Messung" dann 10 mal machen???
Du hast in allen Punkten Recht. Mach halt.
Wenn du 10 analoge Eingänge hast, dann fasst du diese Eingange in eine einzige Analog-Task zusammen. Ein Daq-Read-Element kannst du nun so einstellen, dass es dir ein 2D-Array ausgibt. Dieses Array kannst du dann in eine Queue schreiben. Also: 10 Kanäle - ein Queue-Element.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Ziel ist es, alle 45sekunden eine neue Datenausgabe zu starten(ca 10mal). Bei start der Ausgabe, startet gleichzeitig die Messung. Bei dieser Messung ist die Besonderheit, dass sie einmal kontinuirlich am laufen ist UND außerdem alle 50sekunden einen Messwert in ein Array speichert.
Ich könnte mir auch folgende Lösungsmöglichkeit vorstellen.
Pack beides (Datenausgabe und Samplen) in ein SubVI. Mach in dieses SubVI eine Statemachine rein, die genau den beschriebenen Ablauf hat. Mach die Statemachine mit einer Schrittdauer von 50ms. Alle 50ms liest du per DaqRd alle Kanäle ein. Die kommen in eine Queue (oder werden in einem Array aufaddiert und das kommt in eine Queue). Den ersten Wert aus dem Daqrd schreibst du in einen Melder. Ist das Lesen 20*45 mal gemacht worden, kommt zwischendrinn mal ein anderer Schritt dran: der zum Datenausgeben.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Zitat:Pack beides (Datenausgabe und Samplen) in ein SubVI. Mach in dieses SubVI eine Statemachine rein, die genau den beschriebenen Ablauf hat. Mach die Statemachine mit einer Schrittdauer von 50ms. Alle 50ms liest du per DaqRd alle Kanäle ein. Die kommen in eine Queue (oder werden in einem Array aufaddiert und das kommt in eine Queue). Den ersten Wert aus dem Daqrd schreibst du in einen Melder. Ist das Lesen 20*45 mal gemacht worden, kommt zwischendrinn mal ein anderer Schritt dran: der zum Datenausgeben.
kannst du mir da ein Beispiel zeigen? komme da irgendwie nicht zurecht mit dem zusammenmischen von queues und meldern.
Zitat:Das mit den While-Schleifen im Event-case ist bestimmt nur ein Muster, oder? Event-Case ist für Events da, nicht für dauernd laufende Aufgaben.
Wieso denn nicht? sieht man doch immer wieder, das die verbraucherschleife in eine while schleife eingebettet ist.
Zitat:Bei Messung wird ein Problem auftreten: In Queue können zwar viele reinschreiben, aber immer nur einer auslesen (alles andere ist sinnlos). Wenn also zwei While-Schleifen Daten aus Queue verarbeiten sollen, müssen auch zwei Queues/Melder vorhanden sein. Eine Online-Anzeige (= alle 4 Sekunden messen ...) mach ich immer so: Die sampelnde Schleife (Schleifenraster 50ms) schreibt die gesampelten Daten (Sample-Raster z.B. 1kHz, also 50 Stück Daten) in eine Queue. Der 50te Wert kommt in einem Melder und gilt als Augenblickswert.
Auch hier wärs cool wenn du das mal an einem Beispiel zeigen könntest. Dann kann man sich das immer besser vorstellen wie du das genau meinst.
Zitat:Willst du die Sache mit dem Stopp-Button so beibehalten oder ist das jetzt nur wegen dem Versuchs-VI?
Ne, das muss ich noch überdenken, das stop schneller ausführt.
Hier hab ich mal was gepostet. Das "HauptVI" heißt AIn-Klasse. Da kannst du das mit der Queue und dem Melder sehen.
Zitat:komme da irgendwie nicht zurecht mit dem zusammenmischen von queues und meldern.
Einfach alles parallel machen: Queue und Melder erzeugen, Queue mit Daten beschreiben, Melder mit Daten beschreiben ... Guckst du auch Muster.
Zitat:Wieso denn nicht? sieht man doch immer wieder, das die verbraucherschleife in eine while schleife eingebettet ist.
Es gibt keine Verbraucherschleife (zumindest kenn ich keine).
Es gibt die Einbettung eines Queue-Leseelementes in eine While-Schleife. Das ist auch richtig so und sollte auch so gemacht werden. Dieser Punkt ist aber gar nicht mein Anliegen gewesen. Mir kommt es darauf an, dass in einem Case einer Event-Struktur nichts lange Dauerndes gemacht wird. Außerdem ist eine Event-Struktur nicht als Schleife zu verstehen, sondern als Element innerhalb einer Schleife. Eine Event-Struktur hält die Task, in der sie steht, solange an, bis ein Event eingetreten ist.
Zitat:Auch hier wärs cool wenn du das mal an einem Beispiel zeigen könntest. Dann kann man sich das immer besser vorstellen wie du das genau meinst.
Hmm, da muss ich erst kucken.
Zitat:Ne, das muss ich noch überdenken, das stop schneller ausführt.
1. Möglichkeit: Die 2 Sekunden in 40*50ms quanteln und die Stopp-Taste alle 50ms abfragen.
2. Möglichkeit: Die Stopp-Taste in einen richtigen Event-Case legen und dort dann die Queues löschen ...
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
