Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
' 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.
Hallo zusammen,
mich treibt eine im prinzip gleiche Frage um wie Mila.
Ich habe jetzt versucht den Timeout Fehler zu unterdrücken, aber es führt nicht zum gewünschten Ergebnis. Die Messung läuft nicht weiter, nachdem eine Frequenz unter 16 Hz anlag, bezieungsweise startet nicht, wenn die Frequenz unter 16 Hz liegt. Im Beispielprogramm unterdrücke ich meiner Meinung nach alle Fehlermeldungen, aber auch wenn ich nur die Timeoutmeldung (Fehler 200474) unterdrücke funktioniert es nicht.
Was mache ich bei der Fehlerunterdrückung falsch?
Vielen Dank schon mal.
Anzeige
05.02.2016, 16:54 (Dieser Beitrag wurde zuletzt bearbeitet: 05.02.2016 16:56 von GerdW.)
Zitat:Was mache ich bei der Fehlerunterdrückung falsch?
Musstest du dazu einen 9 Jahre alten Thread wieder hochholen?
Wenn man Fehler "unterdrücken" will, ist eigentlich schon alles zu spät: Dann ist der Fehler ja schon aufgetreten und du löscht ihn einfach nur.
Was würde passieren, wenn du die Minimalgrenze beim CreateChannel niedriger als "16 Hz" setzen würdest?
Was würde passieren, wenn du die Fehlermeldung beachtest und den Timeout anpasst?
Welche Hardware verwendest du überhaupt?
Bei sehr niedrigen Frequenzen kann man auch einfach die Zeit zwischen zwei Flanken messen…
Hallo Gerd,
erst mal Danke für's reagieren auf den wieder entfachten Thread. Ich habe diesen weitergeführt, weil dieser mein eigentliches Problem am besten beschrieben hat, ich aber leider die in diesem Tread beschriebene Lösung nicht umgesetzt bekommen habe.
Meine Hardeware ist die NI-USB 6218. Mein Hauptproblem ist ahnlich zu Mias Problem nicht, dass ich Frequenzen unter 16Hz messen möchte, sondern, dass die Messung wieder aufgenommen wird, sobald wieder eine relevante Frequenz anliegt.
Meine Vorstellung ist, solange die Messwerte valide (Messwert größer 16Hz) Schreibe ich mir die Messwerte weg, wenn (Messwerte kleiner 16Hz) schreibe 0 für Stillstand.
Den Timeout habe ich meiner Meinung nach so stehen, dass das "DAQ max-Lesen" nur einmal versucht die Frequenz zu lesen. Damit möchte ich Verhindern, dass meine dann paralell laufenden Messungen auf den Timeout warten müssen.
Zitat:Den Timeout habe ich meiner Meinung nach so stehen, dass das "DAQ max-Lesen" nur einmal versucht die Frequenz zu lesen. Damit möchte ich Verhindern, dass meine dann paralell laufenden Messungen auf den Timeout warten müssen.
Ich habegerade dein Gerät simuliert und eine Task angelegt (F_min=3Hz, F_max=500Hz). Wenn du das mit einem TimeOut von 0.5s kombinierst, sollte die Messung halbwegs funktionieren…
Wies sollen parallel laufende Messungen von einem TimeOut des Frequenz-Tasks gestört werden?
(08.02.2016 11:36 )GerdW schrieb: Hallo Reiling,
Ich habegerade dein Gerät simuliert und eine Task angelegt (F_min=3Hz, F_max=500Hz). Wenn du das mit einem TimeOut von 0.5s kombinierst, sollte die Messung halbwegs funktionieren…
Wies sollen parallel laufende Messungen von einem TimeOut des Frequenz-Tasks gestört werden?
Hallo Gerd,
ich meine, dass so lange "DAQ max-Lesen" keine Ausgabe leifert und bis zum Timeout wartet, die Schleife nicht abgearbeitet werden kann. Das Problem tritt ja nur auf, wenn keine Frequenz anliegt und ich dann wieder starten möchte. Ansonsten kann ich klar den Timeout nach der kleinsten zu erwartenden Frequenz wählen, das bringt mich aber noch nicht weiter.
Könntest du mir bitte kurz einen screenshot von der Simulation der Taskwerte anhängen, das wäre nett. Mein Stand war, dass es nicht Möglich ist Vorgabewerte Für Eingänge an simulierten Geräten zu erstellen.
um den Einfluss des Timeout zu zeigen habe ich das Beispiel VI noch mit einer Zufallszahl in der Messschleife ausgestattet, an der die Problematik sehr gut zu sehen ist. So lange das DAQmx Lesen eine Wert zum lesen hat ist alles paletti und das VI arbeitet einwandfrei. Liegt kein wert zum lesen an wird nach dem Timeout die Schleife auch wieder durchlaufen. Der Fehlerbehandler leistet also seinen dienst. Darum der ursprüngliche Versuch, das Timeout auf 0 zu stellen, damit einmal abgefragt wird, ob ein Messwert zur Verfügung steht und dadurch auch dann eine schnelle Abarbeitung der DAQmx Lesen erfolgt, wenn kein Wert verfügbar ist. Was isch nicht verstehe, ist, warum DAQmx Lesen bei erneutem anliegen einer Frequenz, also eines Messwertes, dennoch keinen Wert liest.
Ich hatte das ganze schon einmal mit Flankenzählung und der differenz der Zählerstände gelößt, fände es aber dennoch nett, wenn ich die beschriebene Problematik verstehen würde.
Das ganze funktioniert jetzt so lange ich die Zeit für das Timeout, an die niedrigste Frequenz anpasse (hier 1s/16Hz=0.0625s), die es zu Messen gilt. So weit so schön, wären da nicht noch andere Messaufgaben, die ich mit beispielsweise 300 Hz Abtastrate aufnehmen muss. => Ich kann mir bei diesem Aufbau keinen Timeout leisten, der die 300 Hz Abtastrate der anderen Messungen behindert, zumal hierfür auch noch rechenzeit benötigt wird.
Den Task nur alle x Iterationen auszulesen bringt mir in sofern nichts, dass ich dann im Falle eines Timeoutes innerhalb dieses Lesevorgangs immernoch die Länge des Timeoutes brauche.
Einen Versuch jeweils nur ein Sample zu lesen und bei einem Fehler den Task zu stoppen und zu starten und dann erst wieder ettliche Iterationen später wieder ein Sample versuchen zu lesen war leider auch erfolglos. Beispiel_3
Danke für die Denkanstöße und für neue
11.02.2016, 13:57 (Dieser Beitrag wurde zuletzt bearbeitet: 11.02.2016 13:59 von GerdW.)
Zitat:Das ganze funktioniert jetzt so lange ich die Zeit für das Timeout, an die niedrigste Frequenz anpasse (hier 1s/16Hz=0.0625s), die es zu Messen gilt.
Ja, an sowas muss man als Programmier denken. Zum Glück kann man das ja auch durch eine Rechnung erledigen…
Zitat:So weit so schön, wären da nicht noch andere Messaufgaben, die ich mit beispielsweise 300 Hz Abtastrate aufnehmen muss.
Was hat das eine mit dem anderen zu tun?
Wo ist da jetzt der Zusammenhang?
Zitat:Ich kann mir bei diesem Aufbau keinen Timeout leisten, der die 300 Hz Abtastrate der anderen Messungen behindert, zumal hierfür auch noch rechenzeit benötigt wird.
Wieso behindert deine Frequenzmessung irgendwelche anderen Tasks?
Abgesehen davon: die Art und Weise, wie du eine Taktrate für deine Messschleife berechnest, ist hochgradig unsinnig: erstens hast du da einen CoercionDot (und der hat eine Bedeutung!) und zweitens kann man statt y=1/x*1000 auch y=1000/x schreiben (RubeGoldberg!). Und LabVIEW kennt auch Funktionen wie "+1", "-1" und "1/x"…
Zitat:Einen Versuch jeweils nur ein Sample zu lesen und bei einem Fehler den Task zu stoppen und zu starten und dann erst wieder ettliche Iterationen später wieder ein Sample versuchen zu lesen war leider auch erfolglos. Beispiel_3
Was wolltest du damit erreichen? Auch Beispiel4 liest immer nur ein Sample aus…
[quote]So weit so schön, wären da nicht noch andere Messaufgaben, die ich mit beispielsweise 300 Hz Abtastrate aufnehmen muss.
Was hat das eine mit dem anderen zu tun?
Wo ist da jetzt der Zusammenhang?
Angenommen die Zufallszahlen stellen die andere Messaufgabe dar, dann werden diese nicht mehr innerhalb des Timings abgearbeitet, wenn die Wartezeit der Frequenzmesung zu groß ist. Also im Beispielfall dann im Timeout Fall maximal noch 16Hz. Muss ich hierfür dann die Frequenzmessung auslagern und parallel ausführen und die Daten dann übergeben, und wenn ja wie? Bisher sind die restlichen Messaufgabe Analogmessungen, die ich in einer Schleife, alle mit der Selben Abtastrate ausführe.
Fehler:"-200747" Danke für die Rückmeldung