Hallo zusammen,
ich benötige mal wieder eure Hilfe.
Ich arbeite mit einer NI USB-6211 und LabView 8.5.
Ich möchte gleichzeitig die Frequenz eines TTL-Signals und zwei Spannungen messen und die Messwerte in eine Datei schreiben. Dazu benutze ich das angehängte VI. Da ich das nicht komplett selbst programmiert habe, verstehe ich es auch (noch) nicht 100%ig.
Das TTL-Signal stammt von einem Encoder, der an einen Gleichstrommotor angeschlossen ist.
Das größete Problem ist momentan, dass die gemessene Frequenz des TTL-Signals sehr ungenau ist. Wenn ich mir die Messwerte anschaue oder anzeigen lasse, haben diese eine Genauigkeit von 10^3. Sie sehen also beispielsweise so "3000 4000 2000 3000 ..." und nicht so "3245 4035 1999 3245 ..." aus.
Ich dachte erst, dass das vielleicht ein Problem der Sampling-Rate ist. Aber eine Änderung bringt keine Verbesserung.
Außerdem verstehe ich nicht, wieso ich am "DAQmx Create Channel" und dann nochmal an der "Property Node" den Counter einstellen muss. Wieso zweimal? Und muss das der selbe Counter sein? Wenn ich an der "Property Node" einen anderen eingestellt habe, konnte ich keine Veränderung feststellen.
Danke im Voraus,
Grüße
Hast Du die "falschen" Frequenzen schon in Deinem Waveform-Chart oder erst nach dem Umwandeln in einen String?
Gruß Markus
Hallo Markus,
die falschen Frequenzen sind bereits im Waveform-Chart. Siehe Anhang.
Sonst noch eine Idee?
Danke, Gruß
ingo
Hallo,
ich habe gerade festgestellt, dass die Messwerte realistischer aussehen, wenn ich anstatt der Methode "High Frequency with two Counters" die Methode "Large Range with two Counters" verwende. Siehe Anhang.
Kann ich nun also davon ausgehen, dass ich mit dieser Methode alles richtig mache und die Frequenzen stimmen (ungeachtet der üblichen Messfehler natürlich)? Kennt sich da jemand aus?
Und kann mir noch jemand die Frage mit der "Property Node" beantworten? Programm ist wie beschrieben nicht komplett von mir und deswegen verstehe ich diese Stelle nicht.
Grüße
ingo
Hi,
mal zur Info:
http://www.labviewforum.de/Thread-analog...#pid122505
Dein Beispiel kapier ich auch nicht so ganz...aber am PropertyNode wird ja nur angegeben, wo dein zu messendes Signal angeschlossen ist. Entspricht der PFI0 dem "Standardeingang" deines Counters ("Source")?
A.
Also die Frequenzmessung sieht nicht gut aus. Wie soll denn der Gleichstrommotor zwischen zwei Samples die Frequenz derart sprunghaft ändern?
Das sieht mir aus wie eine Schwebung, die wahrscheinlich nur durch das Samplen auftritt.
Eine Frequenz von 3000 Hz mit 800 Samples pro s abzutasten ist nicht gerade praktisch. Da ich jedoch die Funktionsweise der Frequenzmessung des NI USB-6211 nicht im Kopf habe, empfehle ich
Hallo zusammen!
Nach Rücksprache mit dem NI-Service sind einige Fragen geklärt:
(1) Die "Property Node" kann man auch weglassen, wenn man das Signal an dem Default-Anschluss anlegt. Man benötigt sie nur, wenn das Signal an einen anderen Anschluss angelegt wird.
(2) Nun zu der Samplingfrequenz. Sich bei dieser Art der Frequenzmessung auf das Nyquisttheorem zu beziehen ist nicht richtig! Dass es also eine schlechte Idee ist mit f_sampling<f_Signal "abzutasten" ist Quatsch. Hier die Erklärung dazu von NI aus den USA:
"On every rising edge of the sample clock the counter task will latch an encoder reading. We use the same sample clock as the DAQ AI task in order to ensure that there is exactly one sample of AI data and one encoder measurement taken at the same time. (...) If another sample clock pulse comes before the signal of interest has completed then next full period, the Frequency task does not have a value to give. Thefore if the AI task is set to acquire 10 samples, it will have send 10 sample clock pulses and read 10 samples. However the Frequency task may only have been able to acquire 8 samples in that time because the signal of interest is slow. In this case the DAQmx read for the Frequency task is waiting for 2 additonal samples (since it is configured to read 10 samples as well), but those 2 additional samples will never come. Therefore the task times out."
In diesem Fall muss die Samplingfrequenz also unter der Signalfrequenz liegen. Ansonsten gibt es einen Timeout-Fehler.
Ich habe das Beispiel nochmal etwas geändert (s. Freq+Spannung.vi). Die Ergebnisse sehen aber immer noch sehr seltsam aus (Plot_TTL-Frequenz.png).
Was habe ich hier gemacht: Ich habe den Motor mit zwei verschiedenen Spannungen vermessen. Einmal 3V und einmal 6V. Die Frequenzwerte habe ich mir in Blöcken von 5000 in eine Textdatei gespeichert. Für beide Spannungen habe ich die Messung jeweils zehn Mal wiederholt. Nun habe ich also 50000 Samples (Frequenzwerte) für die Messung mit 3V und die selbe Anzahl für die Messung mit 6V. Die beiden Spannungen haben mich hier nicht interessiert. Wenn ich die 50000 Werte dann plotte, erhalte ich die angefügte Grafik.
Nun meine Frage: Wieso verändert sich die Genauigkeit der Messungen so sprunghaft?
Da diese Genauigkeitssprünge fast immer beim Beginn einer neuen Messung auftreten, gehe ich davon aus, dass der Fehler in der Programmierung liegt. Was ebenfalls für ein Softwareproblem spricht, ist die Tatsache, dass sich diese Messergebnisse mit einem anderen Motor in ähnlicher Weise reproduzieren lassen.
Das war jetzt ziemlich viel Text. Ich hoffe es ist verständlich und jemand hat die Muße sich das alles durchzulesen und es zu verstehen. An dieser Stelle möchte ich auch nochmal allen danken, die sich bis jetzt ernsthafte Gedanken gemacht haben!
Grüße
ingo
Bei Erstellung eines PNG-Bildes solltest du beim Speichern eine Kompressionsrate > 0 einstellen. Ansonsten belegt ein PNG genausoviel Platz wie ein BMP. Ich konnte deinen 4,5 MB Upload auf 380 kB verkleinern!
Gruß, Jens
Hi,
sorry wegen des großen Bildes.
Wieso Off Topic? Es geht doch nach wie vor um die Genauigkeit der Frequenzmessung. Das ist meine Frage. Der Rest drumrum ist halt zur Erklärung bzw. um aufgekommene Fragen/Bemerkungen zu beantworten/kommentieren.
Gruß,
ingo
(13.12.2011 15:07 )ingeule schrieb: [ -> ]Wieso Off Topic? Es geht doch nach wie vor um die Genauigkeit der Frequenzmessung.
Mein freundlich gemeinter Hinweis mit dem Riesenbild ist "offtopic", nicht dein Beitrag.
Gruß, Jens