Format Strings

hi
ich hab da ein kleines problem mit dem einlesen von daten. die sind folgendermaßen gespeichert:

Code:

*DATA
13.04.2009 16:29:14.680;953,0;27,4;25,8;3,41
13.04.2009 16:29:14.779;953,0;27,4;;
13.04.2009 16:29:14.879;954,0;27,4;;
13.04.2009 16:29:14.979;953,0;27,4;;
13.04.2009 16:29:15.078;952,0;27,4;;
13.04.2009 16:29:15.178;954,0;27,4;;
13.04.2009 16:29:15.277;954,0;27,4;;
13.04.2009 16:29:15.377;954,0;27,4;;
13.04.2009 16:29:15.477;953,0;27,4;;

also zuerst datum und zeit, und dann noch druck und 2 verschiedene temperatur kanäle. ich les das jetzt mit der read from spreadsheet file.vi ein allerdings bekomm ich die trennung der einzelnen kanäle nicht hin.
welchen format string muss ich da verwenden damit der mir die spalten einzeln ins array reinschmeisst?

mein versuch wär mal der gewesen:

Zitat:%s; %,f; %,f ; %,f ; %,f ;

allerdings klappt das nicht so richtig

Anzeige

Mit dem VI "Read from Spreadsheet File" wirst du nicht glücklich werden. Da deine erste Spalte Datum/Uhrzeit ist, kannst du das mit diesem VI eigentlich nur als 2D-Array of Strings einlesen, also Format-String %s, Spalten-Trennzeichen ; (Nebenbemerkung: Der Format-String Eingang gilt immer für jedes Element der gesamten Tabelle, nicht für eine Zeile, so wie du es scheinbar versuchst.)

Dann musst du jede (bzw. zumindest die erste) Spalte des 2D-Array einzeln behandeln.

Gruß, Jens

Hallo physiker,

das speichern scheint ja jetzt schon mal zu klappen - nun macht das wieder einlesen Probleme?

Zu deinem Formatstring:
Es gibt eine wunderbare Übersicht aller FormatCodes in der LV context help. Einfach mal durchklicken.
Einen Formatstring wie "%,f" gibt es nicht! Was du benötigst ist "%f". Da du mit deutschen RegionalSettings arbeitest, würde ich dir noch den Code "%,;" ans Herz legen, damit deine Daten auf jedem PC korrekt geladen werden. Zum Umwandeln des Zeitstrings gibt es auch spezielle Formatcodes, einfach mal die Hilfe durchlesen. Persönlich bevorzuge ich den Tab als Trennzeichen, der "Text" ist meist besser lesbar...

Abgesehen davon: wie Jens schon schrieb, musst du erst die Tabelle als String einlesen und dann die erste Spalte getrennt bearbeiten.

Es gibt noch eine andere Möglichkeit: Zeilenweise mit for-Schleife einlesen und jede Zeile sofort konvertieren.
Und beim Zeitstring hast Du Glück: In Deiner Datei wird haargenau die "Landestypische Datums und Zeitangabe" benutzt. Dafür gibt es das Formatierungszeichen %c. Zusammen mit der Millisekundenangabe und dem immer zu benutzenden Zeitcontainer wird daraus <%c%3u>T.
   

  Plot.vi (Größe: 12,62 KB / Downloads: 428)

@GerdW
das erste programm is schon fertig :-) also gleich zum nächsten. dabei benutz ich die daten die ein anderes programm(nicht LabVIEW) speichert. also kann ich an der grundformatierung nix ändern. also leider keine englischen kommas.

zu den formatstrings: in der hilfe stehen zwar einige allerdings weiss ich noch nicht ganz wie man verschiedene formatierungen zusammenfasst. da gibts einige ";"...kann man mit denen nicht eine ganze zeile auf einmal auslesen?

so quasi einen array aus strings wobei man das ";" als trennzeichen angibt. was heisst "%,;%<%c%3u>T;%f;%f" zb genau?

@luki
leider geht das programm bei mir nicht aber so in etwa hätt ichs mir auch vorgestellt. wieso muss man das eigentlich zeilenweise auslesen? kann man nicht gleich die ganze file in einen array speichern und dann zeilenweise verändern?
[code]Error 1 occurred at Scan From String (arg 1) in Plot-1.vi

Possible reason(s):

LabVIEW:

bis zum scan from string klappt alles super. dort stimmen die formatstrings ned. ich tipp mal auf den zeitstempel formatireungsstring :-(

Anzeige

' schrieb:@luki
leider geht das programm bei mir nicht aber so in etwa hätt ichs mir auch vorgestellt. wieso muss man das eigentlich zeilenweise auslesen? kann man nicht gleich die ganze file in einen array speichern und dann zeilenweise verändern?
[code]Error 1 occurred at Scan From String (arg 1) in Plot-1.vi

Ja, dann gehörst Du zu jener bedauenswerten Unterschicht, die kein Laufwerk D besitzt. Da ist nichts zu machen, das Programm wird erst laufen, wenn Du eins nachgekauft hast:mellow:Oder hat jemand eine andere Idee?
Zeilenweise einlesen: Ich habe ja gesagt, daß es eine von mehreren Möglichkeiten ist. Einen lebenswichtigen Vorteil hat das nur beim Einlesen großer Dateien, da die ganze Textdatei gar nicht erst in den Speicher kommt.
Zum Pro und kontra kann ich nur sagen: Deine Argumentation "muß man das eigentlich" klingt ja so, als ob das eine umständliche Methode wäre. Es gibt hier im Thread leider nur das ein funktionierendes Beispiel, und das ist zeilenweises Einlesen. Wenn Du ein funktionierendes alternatives Beispiel vor Augen hättest, käme Dir wahrscheinlich die Erkenntnis: Zeilenweise einlesen ist hier nicht umständlicher, sondern eher einfacher.

Hallo physiker,

"was heisst "%,;%<%c%3u>T;%f;%f" zb genau?"

"%,;" - das Komma als Dezimaltrennzeichen für den restlichen Formatstring einstellen (wichtig für die Gleitkommazahlen)
"%<>T" - beschreibt den Zeitcontainer mit %c für die lokal eingestellte Formatierung der Zeitdaten und %3u dreistelliger ms-Angabe
";" - ein Semikolon im Text
"%f" - eine Gleitkommazahl
";" - noch ein Semikolon
"%f" - noch eine Zahl...

ScanFromString sucht nach genau den Werten, die der Formatstring beschreibt. Deshalb bietet sich das zeilenweise Auswerten an - oder willst du alle Formatcodes für ein komplettes Array (mit möglicherweise unbekannter Anzahl Zeilen) in den Formatstring schreiben?

' schrieb:bis zum scan from string klappt alles super. dort stimmen die formatstrings ned. ich tipp mal auf den zeitstempel formatireungsstring :-(

' schrieb:Ja, dann gehörst Du zu jener bedauenswerten Unterschicht, die kein Laufwerk D besitzt. Da ist nichts zu machen, das Programm wird erst laufen, wenn Du eins nachgekauft hast:mellow:Oder hat jemand eine andere Idee?

Ich glaube, das hat physiker13 nicht gemeint mit Fehler 1. Diese Fehlermeldung kommt bei ihm direkt vom "Scan From String".
Erst mal ein Screenshot:
   
Das obere VI liefert (auch bei mir) eine Fehlermeldung, das untere dagegen nicht. Man beachte den feinen Unterschied, oben sind die Sekundenbruchteile mit Punkt abgetrennt, unten mit Komma.
Im Gegensatz zu Lucki steht mein LabVIEW auf "use localized decimal point", erwartet also ein Komma als Trennzeichen. Daher habe ich offensichtlich ein Problem mit dem Punkt im Zeitstempel-Format als Trennzeichen für die Sekundenbruchteile -> Error 1 at Scan from String!

Ich habe versucht, das durch zusätzliche Vorgabe von %.; im Timeformat oder durch explizite Eingabe des Timeformat-Strings inklusive Punkt, so wie im Screenshot zu sehen, zu lösen. Geht leider nicht. Da muss NI nachbessern, ganz klar...

Lösung für physiker13:
1) Du stellst auf "nicht-lokalisierten Dezimalpunkt" um.
2)    

Und zum Abschluß, in deinem hochgeladenen VI solltest du am "Read from Spreadsheet VI" am Delimiter-Eingang unbedingt ein ";" anschließen:
   

Gruß, Jens

' schrieb:Erst mal ein Screenshot:
[attachment=49862:Image01.png]
Das obere VI liefert (auch bei mir) eine Fehlermeldung, das untere dagegen nicht. Man beachte den feinen Unterschied, oben sind die Sekundenbruchteile mit Punkt abgetrennt, unten mit Komma.

Im Gegensatz zu Lucki steht mein LabVIEW auf "use localized decimal point", erwartet also ein Komma als Trennzeichen. Daher habe ich offensichtlich ein Problem mit dem Punkt im Zeitstempel-Format als Trennzeichen für die Sekundenbruchteile -> Error 1 at Scan from String!

Zuerst mal muß ich erklären, daß ich das Komma als Dezimaltrennzeichen total aus meinem System verbannt habe. Also bereits die Windows-Voreinstellung ist Dezimalpunkt. Es macht demzufolge bei mir in LabVIEW keinen Unterschied, ob ich das lokalisierte oder das LabVIEW-System Dezimalzeichen verwende.

Mir ist schon früher aufgefallen, daß beim Zeitstring der Dezimalpunkt anders behandelt wird als normal. Das sieht man auch schon an der Textdatei im Posting #1: Sie wurde offensichtlich mit Laview generiert, mit Komma els Dezimalzeichen. Das Dezimalzeichen für die Sekundenbruchteile ist aber trotzden ein Punkt!

Und bei beim Rückwärts-Vorgang (Datums/Zeitstring zu Zeitstempel) gibt es die gleichen Merkwürdigkeiten.
   
Mit Dezimalpunkt geht alles in Ordnung, mit Komma gibt es für mich mit dem %c -Formatierungszeichen überhaupt keine Möglichkeit, den String zu konvertieren. Allerdings kommt auch keine Fehleremeldung. Das Zeichen %,; bewirkt nichts, eingefügte Kommas bewirken auch nichts. Wahrscheinlich wird es mit dem ausführlichen Zeit-Formatstring irgendwie gehen, habe jetzt nur keine Lust das zu probieren.
Ich betrachte das aber nicht als Bug, sondern eher als einen Schritt in die richtige Richtung: das deutsche Komma mehr und mehr links liegen zu lassen. (So wie ich es schon für für mich getan habe )