LabVIEWForum.de

möglich... ich finde es nur etwas seltsam, dass es für so gängige Signalformen nicht eine Musterlösung gibt.

Hallo zig,

Zitat:für so gängige Signalformen nicht eine Musterlösung gibt

Für "gängige" Signalformen gibt es doch Musterlösungen - wie das von mir angeratene Synch-Beispiel.
Dummerweise ist dein Sensor eben kein "gängiges" Signal…

Du willst hier einen AI mit fester Samplerate mit einem CTR mit sehr unregelmäßiger Sampleabfrage verknüpfen - und wunderst dich über Probleme…
Was hier vielleicht funktionieren könnte, wäre einen "echten" CTR zu verwenden, d.h. nur die Pulse zählen zu lassen und die Frequenz selbst zu berechnen. Sowas kann man nämlich dann auch mit fester Samplerate abfragen!

Zitat:Für "gängige" Signalformen gibt es doch Musterlösungen - wie das von mir angeratene Synch-Beispiel.
Dummerweise ist dein Sensor eben kein "gängiges" Signal…

Naja also ein digitales Signal für den Durchfluss finde ich schon "gängig".

Zitat:Du willst hier einen AI mit fester Samplerate mit einem CTR mit sehr unregelmäßiger Sampleabfrage verknüpfen - und wunderst dich über Probleme…
Was hier vielleicht funktionieren könnte, wäre einen "echten" CTR zu verwenden, d.h. nur die Pulse zählen zu lassen und die Frequenz selbst zu berechnen. Sowas kann man nämlich dann auch mit fester Samplerate abfragen!

Ich wundere mich nur deshalb über Probleme, weil ich erwartet hatte, dass so etwas zum Standard gehört. Da habe ich mich wohl getäuscht

An einen "echten" Counter habe ich auch schon gedacht, aber ich habe oft über Probleme mit der Genauigkeit gelesen, wie groß sind denn schätzungsweise die Probleme die ich dort zu sehen bekomme? Wenn ich das Prinzip richtig verstehe, dann Zähle ich mit dem Counter einfach Pulse und stoppe über ein Timer-VI die Zeit, die er für x Pulse braucht, daraus resultiert die Frequenz. Schaffe ich mit so einem Ansatz 350 Hz fehlerfrei?

Hallo zig,

Zitat:An einen "echten" Counter habe ich auch schon gedacht, aber ich habe oft über Probleme mit der Genauigkeit gelesen, wie groß sind denn schätzungsweise die Probleme die ich dort zu sehen bekomme?

Wieso sollte der CTR ungenauer sein als deine bisherige Frequenzmessung? Sie beruhen beide auf demselben Signal - die Frequenzmessung übernimmt nur die Umrechnung von Pulsdauer/-abstand in Frequenz für dich…

Zitat:Wenn ich das Prinzip richtig verstehe, dann Zähle ich mit dem Counter einfach Pulse und stoppe über ein Timer-VI die Zeit, die er für x Pulse braucht, daraus resultiert die Frequenz.

Wenn du den CTR mit fester Samplerate abfragst, brauchst du die Zeit nicht messen. Die Hardware erledigt das für dich viel genauer…

Zitat:Schaffe ich mit so einem Ansatz 350 Hz fehlerfrei?

Die Frage ist dann nicht, ob du Pulse mit 350Hz einzeln erfassen kannst (die CTR-Hardware selbst auf der einfachsten USB6008 kann 10MHz), sondern, ob du die Pulse wirklich einzeln auswerten willst. Für eine Frequenzberechnung mittels dPulse/dt ist das jedenfalls egal…

Zitat:Wieso sollte der CTR ungenauer sein als deine bisherige Frequenzmessung? Sie beruhen beide auf demselben Signal - die Frequenzmessung übernimmt nur die Umrechnung von Pulsdauer/-abstand in Frequenz für dich…

Nicht der Counter, sondern die nachgelagerte Berechnung der Frequenz. Da diese zeit braucht, kommt die ab einer bestimmten Frequenz nicht mehr hinterher.

Zitat:Wenn du den CTR mit fester Samplerate abfragst, brauchst du die Zeit nicht messen. Die Hardware erledigt das für dich viel genauer…

Dann brauche ich doch aber wieder eine externe Taktquelle oder? Im Beispielfinder ist entweder kein Timing-Vi im Einsatz oder es wird eine externe Taktquelle benötigt. Hast du dazu ein Minimalbeispiel wie das aussehen sollte`?


Was genau verstehst du hier unter "mit fester Samplerate abfragen"? Die tatsächliche Samplerate, die ich am Timing-VI einstellen kann, dann bräuchte ich wieder eine externe Taktquelle oder die Anzahl der zu lesenden Samples in Verbindung mit dem Schleifentiming?

Hallo zig,

erstelle doch mal ein kleines VI, in dem du einen CTR-DAQmx-Task erstellst, diesen mit einer Samplerate von 100Hz und "kontinuierlich" konfigurierst und dann in einer Schleife schön mit DAQmxRead jeweils 10 Samples ausliest!

Ich habe deine Hardware hier nicht und kann/will deshalb nicht prüfen, ob deine Hardware CTR-Tasks mit fester Samplerate erlaubt…

So, im Anhang das VI. Es funktioniert nur leider nicht (zeigt mir gar nix an und bringt den Fehler, dass noch nicht alle Samples gelesen wurden).

Implizites Timing ist hier gar nicht möglich, also muss ich beim Sample-Takt-Timing eine externe Taktquelle vorgeben.

Frage #1: Woher weiß ich was man da am sinnvollsten nimmt? Aus Synchronisationsgründen evtl. ai/SampleClock ?

Frage #2: Mal angenommen das VI würde die Flanken zählen, wie komme ich denn von da zur Frequenz? Wenn der Counter "langsam" hochzählt und ich nur einen Bruchteil der Daten zur Frequenzermittlung lese, dann steht doch im ungünstigsten Fall 10 mal der gleiche Wert im gelesenen Datenpaket oder wo liegt mein Gedankenfehler?

Frage #3: Durch welche Zeit dividieren ich die Anzahl der Flanken dann? Die Schleife, die 10 Werte lesen soll, läuft dann nur ungefähr mit 0,01 ms. Das schwankt leicht.


Ich bin verwirrt