Frequenz "Null" messen

Hallo Zusammen,

ich versuche gerade einen Geschwindigkeitssensor von Corrsys Datron (S350) auszulesen. Er gibt mir 1000 Pulse/Meter aus. Habe jetzt versucht das Ganze über eine Frequenzmessung zu gestalten... Funktioniert auch soweit ganz gut, solange der Sensor in Bewegung ist. Bei Geschwindigkeit 0 gibt dieses Ding aber leider eine Frequenz 0 aus, was zur Folge hat, dass die Messung sofort stehenbleibt. Fehlermeldung nach 10sec, abgelaufenes Timeout... Ich habe schon nachgefragt ob es möglich ist eine Basisfrequenz auf den Sensor zu legen. -Leider nicht! Wie schaffe ich es, dass 1. meine Messung weiter läuft und 2. ich in diesem Zustand eine 0 ausgegeben bekomme? Bitte helft mir.... flippe bald aus! Leider habe ich auch auf der Karte keinen Counter mehr frei um mir sozusagen eine Basisfrequenz auszugeben, die ich dann auf das andere Signal legen könnte. Zudem wäre das keine allzu professionelle Lösung... Eine Flankenzählung wäre wohl auch möglich, allerdings kenne ich mich damit nicht sonderlich gut aus. Da würde ich gerne alle 10msec die Anzahl der gezählten Flanken erfahren, weiss aber nicht wie dass aussehen könnte...

Vielen Dank schonmal für hoffentlich schnelle und gute Hilfe!

Anzeige

Frequenzmessung ist nichts anderes als Flankenzählung, also hilft das hier nicht. Der einzige Weg ist, den Timeout über eine Auswertung des Error-Clusters abzufragen (Code im Timeout ist -200474) und für diesen Case die Frequenz 0 weiterzuleiten. Der Error kann dann zurückgesetzt werden.
Wenn das VI nicht ewig warten soll, musst du eben als Timeout 10ms festlegen. Das könnte aber Probleme beim Messen kleiner Frequenzen geben. Beispielsweise erfordern 10Hz schon 100ms (eben eine Periode). Ich würde also nicht unbedingt die Messung in feste Zeiten takten, sondern messen, wenn es Daten gibt. Wenn du 10s Timeout hast, passiert auch nichts. Entweder, die Frequenz wird wieder anders, dann fängt er wieder an zu messen, oder sie bleibt Null, dann bekommst du diesen Wert auch nach 10s, ohne, dass du zwischendurch was falsches gemessen hättest.

' schrieb:Frequenzmessung ist nichts anderes als Flankenzählung, also hilft das hier nicht. Der einzige Weg ist, den Timeout über eine Auswertung des Error-Clusters abzufragen (Code im Timeout ist -200474) und für diesen Case die Frequenz 0 weiterzuleiten. Der Error kann dann zurückgesetzt werden.
Wenn das VI nicht ewig warten soll, musst du eben als Timeout 10ms festlegen. Das könnte aber Probleme beim Messen kleiner Frequenzen geben. Beispielsweise erfordern 10Hz schon 100ms (eben eine Periode). Ich würde also nicht unbedingt die Messung in feste Zeiten takten, sondern messen, wenn es Daten gibt. Wenn du 10s Timeout hast, passiert auch nichts. Entweder, die Frequenz wird wieder anders, dann fängt er wieder an zu messen, oder sie bleibt Null, dann bekommst du diesen Wert auch nach 10s, ohne, dass du zwischendurch was falsches gemessen hättest.

Gar keine schlechte Idee... Danke für die schnelle Antwort.
Ich spezifiere das Ganze mal noch etwas. Ich brauche diesen Geschwindigkeitssensor um Fahrzyklen nachzufahren, d.h. es kann durchaus sein, dass ich 30sec lang stehe. Während dessen möchte ich aber z.B. den Spritverbrauch und Temperaturen weiter messen. Momentan ist alles in der selben while schleife, was bedeutet, wenn die Frequenz des Geschwindigkeitsensors null ist, steht meine ganze Messung solange, bis er sich wieder bewegt. Leider habe ich bis Montag mein VI nicht zur Verfügung, zwecks Schaltbild... Ich lese die Frequenzen über einen DAQ-Reader aus. Ständig diesen Task zu starten und wieder zu beenden könnte sich doch negativ auf die Geschwindigkeit meiner Messung auswirken?

' schrieb:Ich brauche diesen Geschwindigkeitssensor um Fahrzyklen nachzufahren, d.h. es kann durchaus sein, dass ich 30sec lang stehe. Während dessen möchte ich aber z.B. den Spritverbrauch und Temperaturen weiter messen. Momentan ist alles in der selben while schleife, was bedeutet, wenn die Frequenz des Geschwindigkeitsensors null ist, steht meine ganze Messung solange, bis er sich wieder bewegt.

Hi,

nein das dürfte keine Problem sein! Der Timeout wird ja nicht in deiner Schleife erzeugt, sondern auf deiner Messkarte! D.h. die Schleife läuft ganz normal weiter, es kommen halt keine neuen Werte in der Schleife an. Nach der Timeoutzeit wird von der HW ein Fehler in die Schleife geschickt, und den fängst du dann ab! Die anderen Mess-Aufgaben haben keinen Timeout, d.h. hier kommen kontinuierlich Werte an.

Gruß
Achim

' schrieb:Hi,

nein das dürfte keine Problem sein! Der Timeout wird ja nicht in deiner Schleife erzeugt, sondern auf deiner Messkarte! D.h. die Schleife läuft ganz normal weiter, es kommen halt keine neuen Werte in der Schleife an. Nach der Timeoutzeit wird von der HW ein Fehler in die Schleife geschickt, und den fängst du dann ab! Die anderen Mess-Aufgaben haben keinen Timeout, d.h. hier kommen kontinuierlich Werte an.

Gruß
Achim

Hallo nochmal,

hab gerade bei LabVIEW angerufen. Deren Lösung wäre über den Event Count. Hat das schonmal jemand gemacht? Wo finde ich den diesen sogenannten Event-Count?

Hi,

du hast maximal bei National Instruments angerufen!

Was die genau meinen, kann ich mir nicht vorstellen. Gibts keine Beispiel? Evtl. meinen sie zu schauen, wenn Anzahl Impulse < 1...aber machs einfach so, wie schon vorgeschlagen!

A.

Event Count ist nichts anderes als ein normaler flanken-zählender Counter. Schließ mich Achim an - no idea, was die meinen. Maximal, dass man vor der Frequnzmessung eine Flankenzählung startet und sieht, ob man innerhalb einer gewissen Zeit einen Impuls bekommt. Wenn nicht, wird die Frequenzmessung gar nicht erst ausgeführt, man geht von f=0 aus. Damit lässt sich der Timeout reduzieren, wenn man mehrere Perioden für eine Frequenzmessung verwendet - siehe Methoden 'High frequency' oder 'Large frequency range'. Bei 'Low frequency' bringt das jedoch wenig...

Zu Achims Beitrag: Meiner Meinung nach wartet das DAQmx Read.vi an der Stelle, bis entweder ein Messwert, oder ein Timeout auftaucht. Dein Programm wird also nicht wie gewünscht bei f=0 ohne weiteres funktionieren. Eine Alternative wäre, die Frequenzmessung in eine parallele Schleife auszulagern, die aktuellen Messwerte immer in einen Notifier speichern und in der Hauptschleife nur den letzten Notifier-Status abzufragen...

' schrieb:Zu Achims Beitrag: Meiner Meinung nach wartet das DAQmx Read.vi an der Stelle, bis entweder ein Messwert, oder ein Timeout auftaucht. Dein Programm wird also nicht wie gewünscht bei f=0 ohne weiteres funktionieren. Eine Alternative wäre, die Frequenzmessung in eine parallele Schleife auszulagern, die aktuellen Messwerte immer in einen Notifier speichern und in der Hauptschleife nur den letzten Notifier-Status abzufragen...

Ok, haste recht...aber was ich eigentlich meinte, zeigt die Hilfe (roter Rahmen):

   


Wenn man also "0" als Timeout angibt, wird trotzdem gemessen und sofort ein Fehler angzeigt, wenn keine Frequenz, d.h. keine Flankenwechsel auftauchen...dann kann man aber auch sofort den Fehler verarbeiten/unterdrücken und die Messung geht einfach weiter! So hab ich das "früher" (noch mit Traditional DAQ) jedenfalls auch schon gehandhabt...

A.

Davon würde ich aber abraten... Was passiert denn, wenn eine Frequenz von 1Hz anliegt? Dann dauert die Frequenzmessung mindestens 1s. Wenn man Timeout 0 anlegt, wird dann wohl ein Fehler ausgegeben, der falscherweise als 0Hz interpretiert wird...

Hier noch ein Link zum selben Thema...geht zwar um CVI, aber das Problem + die von NI vorgeschlagene Lösung ist ähnlich:

http://forums.ni.com/ni/board/message?boar...uireLogin=False

Und noch was:

http://forums.ni.com/ni/board/message?boar...uireLogin=False


Wie in diesen Threads schon erwähnt: Macht es überhaupt Sinn, eine sehr niedrige Frequenz mit nem Counter zu messen, oder würde hierfür nicht eine Analogmessung ausreichen? Counter benutzt man meiner Ansicht nach am sinnvollsten dann, wenn man (relativ) schnelle Frequenzen erfassen muss...eine Countermessung für ein 1-Hz-Signal macht nicht so viel Sinn, würde ich sagen...man muss halt irgendwie einschränken, was man messen will und wie lange man gegebenenfalls auf ein (ausbleibendes) Signal warten will...