INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Effizienzsteigerung: Data Viewing & Logging in QSM



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!

19.10.2015, 15:10 (Dieser Beitrag wurde zuletzt bearbeitet: 19.10.2015 15:23 von ExXeQtor.)
Beitrag #1

ExXeQtor Offline
LVF-Grünschnabel
*


Beiträge: 31
Registriert seit: Jul 2011

8.6
-
DE



Effizienzsteigerung: Data Viewing & Logging in QSM
Hallo,

ich habe über die letzten Monate zur Steuerung und DAQ einer selbstgebauten Hardware eine inzwischen ziemlich umfangreiche Queued State Machine (QSM) aufgebaut, bei der ich nun an einer Stelle an meine Grenzen komme. Zum Verständnis kurz:

*Ein Event Handler verarbeitet Eingaben vom Nutzer und sendet Prompts an die QSM
*Eine QSM - Communicator - (die eigentliche State machine), die zum Daten Holen (Treiber) und Processen gut ist
*Eine QSM - Data Consumer - die im Wesentlichen immer dann, wenn ein Datenpaket vom Communicator in die Queue gelegt wurde, dieses herausholt und
a) Zur Visualisierung in Charts steckt
b) in Textdateien loggt.

Mein problem nun ist, dass die Data Consumer QSM, obwohl sie nicht "viel" tut, immer ins Nachhängen kommt, was man an der Anzahl der wartenden Elemente in der zugehörigen Queue erkennt, die ab einer bestimten Datenmenge nur noch größer wird (also nicht mehr schnell genug abgearbeitet wird). Hierzu hoffe ich auf Tips von euch. Dazu im Anhang ein Bild der betreffenden QSM zum Nachvollziehen. das komplette VI darf ich nicht hochladen, nur die consumer qsm extrahieren geht nicht (weil mehr als 24 eingänge).

Zu den Fakten/ der Datenmenge:
Es gibt drei Typen von "Datenpaketen", die die Consumer-QSM erreichen.
- Der erste Typ kommt mit einer Samplerate von ca 500Hz und 6(channel)* 24Bit
- Der zweite Typ kommt mit einer Samplerate von 16Hz und 8(channel)* 24 Bit
- Der dritte Typ - Accelerometer im Bild - kommt mit 50Hz *4(channel)* 16Bit
Das bedeutet, es müssen pro Sekunde- neben den anderen Aufgaben des GUIs - ca. 10kByte an Daten visualisiert und geloggt werden.

Viele Channel werden durch einen eigenen Chart visualisiert, das heißt es gibt 16 Charts, mit jeweils History Lengths von 5000 Samples und zT deutlich weniger.
Das Data logging passiert in TXT dateien im ASCII CSV format für ein besseres Interface zu Software wie excel, matlab etc: Jeder Typ daten bekommt ein eigenes TXT - also wird in drei Daten geloggt.

Im Anhang kann man also sehen was passiert, wenn ein Datenpaket vom Typ "ACCEL" reinkommt: die 16Bit daten werden umgerechnet und dann direkt in die jeweiligen charts gesteckt sowie als CSV string an das log-file angehängt. So läuft es auch mit den anderen Datenpaketen.

DAS IST ZU LANGSAM!

Schalte ich das Data-Logging aus, bleibt die Anzahl der Queue-Elemente bei 1/0 - wird also immer schnell genug abgearbeitet. Wird in die files geloggt, steigt die anzahl der elemente pro sekunde um ca 10 - und das VI kommt nicht mehr hinterher.

Wie kann ich die Daten effizienter - aber bestenfalls im selben Format - loggen? Oder bleibt mir da nur binär, was die datenmenge enorm reduzieren würde, weil kein ASCII- was aber auch bedeuten würde, dass ich noch einen converter für später schreiben muss?

Ich freue mich über jeden hinweis!


Angehängte Datei(en) Thumbnail(s)
   
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
30
Antwort schreiben 


Nachrichten in diesem Thema
Effizienzsteigerung: Data Viewing & Logging in QSM - ExXeQtor - 19.10.2015 15:10

Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  insert data auf fetch recordset data ColdducK 9 6.903 23.12.2011 11:04
Letzter Beitrag: ColdducK

Who read this thread?
1 User(s) read this thread:
SirTom

Gehe zu: