Logarithmische Signaldarstellung

Hallo Adaephon,

Zitat:Du meinst so etwas?

Ja.

Zitat:Das meinte ich auch, nur bin ich mir unschlüssig wie ich eine Taktung bekomme, dass nach jeweils 1s Daten aus dem Producer-Schema ausgegeben werden.

Messdaten für genau eine Sekunde abfragen und in die Queue schreiben…

Zitat:Zumal ich stets wieder zwei Ausgaben brauche, die der letzten Sekunde und die die Daten aller Sekunden.

Falsch. Dein Producer erzeugt immer einen Datenblock von 1s. Der Consumer sammelt die Messdaten "aller Sekunden"…

Anzeige

(02.04.2014 13:52 )jg schrieb:  Lösung: Feedbacknode/Shift-Register initialisieren!
Gruß, Jens

Danke Jens für den Hinweis.

Ich denke das ich es hinbekommen habe. Durch die Initialisierung ist am Rand der äußersten Schleife noch eine Konstante erstellt worden. Dadurch scheint es zu funktionieren.

(02.04.2014 14:46 )GerdW schrieb:  Messdaten für genau eine Sekunde abfragen und in die Queue schreiben…
Dein Producer erzeugt immer einen Datenblock von 1s. Der Consumer sammelt die Messdaten "aller Sekunden"…

Ich habe im Internet von NI eine Beispiel-VI zur Erzeugung einer Warteschlange gefunden und versucht mich daran entlang zu arbeiten.

Dies war die Beispiel-VI:
  daqmxbase_cont_ai_prodcons.vi (Größe: 198,32 KB / Downloads: 161)


Hier mein Versuch mit dem Schema:
  FCS_Producer-Consumer.vi (Größe: 69,08 KB / Downloads: 148)


Ich hoffe das das so klappt. Auf der Arbeit habe ich die LabVIEW 2011 Version von Windows zum arbeiten, aber da ich zuhause auch noch weiter machen möchte habe ich mir nun die Trial-Version von 2013 für OS X heruntergeladen. Jetzt weiß ich auch was ihr mit dem DAQmx-Assistenten habt. Das werde ich morgen direkt als erstes Versuchen den Assistenten in eine Task-Code-Block umzuwandeln, wobei der Assistent bei einer Umwandlung im continuious-Mode erneut eine Schleife um den "Code-Block" erzeugt. Hoffentlich macht das keine Probleme mit dem Producer-Block.

Bei der Einarbeitung der Producer-Consumer-Struktur musste ich einige Datenlinien neu anpassen, hoffentlich hat das einigermaßen geklappt. Testen kann ich das aber erst morgen, wenn ich auf dem Computer der Arbeit bin wo das DAQ installiert ist. Wird es Probleme geben wenn ich hier in der 2013er Version ohne DAQ die VI editiere und speichere? Muss man irgendwo eine Abwärtskompatibilität einstellen?


Aber überzeugt hast du mich mit dem Schema Gerd
Wohin im Bus ist mir eingefallen warum das Schema noch von Vorteil ist. Ich würde nämlich auch noch gern ein fortlaufendes Histogramm erstellen. Das mit immer Datenstücke aus der Queue nimmt welche eine definierte Zeitbreite, z.B. 100 ns, haben und diese wie in einer Zeitspur histogrammiert.

Aber Schritt für Schritt. Bisher bin ich durch eure Hilfe schon weiter gekommen als ich dachte. Vielen Dank!

Hallo Adaephon,

Zitat:Wird es Probleme geben wenn ich hier in der 2013er Version ohne DAQ die VI editiere und speichere?

Solange du nichts am DAQ-Assi rummachst (was du ja eh nicht kannst): Nein!

Zitat:Muss man irgendwo eine Abwärtskompatibilität einstellen?

Du musst "Save for previous version..." machen!

Zitat:Das mit immer Datenstücke aus der Queue nimmt welche eine definierte Zeitbreite, z.B. 100 ns, haben

Du kannst nur solche "Stücke" aus einer Queue nehmen, die du da auch hineingeschrieben hast. Wenn du ganze Sekundenpakete hineinschiebst, fallen am anderen Ende der Queue auch wieder Sekundenpakete vom Band: eine Queue ist eine Warteschlange…
Wie du die Sekundenpakete später verarbeitest, ob am kompletten Stück oder doch fein gehäckselt, bleibt aber immer noch dir und deiner Programmierung überlassen!

Bisher habe ich (hoffentlich funktioniert sie) eine kontinuierliche "Einspeisung" der Daten in die Warteschleife. Wie kann ich die Sekundeneinspeisung in die Queue machen, ohne das ich über die 1 Hz Abtastrate gehe? Geht das mit einer Uhr in der Schleife oder ähnlichem?

Guten Morgen,
nachdem ich ernüchternd heute morgen festgestellt habe, dass meine Idee von gestern Abend nicht funktioniert habe ich einen neuen Versuch gestartet.

Zumindest kommen Daten aus dem Producer-Abschnitt nun in die Queue und im Consumer-Abschnitt werden Daten entgegengenommen.

Mein Problem ist die Einstellung am DAQ-Assistenten. Ich wollte ihn eigentlich in einen Prozess umwandeln lassen, aber dann erzeugt er mir gar keine Daten mehr. Wie GerdW es empfohlen habe, habe ich die Abtastrate auf 1 Hz gesetzt, damit mir 1 Hz Stück / Pulse in die Queue geschoben werden. Dabei habe ich die Sample to Read auf 100k gesetzt, damit der Buffer groß genug ist alle Daten zwischenspeichern zu können die innerhalb dieser 1s gemessen werden.

Nur leider werden keine solche Stücke anscheinend in die Queue geschrieben, da bei der "Messzeit" Ermittlung krumme Werte herauskommen.

Könnte jemand erneut einen Blick auf die Struktur werfen?

  FCS-ProCon.vi (Größe: 81,73 KB / Downloads: 160)

Hallo Adaephon,

also eine Producer-Consumer-Struktur, bei der P und C durch Datenabhängigkeiten/DATAFLOW innerhalb einer großen While-Loop verbunden sind, entspricht nicht unbedingt der "Lehrmeinung"…

Hast du mal das Beispiel einer Producer-Consumer-Struktur angeschaut, indem du ein neues Projekt mittels "Neu…" erstellst?

Schau dir mal das Attachment an!

Hallo GerdW,
danke für den Anhang. Ich hatte das in der Example-VI zum Schema schon gesehen, war mir aber nicht sicher, wie man die äußere Loop entfernen sollte, ohne das Problem das fortlaufenden Arrays zu terminieren.
Aber in deinem Beispiel hast du das Problem gelöst.

Ich habe gerade auch noch einmal ein komplett neues VI erstellt, um zu testen, wie ich den DAQ Assistent dazu bekomme die Daten kontinuierlich auszuwerfen.

Der Versuch ist dieser hier:
  Neuer_Versuch.vi (Größe: 151,12 KB / Downloads: 159)


Hier erzeugt er zwar einen kontinuierlichen Datenfluss aber entsprechende Einstellungen im FCS.vi liefern keine Ergebnisse.

Eventuell hängt das an der Art und Weise wie die "Stop" und "Stopped" Eingänge belegt sind. Derzeit wirft er mir wenn ich "Samples to Read" einstelle die Messzeit heraus, wie lang es gedauert hat 200 Photonen zu detektieren. Unabhängig von der Abtastrate. Sehr komisch. Dabei sollte "Samples to Read" im kontinuierlichen Modus doch nur der Buffer sein.

Ich glaube ich habe das Problem etwas umgangen und so klappt es nun. Es lag wohl wirklich an der Belegung des stopp und stopped Eingang des DAQmx-Assistent.

Ich habe nun einen kontinuierlichen Fluss der Daten in die Queue.
Nun war meine Idee, dass ich die Auswertung in eine Case Struktur packe die nur ausgeführt wird, wenn die Messzeit das erste Mal ganzzahlig eine Sekunde überschritten hat.

Dazu habe ich die Casestruktur angelegt, eine min or euqal-Funktion angelegt und das als Wahr gesetzt.

Nun ist das Problem, dass nur beim ersten Eintrag des Datenstroms getestet wird, ob der Wert kleiner 1 ist, ab dann ist die Anweisung True in die Auswertung läuft. Ich möchte aber eine selektive Auswertung, dass jede Eintrag der Queue überprüft wird.

Hier noch mein Ansatz in der vi:
  FCS-ProCon.vi (Größe: 81,35 KB / Downloads: 161)



Derzeit habe ich den Vergleichswert auf 1 gesetzt um zu sehen, dass wirklich das erste Mal ausgewertet wird nach einer vollen Sekunde.

Edit:

Wobei mir gerade auffällt, dass so meine eigentliche Intention glaube ich nicht gelöst ist.
Über die Case-Anweisung würde ich eine sekündliche Aktualisierung der Messdaten haben, aber eben aller Messdaten und nicht nur der Messdaten der letzten Sekunde.

Hallo Adaephon,

Zitat:Ich möchte aber eine selektive Auswertung, dass jede Eintrag der Queue überprüft wird.

THINK DATAFLOW!

Wenn du jeden Datenblock überprüfen willst, dann solltest du das auch programmieren!
Bisher testest du den ersten Datenblock - und wunderst dich, warum nicht auch die weiteren getestet werden…

(03.04.2014 11:47 )GerdW schrieb:  Hallo Adaephon,

Wenn du jeden Datenblock überprüfen willst, dann solltest du das auch programmieren!
Bisher testest du den ersten Datenblock - und wunderst dich, warum nicht auch die weiteren getestet werden…

Hallo GerdW,
das ist mir gerade auch aufgefallen. Danke für den Hinweis *G*

Als ich mir gerade die Queue-Funktionenn angeschaut habe gibt es auch die nette Funktion Queue leeren und den Inhalt als Array speichern. Damit müsste es sich ja realisieren lassen sekündlich den Queue zu leeren und weiterzuverarbeiten.

Und den Vergleichswert muss ich wohl aus der Producer-Abteilung abgreifen.