Messdaten Performance

Hallo zusammen,

Ich schildere mal kurz meine Anwendung und anschließend das Problem welches mich in den Wahnsinn treibt.

Anwendung:

Kein RT-System sondern Windows basierend.

Datenerfassung DAQmx Analogsignale 96 Kanäle 200S/s
Parallel Datenerfassung Temperatursignale 32 Kanäle 10S/s
Parallel Abspeicherung aller Messdaten in TDMS Format.
Parallel Messdatendarstellung in einem XY-Graphen während der Messung.

Ablauf:

Allg. Initialisierung der Hardware

Schleife 1 -> Erfassung der Analogsignale mit einer Samplerate 100000 / Sampleanzahl 500 / Mittelwerbildung über 500 Messwerte ergibt eine Abtastrate von 200S/s
Die Messwerte sowie ein Zeitstempel werden in eine Queue übergeben.

Schleife 2 -> Erfassung der Temperatursignale mit einer Samplerate 90 / Sampleanzahl 9 / Mittelwerbildung über 9 Messwerte ergibt eine Abtastrate von 10S/s
Die Messwerte sowie ein Zeitstempel werden in die gleiche Queue übergeben.

Schleife 3 -> Queueelemente werden ausgelesen und in eine TDMS Datei gespeichert.
Anschließend wierden die Daten aus dem TDMS File geladen und in ein XY Graphen übergeben, dabei kann ich die Anzahl der darzustellenden Messpunkte einstellen)

Das Problem bei der ganzen Sache ist, dass bereits nach ungefähr 5000 dargestellten Messpunkten im Graphen die Queue immer voller wird. 5000 Messpunkte sind auch nicht gerade viel, entspricht ca. 50ms.
Nach Ablauf der Messung werden die verbleibenden Elemente in der Queue solange ausgelesen bis nichts mehr da ist. Damit soll sichergestellt werden, das keine Messdaten verloren gehen.
Das Auslesen der Elemente dauert eine gefühlte Ewigkeit ungefähr 1min für 3000 Elemente.
Ihr könnt euch natürlich vorstellen wie unbefriedigend das ist. Ich möchte auch nicht die gesamte Messdauer darstellen (geht über 3 Wochen) aber 50ms sind mir zu wenig.

Ich habe es auch mit Signalverlaufsdiagramm und Signalverlausgraphen probiert, leider ohne Erfolg

Wie würdet ihr an die Sache dran gehen?

Was wäre die optimale Ansatz für so eine Anwendung?

Für einen Aufbauschema wäre ich dankbar.

Das Vi habe ich zur Zeit nicht da, kann es aber bei Bedarf hochladen.

Ich bedanke mich schon mal für die Unterstützung

Anzeige

..also das Auslesen von 3000 Messwerten aus einer queue sollte in "unmessbar" kurzer Zeit erledigt sein. Daran sollte es nicht liegen. Für mich liest sich deine Beschreinung so, dass das Problem in der weiteren Verarbeitung / Darstellung liegt. Das könntest du ja mal auskommentieren und prüfen, ob es dann läuft.
Der Rest ist für mich zu viel rumrätseln. So ohne VI wird es wohl schwer mit der Hilfe..

Gruß, Marko

(03.05.2019 21:07 )simcum schrieb:  Das Vi

Heißt das, dass es nur in einziges VI gibt? Würde ich nicht machen: Pro parallelem Ablauf ein VI.

Zweitens:
Lesen und Schreiben gleichzeitig in bzw. aus demselben File? Da blockieren sich aber zwei.

Danke für die Antworten, das Beste wird sein das Vi Hochzuladen.
Werde es kommenden Montag tun.

Bis dann

---

(03.05.2019 22:26 )Trinitatis schrieb:  ..also das Auslesen von 3000 Messwerten aus einer queue sollte in "unmessbar" kurzer Zeit erledigt sein. Daran sollte es nicht liegen. Für mich liest sich deine Beschreinung so, dass das Problem in der weiteren Verarbeitung / Darstellung liegt. Das könntest du ja mal auskommentieren und prüfen, ob es dann läuft.
Der Rest ist für mich zu viel rumrätseln. So ohne VI wird es wohl schwer mit der Hilfe..

Gruß, Marko

ja, das Auslesen der Queueelemente wird wahrschrinlich aufgrund der Grafischen Darstellung verlangsamt.

---

(04.05.2019 07:48 )IchSelbst schrieb:  

(03.05.2019 21:07 )simcum schrieb:  Das Vi

Heißt das, dass es nur in einziges VI gibt? Würde ich nicht machen: Pro parallelem Ablauf ein VI.

Zweitens:
Lesen und Schreiben gleichzeitig in bzw. aus demselben File? Da blockieren sich aber zwei.

Werde am montag mal die Schleife zum speichern und Grafische Darstellung voneinander trennen.

Wie würdet ihr sowas denn generell Programmieren?

Mir reicht ein simples Beispiel, damit ich eine Basis habe.

Hallo zusammen,

füge das Vi in die Attacment ein, so könnt ihr euch ein besseres Bild davon machen (LabView2016).

Hoffe auf Vorschläge

Bedanke mich

Hallo simcum,

Zitat:so könnt ihr euch ein besseres Bild davon machen (LabView2016).

, wenn du jetzt LabVIEW2016 verwendest!
Dein MainVI ist viel zu groß, da hat man keinen Überblick! Erstelle mehr subVIs!
Es fehlt eine Projektdatei! Wie willst du so dein LabVIEW-Projekt verwalten?
Deine subVIs haben keine aussagekräftigen Icons…
Zuviele unnötige CoercionDots…
IMHO Probleme beim DATAFLOW, wenn Controls außerhalb von Schleifen liegen…
Fehlende Typdefinitionen für Cluster etc.
Umständliche Arrayoperationen mit DeleteFromArray anstatt IndexArray…

Und: Parallel in ein und derselben Datei schreiben und lesen geht gar nicht!
In deiner Darstellungsschleife wird 6mal (inkl. Disabled-Struktur 8mal) lesend auf das TDMS zugegriffen und jedesmal am Offset/Datalength rungefummelt…

(09.05.2019 06:39 )GerdW schrieb:  Und: Parallel in ein und derselben Datei schreiben und lesen geht gar nicht!
In deiner Darstellungsschleife wird 6mal (inkl. Disabled-Struktur 8mal) lesend auf das TDMS zugegriffen und jedesmal am Offset/Datalength rungefummelt…

Da widerspreche ich: Gerade die TDMS-API gibt das her. Hier ein Beispiel von der NI-Seite: https://forums.ni.com/t5/Example-Program...anguage=en

Besonders effektiv ist das aber nicht, du hast die Rohdaten schon im Speicher beim TDMS-Write. Ich würde mir an dieser Stelle ein Ringbuffer-FGV erstellen für die Übertragung der Daten an die Graphen.

5000 Werte pro Kanal ergibt übrigens bei 200 S/s (und nur die gemittelten Werte schreibst du weg) eine Anzeigelänge von 25 Sekunden. Bei 96 Kanälen hältst du somit grob 500000 Datenpunkte im Speicher, da hat ein XY-Graph schon zu tun. Diesen Vorgang (also das Neuzeichnen aller Graphen) versuchst du mit derselben Rate aufzurufen wie die Datenspeicherung, und das sind bei den Einstellungen am Frontpanel (Sampleanzahl Sp = 500 bei 100 kHz) alleine schon 200 S/s. Mehr als 20 Hz Aktualisierungsrate bei einem Graphen macht aber gar keinen Sinn.

Gruß, Jens

Oder anders ausgedrückt:

1) Speichern seltener auslösen, 200 mal pro Sekunde ist auch schon viel.
2) Darstellung der Graphen NICHT so hart an den Speichertakt koppeln. Max. 10x pro Sekunde aktualisieren langt in der Regel.

Gruß, Jens

(09.05.2019 11:58 )jg schrieb:  

(09.05.2019 06:39 )GerdW schrieb:  Und: Parallel in ein und derselben Datei schreiben und lesen geht gar nicht!
In deiner Darstellungsschleife wird 6mal (inkl. Disabled-Struktur 8mal) lesend auf das TDMS zugegriffen und jedesmal am Offset/Datalength rungefummelt…

Da widerspreche ich: Gerade die TDMS-API gibt das her. Hier ein Beispiel von der NI-Seite: https://forums.ni.com/t5/Example-Program...anguage=en

Besonders effektiv ist das aber nicht, du hast die Rohdaten schon im Speicher beim TDMS-Write. Ich würde mir an dieser Stelle ein Ringbuffer-FGV erstellen für die Übertragung der Daten an die Graphen.

5000 Werte pro Kanal ergibt übrigens bei 200 S/s (und nur die gemittelten Werte schreibst du weg) eine Anzeigelänge von 25 Sekunden. Bei 96 Kanälen hältst du somit grob 500000 Datenpunkte im Speicher, da hat ein XY-Graph schon zu tun. Diesen Vorgang (also das Neuzeichnen aller Graphen) versuchst du mit derselben Rate aufzurufen wie die Datenspeicherung, und das sind bei den Einstellungen am Frontpanel (Sampleanzahl Sp = 500 bei 100 kHz) alleine schon 200 S/s. Mehr als 20 Hz Aktualisierungsrate bei einem Graphen macht aber gar keinen Sinn.

Gruß, Jens

Hallo Jens,

danke für die Anmerkungen. Werde Ringpuffer-FGV mal ausprobieren.
FÜr mich zum Verständnis, wenn die Aktualisierungsrate in einem Graphen reduziert wird, muss dann nicht aufgrund der unveränderten Anzahl an Messdaten, mehr Daten bei der Aktualisierung übertragen werden?
Ist das von der Performance besser?

Also verstehe ich das richtig, dass bei bei Aktualisierung der Daten im XY Graph alle Werte neu eingelesen werden.
Gibt es denn keine Möglichkeit nur die aktuell ausgelesenen Werte anzuhängen ohne alles neu einzulesen?

Wir setzen zum Beispiel auch andere Messsoftware ein, mit der Problemlos simultan 24 Kanäle mit 40Mhz Abtastung und 400000S/S als Trenddiagramm über mehrere Tage dargestellt werden können.
Es muss doch mit Labview bessere Möglichkeiten geben.

Hallo simcum,

Zitat:Es muss doch mit Labview bessere Möglichkeiten geben.

Ja klar! Aber die muss man eben programmieren…

Zitat:Wir setzen zum Beispiel auch andere Messsoftware ein, mit der Problemlos simultan 24 Kanäle mit 40Mhz Abtastung und 400000S/S als Trenddiagramm über mehrere Tage dargestellt werden können.

Diese Software wird aber nicht 1Kanal*40MS/s*3Tage*24h*3600s=10.4*10^12 Samples in einem Graph mit nur 600 Pixeln Breite darstellen!
Da wird sich jemand Gedanken gemacht haben, welche Datenmenge sinnvoll ist für die Darstellung…

Und diese Gedanken musst du dir eben auch mal machen! (Tipp: Bei einem Graph mit 600 Pixeln Breite sind mehr als ~1200 Werte pro Plot nicht sinnvoll…)