LabVIEWForum.de - Durchflusssensor - Pulse zählen/Frequenz messen

LabVIEWForum.de

Normale Version: Durchflusssensor - Pulse zählen/Frequenz messen
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2 3 4 5
Ich habe doch noch eine Frage bezüglich der Durchflussmessung.

In meinem MWE-Programm werden die "normalen" Sensoren mit 2000 Samples/s abgetastet. Gelesen und weiterverarbeitet werden die Daten in Blöcken zu je 2000 Sample, also jede Sekunde ein Datenblock. Wenn ich die Daten vom Durchflusssensor, wie von GerdW vorgeschlagen, mittels eines Melders weitergebe und die Daten in der gleichen Schleife weiterverarbeite wie die restlichen Sensoren, bekomme ich nur 1 Wert/s, was etwas wenig ist. Ich sollte vllt. noch erwähnen, dass ich hauptsächlich mit Signalverläufen arbeite, so kann ich am Ende in der TDMS-Datei noch eine Zeit-Spalte erzeugen.

Darum habe ich mir folgendes Überlegt:

Ich entkoppele die Durchflussdaten von den restlichen Messwerten, indem ich eine separate Schleife verwende. Die Daten werden aus der DAQ-Schleife per Melder in eine weitere Schleife überführt. Diese zweite Schleife arbeitet mit einem festen Timing von 100 ms - somit bekomme ich alle 0,1 s einen Wert für den Durchfluss, das sollte reichen. Mit dieser Timing-Information kann ich mir einen Signalverlauf basteln, der dann über eine Queue in die Logging-Schleife transportiert wird. Den Fall des Null-Durchfluss fange ich über den Melder-Timeout ab. Evtl. ist die Queue bei dem langsamen Timing von 100 ms überflüssig?

Das VI befindet sich im Anhang.


Mein Frage dazu: Gibt es generelle Verbesserungsvorschläge bzw. kann/sollte man das grundsätzlich anders aufbauen?

Danke!


PS: Stört euch bitte nicht an der nicht vorhandenen Fehlerbehandlung... ist nur ein Test-VI^^
keiner eine Idee? Ihr seid doch sonst so schnell mit Vorschlägen? Smile (oder liegts am WE?)
Hallo zig,

so, das WE ist vorbei…

Dein VI sieht so schon ganz gut aus. Was man noch ändern könnte:
- Statt des Melders und Abfrage des TimeOut des Melders kannst du auch direkt am DAQmxRead einen TimeOut von 100ms vorgeben. Dann den TimeOut-Fehler direkt abfangen/auswerten und die Daten per Queue weiterschicken. Das führt zum gleichen Ergebnis und spart eine Schleife ein…
- In der (dann nicht mehr nötigen) Schleife zur Auswertung des Melders hast du einmal ein TimeOut von 100ms am AufMelderWarten und einmal einen 100ms-Takt vorgegeben. Ich hätte da leichte Bauchschmerzen, dass beide Wartezeiten sich ungünstig auswirken: ich würde das Timeout auf ~95ms begrenzen, wenn ich ganz sicher einen 100ms-Takt einhalten will…
Vielen Dank für deine Hinweise. Wenn ich allerdings den Melder entferne, den Timeout an das DAQmx-Read hänge und dadurch die mittlere Schleife weg fällt, habe ich doch aber das Problem, dass ich die unterschiedlichen Sampleraten des Durchflusszählers nicht mehr in einen geordneten Signalverlauf mit gleichem delta_t bekomme?! Oder wie hast du das gemeint?

Du hattest mir in diesem Thread den Hinweis gegeben, die, mit dem Durchfluss veränderliche, Anzahl an Samples pro Sekunde mit einem Melder und einer getakteten Schleife abzufangen!?
Hallo zig,

Zitat:habe ich doch aber das Problem, dass ich die unterschiedlichen Sampleraten des Durchflusszählers nicht mehr in einen geordneten Signalverlauf mit gleichem delta_t bekomme?
Sorry, das hatte ich nicht mehr auf dem Schirm. Also doch weiterhin mit der Zwischenstufe Melder…
Vielen Dank, dann werde ich das so ins Programm übernehmen (mit angepasstem Timeout)
Hm... mir ist noch ein Problem begegnet, bei dem ich nur eine Lösung durch "starkes Pfuschen" gefunden habe. Betrachtet man das letzte VI von mir, fällt in der mittleren Schleife auf, dass der Signalverlauf immer nur aus einem Wert besteht und dann geschrieben wird. Das dt kommt nur durch das Schleifentiming zustande (Liest man das dt wieder aus, dann ist der Wert immer 1, da nur ein Wert enthalten ist). Wenn man die Werte nur direkt schreibt ist das egal (seltsamer weise steht in der TDMS-datei dann wf-increment 0,1). Jetzt wollte ich aber noch ein Signalverlaufsdiagramm einfügen. Dieses zeigt mir, logischerweise, nur einen hüpfenden Punkt.

Wenn ich nun versuche das mit Hilfe von Arrays zu einem Verlauf zu strecken, dann wird immer der gesamte Verlauf neu angehängt und nicht nur die aktuellsten Werte. Dadurch kommt es im Graphen zu ständigen Wiederholungen.

Die zweite Alternative war das "Anhängen-VI" aus der analogen Signalverlaufs-Palette mit einem Rückkopplungsknoten... das scheint zwar zu funktionieren aber irgendwie ist mir das unsympathisch.

Gibt's da noch eine elegantere Möglichkeit?

Die zweite Variante habe ich mal angehängt.
Hallo zig,

dann baue doch die Waveform erst später zusammen - siehe Anhang!
Und achte darauf, das Schieberegister mit einer korrekten Waveform zu initialisieren (bzgl. t0 und dt)!
Erneut vielen Dank, damit werde ich nun hoffentlich zurecht kommen Smile
Also ehrlich, diese beknackte Ermittlung des Durchflusses mittels Frequenzmessung treibt mich noch in den Wahnsinn xD


Nachdem ich nun dachte, dass alles paletti ist, musste ich feststellen, dass die Messwerte der "normalen" Sensoren und die des Druchflusszählers asynchron sind.


Nun habe ich mich schon durch den ein oder anderen Artikel und Thread bezüglich Synchronisation gewühlt aber ich glaube, dass mein Problem hier wo anders begraben liegt.

Angehängt ein Beispiel VI, welches das Probelm verdeutllicht:

Startet man das Vi, lässt es kurz laufen und beendet es, entsteht eine TDMS-Datei mit den Messwerten. Dabei fällt auf, dass die Werte der "normalen" Sensoren z.B. über 5 sec. 5000 Werte (dt = 0,001) geliefert haben. Entsprechend erwarte ich, dass der Durchflusssensor 50 Werte (dt = 0,1) liefert. Leider sind es bei Letzterem immer etwas weniger.

Nun die erste Frage: Wo liegt der Fehler?


Die zweite Frage: Um im realen Programm alle Tasks gleichzeitig (annäherend) zu starten, reicht es, wenn ich alle DAQmx-Start-Blöcke in eine flache Sequenz packe?

Danke!
Seiten: 1 2 3 4 5
Referenz-URLs