unflatten from string- zu große Daten Menge

Hallo rolfk,

ja das ist mir jetzt schon bewusst, danke auch dafür, aber wie kann ich dies mit der genannten Anforderung kombinieren/vereinen?

Zitat:Der Grund warum ich das Read/Write to Text File verwende ist damit ich zu Beginn der "Daten" ein Header schreiben kann mit Infos. Genauer gesagt eine Info welche Version des Cluster hier verwendet wird.
Später soll dies beim Laden berücksichtigt werden und das jeweilige Cluster als Datentyp verwendet werden.
Damit kann das Cluster weiterentwickelt werden und ältere Daten sollen geladen werden können.

Mit Write To BinaryFile kannst du auch ganz normalen Text schreiben. Der bleibt auch lesbar. Einzig für mögliche Zeilenumbrüche musst du selber sorgen.
Probieren geht über studieren!

Gruß, Jens

Ja Text bleibt lesbar, das Problem ist jedoch, das man am type Eingang des "Unflatten From String" den Cluster angeben muss, ist dieser wie gesagt zwischenzeitlich nicht mehr derselbe, geht es natürlich nicht.
D.h. ich muss erst eine Versions Info bekommen und dann kann ich dementsprechend handeln.

(06.07.2012 11:29 )GT123 schrieb:  Ja Text bleibt lesbar, das Problem ist jedoch, das man am type Eingang des "Unflatten From String" den Cluster angeben muss, ist dieser wie gesagt zwischenzeitlich nicht mehr derselbe, geht es natürlich nicht.
D.h. ich muss erst eine Versions Info bekommen und dann kann ich dementsprechend handeln.

Das macht man indem man den Header String zuerst schreibt und dann den Cluster, und das gleiche in gleicher Reihenfolge auch wieder beim Lesen. Ist doch nicht so schwer!

Der Königsweg wäre dabei vermutlich LVOOP zu nutzen. Die verschiedenen Varianten des Strings fungieren als Kindklassen einer Elternklasse die die Methode für das Ausspeichern enthält, sowie für das wieder einlesen. Die Einlesefunktion nutzt du dann einfach in der Elternklasse und kannst damit jede beliebige Kindklasse die du ausgespeichert hast wieder laden (da die Kindklassen auch auf einem wire der Elternklasse weitergeleitet werden).

Das einzige was du dann noch machen musst wäre ein "to more specific class", wenn du Zugriffe hast die du nicht über die Elternklasse und dynamic dispatching implementieren kannst. Dazu musst du dann einmal "rausfinden" welche Klasse wirklich instanziert ist (im Einfachsten Fall kannst du das in der Elternklasse als Attribut hinterlegen).


Ansonsten für deinen Zeck: File öffnen --> Referenz benutzen für ein Write to Text file um den Header zu schreiben (dann macht der dir auch auch automatisch deine Zeilenenden nach jedem Write rein --> per Write to Binary File die eigentlichen Daten in das File schreiben --> File Referenz schließen.

Rückwärts entsprechend erst den header lesen und dann wieder per read from binary auslesen. Aus dem Header kannst du ja dann wieder darauf zurückschließen was du ausgespeichert hattest.

Hallo Kiesch,
danke für die Ispiration mit dem Königsweg.
Hierzu gehen die Meinungen im Forum auseinander:

Zitat:Geschrieben von Kiesch - 06.07.2012 19:16
Ansonsten für deinen Zeck: File öffnen --> Referenz benutzen für ein Write to Text file ...

denn es hiess es gibt Probleme mit den Konversions:

(06.07.2012 07:40 )rolfk schrieb:  Jens hat das Problem der Zielenenden schon angesprochen mit dem Kopieren im Editor. Dasselbe tritt aber auch auf wenn Du Deinen Flattened Cluster mit der Write to Text File Funktion abspeicherst. Die heisst nicht nur per Zufall "Text", denn die macht default Zeilenende (EOL) Konversion. Alle <CR> <LF>, <CR> und <LF> alleine werden dabei mit der für die aktuelle Platform geltenden Zeilenendekombination geschrieben. Unter Windows ist das <CR> <LF>.Und Read from Text File macht das Umgekehrte, indem alle diese Zeilenenden in das LabVIEW Zeilenende <LF> umgesetzt wird. Darum sollte man für Binary Daten ja auch Write to Binary File UND Read from Binary File verwenden.

Bin mir nun nicht schlüssig wie es auf jeden Fall zuverlässig funktioniert.

Anzeige

Der Satz von mir ging ja auch noch weiter ;-):

Zitat:Ansonsten für deinen Zeck: File öffnen --> Referenz benutzen für ein Write to Text file um den Header zu schreiben (dann macht der dir auch auch automatisch deine Zeilenenden nach jedem Write rein --> per Write to Binary File die eigentlichen Daten in das File schreiben --> File Referenz schließen.

Du scheinst das etwas misszuverstehen: Du schreibst nicht eine Textdatei mit Write to Text file bzw. eine Binärdatei mit Write to Binary, sondern du schreibst unter bestimmten Konventionen in eine Datei.

Die Funktionen dienen nur dazu dir zum Beispiel nach einer Zeile ein Zeilenende (Write to Text file) zu schreiben bzw. dir die Längen deiner Strukturen (zum Beispiel Anzahl der Array Elemente) vorranzustellen (Write to Binary). Der qualitative Unterschied dabei ist, dass du Write to Text file in der Regel nutzt um eine Art Nutzerausgabe zu machen (menschenlesbare Tabelle) und während Write to Binary für die Datenspeicherung zur weiteren Verarbeitung durch ein Programm verwendet wird. Entsprechend stellen die dir halt unterschiedliche Funktionen zur Verfügung (zum Beispiel ein Automatisches Daten serialisieren wenn du bei Write to Binary einen beliebigen Datentyp einhängst).

Grundsätzlich machen die aber wie gesagt auf der untersten Ebene nichts unterschiedliches. Beide Schreiben letztlich Zeichen in eine Datei.

Fakt ist jedenfalls: Durch die Konversion der Zeilenende Zeichen bei Write to Text file (Read from Text file) geht dir Information verloren. Praktisch gesehen: Jedes Zeichen in der Datei besteht aus 8 Bit, entsprechend hast du 256 verschiedene Zeichen zur Auswahl. Ein I32 wird dann zum Beispiel aus 4 Byte - also 4 Zeichen in deiner Datei - dargestellt. Wenn du jetzt 3 dieser Zeichen konvertierst wird bei jedem auftauchen eines dieser Zeichen beim Ausspeichern der gespeicherte Wert verändert und du lädst am Ende was anderes als du gespeichert hast.

Kurzbeispiel:

nehmen wir mal an das Zeichen für 1 wäre Zeilenende und das Zeichen für 255 wäre Zeilenvorschub. Dann wird beim Speichern eventuell noch Zeilenende geschrieben, beim lesen jedoch wird dann schon Zeilenvorschub gelesen (durch die Konvertierung). Entsprechend speicherst du zwar 1 aus, liest aber 255. Das könnte man als bei Zahlen nicht weiter tragisch ansehen. Wenn du aber bedenkst, dass du zum Beispiel ein Array ausspeicherst das 1 Element hat. Dann speichert der Zeilenende als Anzahl der Array Elemente. Anschließend kommt das eine Element. Liest du das wieder ein, liest er plötzlich 255 Elemente (und versucht die dann aus der Datei zu lesen; der wandelt dann also Daten komplett falsch um etc.) - was natürlich schiefgeht, da du keine 255 Elemente gespeichert hast.

Hoffe das ist jetzt klarer.

...ja jetzt ist es doch deutlich klarer, vielen Dank allen Beteiligten.