Timeout bei FIFO Speicher

Hallo Leute,
ich schreibe gerade meine Masterarbeit und muss dafür eine Hochgeschwindigkeits Messung in Labview programmieren. Das Ziel ist 7 Signale mit jeweils 100kHz abzutasten. Dafür habe ich ein cRIO 9082 und 2 Module mit jeweils 4 analogen Eingängen. Nun habe ich schon herausgefunden, dass ich dafür wohl sowohl FPGA als auch den cRIO programmieren muss und habe mir mit Hilfe dieses Tutorials eine Anwendung gebastelt. Solange ich mir die Messdaten nur anzeigen lasse, erreiche ich auch die 10usec (100kHz) Abtastzeit. Sobald ich allerdings beginne die Daten in eine TDMS Datei zu schreiben dauert es vielleicht eine halbe Sekunde und ich bekomme einen Timeout. Ich vermute es liegt daran, dass die TDMS Datei nicht schnell genug geschrieben und damit der FIFO nicht schnell genug geleert wird.
Hat jemand eine Idee wie ich das Problem lösen kann?

Anzeige

Hallo otto,

Zitat:Sobald ich allerdings beginne die Daten in eine TDMS Datei zu schreiben dauert es vielleicht eine halbe Sekunde und ich bekomme einen Timeout. Ich vermute es liegt daran, dass die TDMS Datei nicht schnell genug geschrieben und damit der FIFO nicht schnell genug geleert wird. Hat jemand eine Idee wie ich das Problem lösen kann?

1. Producer-Consumer-Schema verwenden: Schleifen entkoppeln…
2. Willst du auf dem cRIO wirklich auf den Pfad "C:\Temp\" schreiben? Du weißt schon, dass das cRIO keinen Zugriff auf die Festplatte in deinem PC hat?
3. Du willst 7*100kS/s*8 Bytes = 5.35MiB/s wegschreiben? Auf dem cRIO? Wieviel Speicherplatz steht dir (dort) zur Verfügung? Wie schnell ist dieser Speicher?

Hall GerdW,
danke für die schnelle Antwort. Ich werde mal versuchen das ganze zu entkoppeln. Bei dem Pfad hast du recht, das hab ich auch schon festgestellt und habe den Pfad geändert. Das Bild ist davor entstanden.
Ja mir ist bewusst, dass das verdammt viele Daten sind. Laut Datenblatt hat das cRIO einen Speicher mit 32 GB, ich weiß allerdings nicht wie schnell der ist. Ich habe auch schon überlegt die Daten direkt übers Netzwerk wegzuschieben, aber dadurch wird es ja vermutlich noch langsamer oder?

Hallo otto,

- als erste Maßnahme könntest du die Datenrate halbieren, wenn du statt DBL einfach die original FXP-Daten speicherst
- beim Verzicht auf TDMS ersparest du dir weiteres (internes) Dateihandling: TDMS muss nebenbei auch noch Verwaltungsstrukturen befüllen/verwalten. Einfach eine simple Binärdatei speichern: du weißt doch, welche Daten wie darin landen!

Die FXP-Daten auf dem FXP sind wahrscheinlich <32 Bit breit (ein 9205-Modul liefert z.B. 26 Bit breite FXP-Werte). Die kannst du doch bequem als U32 verpacken und auf dem cRIO in eine Binärdatei speichern. Schon bist du auf 7*100k*4=2.7MiB/s runter. (Mit geringfügig mehr Aufwand kann man 7 FXP-Werte zu je 26 Bit (=182 Bit) auch in 6 U32-Werte (=192 Bit) reinpressen, damit würde sich die Datenrate auf 6*4*100k=2.3MiB/s senken.) Da man das dann schon auf dem FPGA macht, benötigt man dafür überhaupt keine Rechenzeit im RT-Host!
Für die Auswertung auf einem PC ist es irrelevant, wenn man einen zusätzlichen Schritt zum Auspacken der Daten einplanen muss: du verringerst auf dem cRIO die Datenrate immerhin um >=50%…

Zitat:Ich habe auch schon überlegt die Daten direkt übers Netzwerk wegzuschieben, aber dadurch wird es ja vermutlich noch langsamer oder?

Das cRIO9082 verfügt über Gigabit-LAN-Schnittstellen: hier bekommst du im Idealfall bis ~100MB/s übertragen!
Und LabVIEW bietet Network-Streams, die für solche Übertragungen gemacht sind: da musst du dich nicht mal selbst um TCP/IP-Handling kümmern!

Ich drehe hier langsam durch Ich bekomms einfach nicht ans laufen. Ich bin jetzt bei der Datenumwandlung schon mal von double auf Single umgestiegen um die Größe zu reduzieren. Das allein reicht allerdings noch nicht.
Wenn ich die Daten als binary anstatt TDMS abspeicher, läuft es genauso in den Timeout.
Ich habe probiert die Daten übers Netzwerk zu streamen. Das hat leider auch nicht so wirklich funktioniert.
Nun habe ich versucht das Schreiben der TDMS Datei in eine eigene Schleife auszulagern, allerdings klappt das auch noch nicht so richtig. Es werden zwar Daten geschrieben, allerdings, irgendwie nicht die richtigen. Vermutlich ist das mit der for Schleife so auch nicht richtig, aber ich weiß leider nicht wie ich es machen soll. Kann mir da bitte jemand helfen?
   

Hallo Otto,

dein letztes Bild ist ein krasses Beispiel für fehlendes THINK DATAFLOW!

Zitat:Ich habe probiert die Daten übers Netzwerk zu streamen. Das hat leider auch nicht so wirklich funktioniert.

Mangels VI kann man das nicht beurteilen…

Zitat:Nun habe ich versucht das Schreiben der TDMS Datei in eine eigene Schleife auszulagern, allerdings klappt das auch noch nicht so richtig.

Weil du es nicht richtig "versucht" hast…
Hast du dir mal die Beispiel-Projekte zur Producer-Consumer-Struktur angeschaut?

Zitat:Es werden zwar Daten geschrieben, allerdings, irgendwie nicht die richtigen.

Wenn du THINK DATAFLOW anwendest, weißt du auch, welche Daten geschrieben werden!

Zitat:Vermutlich ist das mit der for Schleife so auch nicht richtig

Nein, so natürlich nicht.
Was soll es bringen, eine FOR-Loop so oft ausführen zu lassen, wie die While-Loop zuvor iteriert hat?
Was soll es bringen, wenn man einen (einzelnen) Datensatz mehrfach in eine Datei speichert?

Zitat:Kann mir da bitte jemand helfen?

Und wie? Sollen wir mit Photoshop in einem Bild rummalen?

LabVIEW bringt jede Menge Beispiel-VIs mit - im ExampleFinder. Und es hat auch eine ganze Menge an Beispiel-Projekten, einfach mal in den "Neu…"-Dialog gehen!

Anzeige

Was bedeutet denn Think Dataflow?

Ich habe einen Netzwerkstream (RT-network.vi) erzeugt und in einem VI auf meinem PC (Networktarget.vi) die Daten wieder ausgelesen. Allerdings schreibt er mir dann nur Nullen. Irgendwie scheinen da keine Daten anzukommen.

Natülich habe ich auch nach Producer-Consumer-Schema gegoogelt, allerdings habe ich es nicht geschafft ein array mit hilfe dieser queue zu übertragen.

Das mit der FOR Schleife ist mir dann auch klar geworden. Es war halt ein verzweifelter Versuch. Ich weiß nun mal leider nicht wie es geht. Wäre super wenn du mir da einen Tip geben könntest.

Ich habe die VIs jetzt mal angehängt. Vielleicht hilft das ja weiter.

Hallo Otto,

Zitat:Was bedeutet denn Think Dataflow?

Ich habe da etliche Links in meiner Signatur, die solltest du mittlerweile sowohl bemerkt als auch gelesen haben…

Zum Network-Stream gibt es ein ganzes Beispiel-Projekt im LabVIEW-Beispielfinder. Hast du das studiert und ausprobiert?

Zitat:Natülich habe ich auch nach Producer-Consumer-Schema gegoogelt

Wieso googlest du, wenn dir LabVIEW ein komplett vorbereitetes Projekt anbietet?

Zitat:allerdings habe ich es nicht geschafft ein array mit hilfe dieser queue zu übertragen.

Im Beispielfinder gibt es das Beispiel "Einfache Queue"…

Zitat:Ich weiß nun mal leider nicht wie es geht. Wäre super wenn du mir da einen Tip geben könntest.

Wenn Dinge parallel arbeiten sollen, darf man sie nicht sequentiell programmieren - THINK DATAFLOW!
Tipp: mit LabVIEW mitgelieferte Beispiele studieren…

P.S.: Es ist auch nicht hilfreich, beim Namensarray für das TDMS-Schreiben hinter deinen 4 Kanalnamen noch 3 leere Stringelemente zu verstecken!

(16.09.2016 12:16 )GerdW schrieb:  Hallo Otto,

dein letztes Bild ist ein krasses Beispiel für fehlendes THINK DATAFLOW!

In LabVIEW 2016 würde das mit dem richtigen Draht schon gehen.
   
Gruß, Jens

Hallo Jens,

das haben aber weder Otto noch ich bisher im Einsatz.
Und ich glaube auch, dass das Otto noch mehr verwirren würde…