.log Datei in Labview einlesen und graphisch darstellen

Hallo,

ich bin neu hier und auch erst seit kurzem mit Labview beschäftigt. Ich versuche momentan meinen Techniker in der Abendschule zu machen, und unser Lehrer war so lustig uns eine Aufgabe zu geben nach knapp 1 Halbjahr womit alle in meiner Klasse überfordert sind. Ich hoffe das ich hier die Hilfe bekomme,die ich benötige um die Aufgabe zu lösen.

Aufgabe:

Wir sollen das angehängte Logfile in LV einlesen(leider konnte ich die eigentliche Datei nicht anhängen, deshalb der Screenshot, es handelt sich letztendlich um 9 Werte die separiert und eingelsen werden müssen), zerlegen und graphisch darstellen. Hierbei ist zu beachten, das wir auch den Logfile keinen Einfluss haben, da dieser so von einer gebauten Maschine ausgegeben wird, welche wir im nächsten Schritt direkt auslesen sollen.
Um ehrlich zu sein, habe ich nicht die geringste Idee wo und wie ich überhaupt anfangen soll. Wir quälen seit 2 Wochen selber dadurch und kommen keinen Schritt weiter.

Ich bin für jede Hilfe dankbar.

Gruß

CHD

Anzeige

Die Struktur der Datei sieht nicht kompliziert aus. Woran hängt es denn eigentlich momentan konkret? Ihr habt sicher schon einiges ausprobiert und du könntest uns deine bisherigen Versuche als VI zeigen?

Im Allgemeinen würde ich folgendermaßen vorgehen:

1. Erstmal die Trennzeichen zwischen Zeilen und Werten herausfinden (z.B. Notepad++ oder einfach komplette Datei mit LabVIEW einlesen)
2. Datei mit "Read Text File" einlesen
3. Trennung des Dateiinhaltes in einzelne Zeilen mittels "Spreadsheet String to Array"
4. Trennung der einzelnen Werte mittels selber Funktion
5. Extrahierung der Zahlenwerte aus dem "Wertestring" der noch aus "Bezeichner = Wert" besteht. z.B. mittels "Match Pattern" oder "Scan from String"
   

Im Ergebnis bekommst dann für jede Zeile deine N Werte. Da es eine Aufgabe für die Abendschule ist, möchte ich dir nicht gleich eine fertige Lösung basteln. Bei konkreteren Fragen gibts natürlich konkretere Antworten

Vieles wäre mit dem Originalfile leichter zu beantworten als mit dem Screenshot. Pack das Teil in ein zip-Archiv und lade es dann hoch.

Auf Grund des Screenshots vermute ich:
Der File besteht aus Zeilen, die aber nur ein <LineFeed> als Zeilentrenner enthalten. Deshalb die ungünstige Darstellung im Windows-Editor.
Außerdem sind die einzelnen Werte mglw. durch ein <Tabulator>, zumindest sieht es im Screenshot so aus, als ob der Abstand zwischen den "Key-Value" Paaren unterschiedlich lang ist. Genaueres kann man aber nur mit Hilfe der Datei sagen.

Ich würde diese Datei mit "Read from Text File" im Modus "Read Lines" einlesen und dann jede Zeile einzeln verarbeiten. Dann die "Key-Value" Paare voneinander trennen, z.B. mit Hilfe von "Spreadsheet String to Array" mit geeignetem Spaltentrennzeichen. Dann kann man in einer For-Schleife die Key-Value-Paare verarbeiten. Alternativ jede Zeile stur mit "Scan from String" verarbeiten, dann erhält man direkt die 9 "Values".
EDIT: Zahlen dann am Ausgang der FOR-Schleife per AutoIndexing in Arrays sammeln und z.B. in einem Chart darstellen.

IMHO ganz einfach.

Gruß, Jens

EDIT: 2 Köpfe, 1 Meinung.

Nachtrag:
Bei deinen Parsereien musst du die Struktur (den Aufbau) deiner Datei beachten.
Gemäß Screenshot beginnt ein Datensatz mit Millis: 123456
Dann folgen 7 Parameter im Format Name=Wert
Geschlossen wird der Satz mit rpm: float

Dann geht´s wieder von vorn los.


Gruß, Marko

Guten Abend,

erst einmal sorry das ich solange mit einer Antwort haben warten lassen. Wir sind jetzt schon ein Stück weiter gekommen und haben schon einmal ein "Grundgerüst" aufgestellt. Das Problem was sich jetzt darstellt , ist folgendes.

Ich möchte in der angehängten Log Datei alle nicht relevanten Zeichen wie :,=, und Leerzeichen rausfiltern. Desweiteren soll nicht nur die Schnittstelle in einem Graph mit Kurvenform dargestellt werden, sondern auch schon die Logdatei quasi komplett eingelesen werden. Hierbei sollen ebenfalls Kurven der jeweiligen Werte dargestellt werden. Als X-Achse soll hierbei der Wert Millis fungieren, da dieser die Zeitliche Abfolge darstellt. Ich wäre sehr dankbar wenn man mir da zeigen könnte wie es geht, da ich wirklich keine Schritt mehr weiter komme.


Gruß und Danke

CHD

Hallo CHD,

wer auch immer das LOG-Format entworfen hat, sollte wegen der Mehrfach-SPACES öffentlich gerügt werden!

Vorschlag zum Einlesen der kompletten Datei und nicht nur einer Zeile:
   

Die Fehler in deiner LOG-Datei darfst du selbst ausbügeln! Was sollen die leeren Zeilen am Ende?

Anzeige

Hi,

das Problem mit der Log Datei ist, dass wir diese so von unserem Lehrer bekommen haben. Er hat diese so wie sie ist aus einer Apparatur ausgelesen, welche letzte Jahr von anderen Schülern im Rahmen der Projektphase gebaut wurde. Der Log ist auch nur der erste Schritt. Im zweiten Schritt müssen wir den ganzen Kram direkt von der lokalen Schnittstelle aus einlesen.

Hallo CHD,

dann sollte der Lehrer gerügt werden, weil er den Vorjahres-Schülern kein vernünftiges Dateiformat nahegebracht hat…

Zitat:Im zweiten Schritt müssen wir den ganzen Kram direkt von der lokalen Schnittstelle aus einlesen.

Das ist zwar ähnlich, aber ganz sicher mit einem besseren Formatstring zu erledigen. Und meist auch einfacher als das Einlesen eurer LOG-Datei…

Was bedeutet "lokale Schnittstelle" genau?

Hallo,

lokale Schnittstelle bedeutet über einen USB Anschluss wir das Gerät angeschloßen.

Kaum schaut man sich die Datei mit einem gescheiten ASCII-Editor an (der <Linefeed> auch als Zeilenumbruch darstellt), schon wird der log-File übersichtlich:
   
Da hat wohl jemand versucht, für einen ASCII-Editor eine Tabellendarstellung hinzubekommen, wenn auch mit einigen Schwächen. Gerds Meinung dazu kann ich nur zustimmen, Schwachsinn.

Hier noch eine Idee, wie man die 2-5 Leerzeichen in einem Aufwasch durch ein gescheites Trennzeichen (z.B. Tab) ersetzen könnte:
   

Und noch ein klein wenig
Beim Interpretieren des rpm-Wertes ist wohl irgendetwas falsch programmiert worden... Immer wieder der Wert 429496729.5, das ist aber ein schnell drehendes Teil. Mit 10 multipliziert ist das aber zufällig das Maximum eines U32-Integer (0xFFFFFFFF). Sollte der Wert aber zufällig ein I32-Datenformat haben, dann entspricht 0xFFFFFFFF = dezimal -1, mglw. somit eine Anzeige für einen "nicht gültigen Wert".

Gruß, Jens