schnelle+kontinuierliche Datenerfassung: Speicherproblem

Hallo,

zuerst eine kleine Beschreibung was ich machen will:
Ich möchte einen (oder später mehrere) analogen Eingang (+- 10 V, Kraftmessung) sowie einen Zähler (digitaler Zähler, A/B Signal zur Positionsbestimmung) zusammen, also zeitgleich, mit etwa 10 kS/s kontinuierlich aufzeichnen. Dazu verwende ich einen A/D Wandler der per USB angeschlossen ist (NI USB-6221; M-Serie, 16 bit, 250 KS/s).

Mein Problem ist die Speichernutzung, sowie die Geschwindigkeit des ablaufenden Programms (CPU Last 100% und Speicher läuft bis zum Abbruch voll), was eine kontinuierliche Aufzeichnung über einen längeren Zeitraum verhindert. Ich weiß, dass man das Programm an einigen Stellen verbessern kann, allerdings weiß ich nicht wie genau und bin daher für Hilfe sehr dankbar.

Was habe ich gemacht? (Im Folgenden ist mein VI in mehrere Screenshots unterteilt.)
Am Anfang initialisiere ich den Wandler mit Hilfe der DAQmx Module mit gewünschten Sample-Takt (wie im Example Finder auch zu finden). [siehe initialise.jpg]

Mittels einer Producer-Schleife werde die Daten von der Messkarte gelesen. [siehe producer.jpg]
Bei DAQmx-Read auf 1 Sample kann ich sichergehen, dass ich bei beiden Eingängen einen Wert bekomme, diese Einstellung ist leider zu langsam bei hohen Sampleraten. Daher lese ich nun immer NSamples pro Durchlauf. Damit kann ich auch Sampletraten von 100 kS/s einstellen, ohne dass der Buffer der Messkarte überschrieben wird. Frage: Kann ich mich darauf verlassen, dass die Aufzeichnung weiterhin synchron ist, ich also immer gleich viele Messdaten im gleichen zeitlichen Abstand bekomme?
Bei Abbruch des Programms wird der DAQmx-Task erst geschlossen und die Queue gelöscht, wenn die Warteschlange geleert wurde um keine Messwerte zu verlieren. Auf die unschöne Verwendung der dynamischen Daten komme ich nachher noch zu sprechen.

Das größte Problem liegt nun in der Consumer-Schleife: [siehe consumer.jpg]
Hier werden die dynamischen Daten aus der Schlange wieder in zwei einzelne Arrays zerlegt, der neuste Wert (das neuste 1D Array an Werten) dem Array hinzugefügt, das ganze in einem Schieberegister. Da ich aber annehme, dass mit jedem Ändern des Arrays ich neu Speicher alloziieren muss und die Arrays sehr schnell sehr groß werden (1M Einträge und mehr) wird alles sehr schnell sehr langsam bis zum Programmabbruch. Ich kann zwar vorher ein riesiges Array initialisieren, das braucht aber relativ lange und beschränkt mich dann auf die Größe dieses Arrays.
Fragen: Gibt es einen besseren Weg, beide Messreihen zu vereinen, als die dynamischen Signale zusammen zu fassen? Bei einem Versuch, verschieden große Arrays an ein existierendes 2D Array zu hängen kam ich nicht zurecht mit Spalten/Reihen/Größen/usw. (Trotz versuchtem Transponieren und verschiedenen Tests). Da habe ich irgendetwas übersehen oder einfach nicht gewußt.
Um das Problem mit dem Speicher zu umgehen, könnte man die Messdaten direkt auf die Festplatte speichern, dies ist auch das eigentliche Ziel. Wie stelle ich das an? Um jeden einzelnen Messwert zu schreiben, ist die Schreibroutine viel zu langsam, d.h. ich müsste, sagen wir alle 2-5 Sekunden, den Inhalt des Arrays auf Platte schreiben und danach den Speicherplatz wieder frei geben. Das alles ohne die weiterlaufende Messung zu unterbrechen oder zu stören. Dazu fehlt mir aber leider das Wissen.

Das Verarbeiten der gemessenen Daten [siehe processing.jpg] geschieht nach Beenden der Aufzeichnung, dies ist durch die Mittelwertbildung bedingt. Da ich gelesen hatte, dass bei jeder Verzweigung eine Kopie der Daten erstellt wird habe ich einen Ausweg gesucht und bin auf die Inplace-Struktur gestoßen. Dadurch werden, soweit ich das Verstanden habe, Pointer verwendet um die Daten direkt zu editieren, ohne zusätzliche Kopien im Speicher zu benötigen. Ich hoffe, dass ich diese Strukturen dementsprechend richtig verwendet habe. Alle aufgezeichneten Daten werden noch einmal in einem Graphen ausgegeben und dann gespeichert. Momentan sind zwei Speichermethoden implementiert, als Vergleich zueinander. Später werde ich das Express-VI löschen, da mir das eine wiederholte Wandlung in dynamische Daten erspart und entsprechend schneller und weniger speicherintensiv ist. Gibt es hier bessere Ansätze die Daten zu speichern? Abgesehen vom Streamen in der Consumer-Schleifer.

Abschließend wird der Speicher von LabVIEW freigegeben und das Programm beendet. Den Speicher muss ich explizit freigeben, da dies sonst nicht geschieht (Speicherauslastung bleibt entsprechend hoch). SubVI würden zwar bei der Übersichtlichkeit des Programms helfen, allerdings habe ich noch nicht genau herausgefunden wie ich Ein- und Ausgabemasken (Graphen usw.) an das Haupt-Frontpanel weiterleiten kann.

Im Anhang die entsprechenden angesprochenen Teilbilder des Programms.

Zusammenfassend ist das Ziel also eine relativ schnelle, endlose Aufzeichnung der synchronisierten und mit festen Sampleraten aufgenommen Messwerte.

Ich hoffe, dass mir jemand helfen kann, sei es mit Tips, Erklärungen oder Beispielen ;-)

Vielen Dank und schöne Grüße,
mh

PS Der Code ist in LabVIEW 8.6 geschrieben

Anzeige

Hallo,

nur kurz, da ich aktuell nicht viel Zeit habe:[list]
[*]Die Verwendung von dynamischen Daten ist eher schlecht, was du selbst festgestellt hast. Ich vermute, dass bei jeder Umwandlung des Dbl-Arrays in dynamische Daten und umgekehrt sämtliche Daten kopiert werden. Das ist langsam und hat eine hohe Speicherauslastung zur Folge. Vermeide dynamische Daten daher, wenn möglich.<>
[*]Wie du selbst richtig festgestellt hast, ist das einzig sinnvolle, die Dbl-Array zu Beginn zu initialisieren. Sonst wird das Array bei jedem Einfügen kopiert und das ist auf Dauer sehr langsam. Wenn die die Messzeit absolut nicht weißt, kannst du die Arrays auch z.B. mit 200.000 Werte initialisieren und diese schrittweise um 200.000 Werte vergrößern. Dann werden die Arrays zwar auch kopiert, aber viel seltener. Da musst du schauen, was für dich sinnvoll ist.
Evtl. reicht es auch, die Daten auf die Festplatte zu streamen ohne sie in den Arrays zwischenzuspeichern. Wenn du natürlich über tage mit 10 kS/S Werte einliest, läuft der Speicher irgendwann mal voll.

Kleine Beispielrechnung:

Messzeit: 1 Stunde
Datentyp: Double
Abtastrate: 10 kHz

macht für die eine Messkarte eine ungefähre Array-Größe von: 3.600 s * 8 Byte * 10.000 1/s = 288.000.000 Bytes = 282 MB
(wenn ich mich nicht verrechnet habe)
Bei 2 Kanälen, wie du sie hast, wären das 564 MB pro Stunde, die da an Daten zusammen kommen.

Misst du über einen Tag (ich weiß nicht, was für dich ein "längerer Zeitraum" ist), sind das ca. 13,5 GB, die du an RAM bräuchtest.
Da hilft nur noch ein Streamen auf die Festplatte.
<>
[*]DAQmx kann dir selbstständig die Messdaten auf die Festplatte speichern im TDMS-Format (s. hier). Ich weiß nicht, ob das mit LV 8.6 schon geht, sonst musst du das selbst umsetzen. Hierfür wurde das TDMS-Format u.a. entwickelt. Es ist also gut geeignet, um viele Daten fortlaufend zu speichern (binäres Format und kann mit eigenen Kommentaren versehen werden).
Ich weiß nicht, dass du in deinem ExpressVI zum Schreiben der Messdatei eingestellt hast. Im Zweifelsfall kannst du versuchen, die TDMS-VIs zu verwenden und auf das Express-VI zu verzichten.<>
[st]Ein recht hilfreiches Tool findest du unter "Werkzeuge -> Profile -> Leistung und Speicher" (oder so ähnlich).
Starte das Tool mit den entsprechend angehakten Optionen und lasse dein VI dann laufen. Wenn du das Tool dann wieder stoppst siehst du, welches VI am längsten braucht, welches am meisten Speicher benötigt etc.
Das gibt dir einen guten Anhaltspunkt, wo du mit der Optimierung ansetzen kannst.

Hi Mechatronik-Ingenieur,

danke für deine Antwort.

Ich würde auch gerne auf die dynamischen Daten verzichten, aber irgendwie mache ich bei dem Versuch einige Fehler, die ich nicht genau sehe. Wie schon oben beschrieben, hatte ich es nicht geschafft, die Daten der zwei 1D-Arrays in der richtigen Reihenfolge (Spalten/Zeilen) an ein existierendes 2D-Arrays zu hängen. Dies sollte an sich relativ einfach sein, aber naja, ich scheine was zu übersehen ;-) Ansonsten kann ich die Daten nicht bündeln und muss sie in zwei Warteschlangen stellen, was praktisch eine zweite Consumer-Schleife bedeuten würde. Dies wollte ich durch die Verwendung der dynamischen Daten vermeiden. Ob diese Entscheidung besser oder schlechter war, kann ich momentan nicht beurteilen.

Das Streamen der Daten wäre das Beste. Danke für den Link, den kannte ich bisher nicht. Ab DAQmx v9.0 sollte das ja implementiert sein. Mein "längerer Zeitraum" sind mehrere Stunden, da das Experiment unter Aufsicht abläuft. Das wären dann etwa 6-10 Stunden pro Tag, je nach Aufgabenstellung. Da bei mir aber der RAM begrenzt ist, muss ich die Daten ja irgendwie auf die Festplatte bekommen. Da kommt mir eine Zwischenfrage: Spricht LabVIEW mehr als 2 GB RAM an? Soweit ich weiß stellt ja Windows (zumindest 32bit) jedem Programm nur 2 GB zur Verfügung.

Momentan hatte ich das Express-VI auf ASCII-schreiben eingestellt, also Klartext. Dies verbraucht zwar mehr Speicher auf der Platte und ist meistens etwas langsamer, aber ich kann die Daten so ohne Probleme und Aufwand in verschiedene einlesen und Verarbeiten. Klartext ist aber nicht zwingend notwendig, ich kann die Daten auch jeweils bei Bedarf entsprechend dekodieren, das muss nicht während der Messung geschehen.

Mit dem Speichermonitor hatte ich schon gesehen, dass viel bei der Umwandlung in dynamischen Daten verlorengeht. Anfangs hatte ich auch oft Fehlermeldungen, da CreateSignalChunk.vi zu viel Speicher gefressen hat. Ich werde wohl Montag mein Programm ein wenig umschreiben und versuchen direkt die Daten auf Platte zu streamen und mich danach noch einmal melden. In der Zwischenzeit sind weitere Tips natürlich immer gerne gesehen, denn zu verbessern und zu lernen gibt es meistens etwas. :-)

Danke und gute Nacht,
mh10

So, ich bins noch einmal.

Leider habe ich keine Editierfunktion gefunden, daher der Doppelpost. (Falls es eine gibt, bitte eine Mitteilung an mich EDIT: OK, eine zeitlang kann ich wohl meine Posts editieren).

Ich habe heute ein paar Sachen geändert. Zum einen habe ich herausbekommen, wie ich die Arrays richtig aneinander hängen kann, was sich aber als sehr langsam herausgestellt hat. Eventuell habe ich da was unsinniges fabriziert. Die größte Änderung betrifft jedoch das Streaming, die ganze Nachbearbeitung der Daten lasse ich dabei erst einmal weg. Ich habe also jeweils vor Taskbeginn ein DAQmx-Protokollierung Baustein eingefügt. Er streamt jetzt meine Daten in zwei Dateien (1x Analog=Kraft und 1x Digital=Weg). Die Geschwindigkeit scheint kein Problem mehr zu sein, da ich auch die Arrays aus den Schleifen gelöscht habe, die Daten muss ich ja jetzt nicht mehr zwischenspeichern. Die Warteschlange dient dann nur noch dazu, die aktuellen Werte als Chart anzuzeigen. Ich habe testweise einige Minuten mit 100 kS/s aufgenommen und es hat alles geklappt. Nur beim Anzeigen oder Umwandeln der Daten weigert LabVIEW sich nun, aufgrund von Speicherproblemen.

Nachdem ich die Daten dann stückweise ins ASCII-Format gewandelt habe ist mir aufgefallen, dass ich jeweils zwei Spalten habe, eine Zeitspalte und eine mit den Werten. Beim digitalen Signal ist die Zeitspalte aber durchgehend 0. Habe ich da etwas falsch verdrahtet oder kennt jemand den Grund dafür? Auch beim TDMS-Dateimonitor gibt er mir für diese Datei ein Inkrement der 1. Spalte mit 0 an (wf_increment=0). Beim analogen Signal ist alles ok.

Frage: Gibt es einen Weg, beide Ströme zu vereinen, also zB nur einen Task zu erzeugen, der beides gleichzeitig aufnimmt und in eine Datei schreibt? Das würde der Übersicht sehr helfen und auch das Problem der Zeitspalte lösen. Eventuell gibt das aber dann ein Problem mit der Liveanzeige der aktuellen Messung in der Consumer-Schleife. KOmmt halt darauf an, was ich dazu wie umschreiben muss.

Viele Grüße,
mh10

Hallo

' schrieb:[...] 1x Analog=Kraft und 1x Digital=Weg [...]

Frage: Gibt es einen Weg, beide Ströme zu vereinen, also zB nur einen Task zu erzeugen, der beides gleichzeitig aufnimmt und in eine Datei schreibt?

Ich sitze aktuell an einer ähnlichen Thematik. Nur erhalte ich sowohl Kraft als auch Weg als analoges Signal (digitalisiert über die Messkarten 9203 und 9237). Mit welcher Karte liest du denn die digitalen Signale ein? Über eine Schnittstelle wie Profibus, eine serielle o.ä.?
Damit kenne ich mich leider nicht aus, da ich bisher nur mit Messkarten gearbeitet habe und die DI-/DO-Karten geben bei mir immer nur "high" oder "low" aus bzw. lesen das ein.

Bei den Analogkarten kann ich problemlos mehrere Kanäle in einen Task packen (nacheinander erzeugen und gleichzeitig auslesen). Das hat u.a. den Vorteil, dass die Daten synchron eingelesen werden.
Dazu musst du den Task jedoch über das DAQmx-VI "Create Task" bzw. "Task erstellen" erzeugen und dort die Kanäle hinzufügen. Das fehlt bei dir noch in den oben gezeigten Blockdiagrammen.

Hi Mechatronik-Ingenieur,

ich kam leider bisher nicht dazu dir zu antworten. Momentan geht es ein wenig hektisch zu mit Anträgen und solch einem Zeug.

Ich benutze den folgenden A/D-Wandler per USB angeschlossen: NI USB-6221; M-Serie, 16 bit, 250 KS/s

Als Kraftsensor benutze ich einen Zug-/Drucksensor mit +-2 kN maximaler Kraft. Das Signal wird auf +-10 V verstärkt und dann analog in den A/D-Wandler eingespeist (AI0).
Mein Wegsensor funktioniert auf Basis eines Hallsensors. Ein Magnetband (abwechselnd Nord/Süd polarisiert) wird am bewegten Schlitten befestigt und die Bewegung/Position mittels Hallsensoren (IC-ML) ausgegeben. Dabei könnte ich auch verschiedene andere Modi beim Sensor einstellen. Analoge Ausgabe, digitale Ausgabe, nur steigende Flanken, usw.; es gibt etliche davon;)Aber wenn mir der interne Chip bereits ein digitales Signal ausgibt (Kanal A/B in X4 Encoding) ist es ja am einfachsten dieses zu verwenden (Ctr0 Eingang; PFI8 (Kanal A) und 10 (Kanal B) wenn ich mich nicht gerade irre).

Mein momentaner Stand:
1. messen --> direkt auf Platte streamen (nochmals danke für den hilfreichen Link)
2. Daten in einer Schleife einlesen (ca. 1 Million pro Schleife; aufgrund von RAM Beschränkungen), Mittelwert bestimmen, Datei schließen
3. Daten in einer Schleife einlesen, per Mittelwert korrigieren (eliminiert u.a. Offsets), richtig skalieren, beliebig weiterverarbeiten oder einfach neu speichern, zB in ASCII-Format für andere Programme

Mit Tasks zusammenfassen hatte ich bisher nur im Zusammenhang mit analogen Tasks gelesen. Ich glaube ich muss es mir noch einmal genauer anschauen, ob nicht auch gemischte Aufzeichnungen (digital/analog) möglich sind. Von NI ist mir die Methode mit dem Sample-Takt zur Synchronisierung empfohlen worden, daher habe ich diese dann auch verwendet.

Mal schauen was ich mit den Daten dann anfangen kann. Den Rest der Woche werde ich hoffentlich ein paar Messreihen fahren können, dann wird sich auch herausstellen, in wie weit ich die Daten noch nachbearbeiten muss.

Für weitere Tips und Verbesserungen bin ich immer offen. Man lernt ja nie aus

Wünsche noch einen schönen Abend,
mh10

Hi,

nun ein neues Problem.

Ich habe ein paar Testmessungen vorgenommen und festgestellt, dass zum einen die Zeitspalte bei der Streaming Datei des Weges nach wie vor konstant 0 ist, was sehr unschön ist (siehe obige Posts). Der analoge Kanal enthält die richtige Samplerate, also Zeitspalte. Des weiteren stört mich sehr, dass wenn ich im Zähler unter 0 falle, also z.B. wenn ich gerade die Dekrementierungsphase des periodischen Signals beim Starten des Programms erwische, speichert LabVIEW zwar alles richtig, was positiv ist, aber alle negativen Werte zieht es konstant auf ein Minimum. Dieses Minimum ist unterschiedlich, bei einem Durchlauf z.B -10.568,325.

Wenn ich die Livedaten des Weges beim Aufzeichnen anschaue (CI-Position-Wegaufnehmer), ist alles in Ordnung. Der Weg schwankt zwischen negativen und positiven Werten (zB zwischen -1 und +1). Das Ganze wird gleichzeitig in eine Datei gestreamt. Jedoch sind nun alle negativen Werte SEHR negativ (siehe oben) und konstant auf einen Wert bis der Weg wieder positiv wird. Ich frage mich, warum??

Beispiel:
1 0,9 0,5 0,1 -0,2 -0,5 -0,3 0,6 (wird korrekt angezeigt beim Aufzeichnen (TDMS- Protokollieren und lesen)
1 0,9 0,5 0,1 -1E7 -1E7 -1E7 0,6 (das steht in der Datei)

Das Ganze schaut verdächtig nach einem Buffer underflow aus. Als ob nur unsigned int in die Datei geschrieben wird. Warum funktioniert aber alles mit dem analogen Signal? Da klappen auch die negativen Signale.
Ein Workaround ist, ein entsprechend hohes Offset bei der Wegbestimmung zu setzen, so dass die Werte nie negativ werden. Dies empfinde ich aber als nicht zufriedenstellend, da das Problem nur umgangen aber nicht genau erkannt und behoben wurde. Hat jemand dazu eine Idee oder einen Vorschlag?

Bei Bedarf stelle ich später noch mein aktuelles Programm rein (habe ich leider gerade nicht zur Hand).

Wünsche ein schönes Wochenende,
mh10

Hi Leute,

hier mein Update:

Ich hab mir selbst geholfen und auch längere Zeit mit dem Support verbracht. Herausgekommen ist Folgendes:

- Keine Aufzeichnungen von negativen Werten --> Bug in der TDMS Implementierung --> Abhilfe: Update auf die neuste DAQmx Version

- DAQmx-Protokollierung schreibt die Daten per DMA direkt auf die Festplatte ohne über den Arbeitsspeicher zu gehen
Vorteil: Sehr schnell
Nachteil (bisher): keine Kanalbündelung möglich, jeder Task schreibt kann nur in "seine" Datei schreiben, keine Zeitspalte beim Counter

Was ich nun gemacht habe um die CPU-Last und die Speicherauslastung zu reduzieren ist, dass ich nur eine feste Anzahl an Samples lese (hier entsprechend der Samplerate 10x pro Sekunde) und meine Consumerschleife doppelt so häufig abfrage. Dann wird die Signalverlaufsinformationen der analogen Messung extrahiert und den einfachen Doublewerten des digitalen (Counter-)Signals hinzugefügt, damit ich einen Signalverlauf erhalte (scheinbar ist es anders nicht möglich, da der Counterkanal kein Signalverlauf ausspuckt). Danach setze ich beide Signale zusammen und schreibe sie per TDMS schreiben in eine Datei.

Dies ist langsamer als die DAQmx-Protokollierung aber für meinen Fall immer noch ausreichend (~3-6 MB/s).

Später lese ich in einem anderen Programm meine Daten wieder ein, bestimme Offset, Amplitude und Phase, korrigiere die Messdaten und speichere sie erneut. (Dies ist aber eine andere Geschichte)

Anbei zwei Bilder. Einmal die Initiierung der Kanäle (digitaler Kanal muss(!) vor dem analogen gestartet werden, damit beide synchron sind) und einmal die Aufzeichnung mit der Kanalbündelung. (Das Blockdiagramm ist nun in LabvIEW 10, da ich einige Systemprobleme hatte und den Rechner neu installieren durfte.)

Das mit den Signalverlaufsinformationen extrahieren und beim anderen Kanal hinzufügen habe ich von hier: NI-Beispiel zur synchronen Datenaufzeichnung

Und wie immer: Wenn einer Verbesserungen oder allgemeine Tips hat, her damit, ich lerne gerne hinzu. ^_^

Schönen Gruß,
mh10

EDIT: Soweit es mich jetzt betrifft, sehe ich die größten Teile meines Ursprungsproblems als gelöst an und betrachte dies daher vorerst als abgeschlossen