LabVIEWForum.de - Timeout bei FIFO Speicher

LabVIEWForum.de

Normale Version: Timeout bei FIFO Speicher
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2
Ich habe mich jetzt nochmal am Einsatz einer Queue versucht und habe die Prozesse Daten anzeigen und Daten abspeichern in eigene Schleifen ausgelagert. Ich kann es leider erst am Montag testen. Kann mir jemand sagen ob ich das so richtig angelegt habe?
Hallo Otto,

Zitat:Kann mir jemand sagen ob ich das so richtig angelegt habe?
Prinzipiell ja, aber in der speziellen Ausführung: Nein.

1. Queues funktionieren nach dem Prinzip: "viele Quellen, eine Senke". Dummerweise hast du aber eine Quelle und 2 Senken programmiert!
Lösung dafür: entweder nur eine Datensenke verwenden oder der erste Consumer leitet Daten weiter in eine zweite Queue für einen zweiten Consumer…

2. Das gleiche gilt für die Queue mit der Stopp-Bedingung. Hier ist die Lösung aber trivialer: verwende einen Notifier! Diese arbeiten nämlich nach dem Prinzip "eine Quelle, viele Senken"…

3. Du hast kein Timeout bei den QueueRead-Funktionen vergeben. Dies kann (muss aber nicht) hinderlich sein, wenn man ein Programm kontrolliert beenden will…
Zitat:1. Queues funktionieren nach dem Prinzip: "viele Quellen, eine Senke". Dummerweise hast du aber eine Quelle und 2 Senken programmiert!
Lösung dafür: entweder nur eine Datensenke verwenden oder der erste Consumer leitet Daten weiter in eine zweite Queue für einen zweiten Consumer…
Danke für den Tip. Ich habe jetzt das Schreiben der TDMS Datei und das Diagramm in eine Schleife mit nur einer Senke gesetzt.

Zitat:3. Du hast kein Timeout bei den QueueRead-Funktionen vergeben. Dies kann (muss aber nicht) hinderlich sein, wenn man ein Programm kontrolliert beenden will…
Ich habe mal einen Timeout von 1000ms gesetzt. Was wäre hier denn ein sinnvoller Wert?

Das Programm läuft jetzt so und die Daten werden auch bei 10us Abtastrate aufgezeichnet. Allerdings sind es gefühlt zu wenig Daten. Bei 10us müssten ja 100k Werte pro Sekunde gespeichert werden. Nach 5 Sekunden habe ich aber erst etwas über 200k Werte. Es wird aber auch kein Fehler ausgegeben.
EDIT: Ich habe grade festgestellt, dass die Abtastrate wohl im laufenden VI nicht an das FPGA weitergegeben wird. Das heißt er nimmt nur den Wert, der am Anfang eingestellt ist. Und wenn ich da 10us am Anfang einstelle, bricht das Programm auch ab. Fehlermeldung:
Dequeue Element in RT_parallel.vi Error 1122
Hallo Otto,

Zitat:Ich habe mal einen Timeout von 1000ms gesetzt. Was wäre hier denn ein sinnvoller Wert?
Du solltest einen Timeout setzen, der dich nicht stört, wenn du die Schleife beenden willst. Mancher User ist irritiert, wenn ein Programm ein paar Sekunden gefühlt "stehen bleibt", bevor es irgendwie reagiert: wenn du Daten alle 20ms erwartest, sollte ein Timeout von 100ms mehr als ausreichend sein…

Zitat:Allerdings sind es gefühlt zu wenig Daten. Bei 10us müssten ja 100k Werte pro Sekunde gespeichert werden. Nach 5 Sekunden habe ich aber erst etwas über 200k Werte. Es wird aber auch kein Fehler ausgegeben.
Da hilft nur debuggen:
- einfach mal die Samplerate im FPGA überprüfen (wirklich: ich hatte mal ein DIO-Modul mit max. 140kHz im FPGA programmiert und habe mich gewundert, dass augenscheinlich nur 60kHz Samplerate erreicht wurden…)
- die Anzahl der vom FPGA gelesenen Samples überprüfen und mit den Erwartungswerten vergleichen
- die Anzahl der per Queue übertragenen Datenpakete überprüfen und mit den Erwartungswerten vergleichen
- die Anzahl der geschriebenen Daten überprüfen und mit den Erwartungswerten vergleichen
Ich habe die Wartezeit in der Schleife "Daten von FPGA holen" auf 1 ms runtergesetzt und jetzt läuft es und produziert Unmengen von Daten Cool

Vielen Dank für deine Hilfe
Hallo Otto,

genau dort solltest du gar keine zusätzliche Wartezeit programmieren!
In dieser Schleife ist das FIFO.Read der zeitlimitierende Faktor: hier gibst du vor, 2100 Samples zu lesen. Zusammen mit der Samplerate im FPGA ergibt das genau die Zeit, die in dieser Schleife gewartet werden muss (bis hin zum Timeout von 1s)…
Seiten: 1 2
Referenz-URLs