LabVIEWForum.de

Weiß jemand genau wie diese Funktion "Typenformung" arbeitet und wozu diese eigentlich da ist? Muss doch nen bestimmten Grund haben?
Z.b. ist es einleuchtend das wenn vor der Funktion ein U8-Integer angeschlossen wir und den Eingang "Typ" offen lässt, man die Zahl in ASCII-Code in einem String zurückbekommt. Ist ja auch klar, denn ein String ist ja nichts anderes als ein Array von Zahlen welche dann in ASCII umgesetzt werden. So ist doch z.b. ein string welcher folgerdermaßen aussieht
|abcde| nichts anderes als ein Array von Zahlen |97|98|99|100|101| in ASCII-Darstellung. Und deshalb erhält man den ASCII Code in einem String wenn man vor der Funktion ein Array of U8-Integer anschließt. ABER wenn man nun ein DBL-Array anschließt so bekommt man nur wirres Zeug raus.
Hat nicht jemand dafür ein sinnvolles Beispiel wofür diese Funktion gut ist?

' schrieb:Weiß jemand genau wie diese Funktion "Typenformung" arbeitet und wozu diese eigentlich da ist? Muss doch nen bestimmten Grund haben?
Z.b. ist es einleuchtend das wenn vor der Funktion ein U8-Integer angeschlossen wir und den Eingang "Typ" offen lässt, man die Zahl in ASCII-Code in einem String zurückbekommt. Ist ja auch klar, denn ein String ist ja nichts anderes als ein Array von Zahlen welche dann in ASCII umgesetzt werden. So ist doch z.b. ein string welcher folgerdermaßen aussieht
|abcde| nichts anderes als ein Array von Zahlen |97|98|99|100|101| in ASCII-Darstellung. Und deshalb erhält man den ASCII Code in einem String wenn man vor der Funktion ein Array of U8-Integer anschließt. ABER wenn man nun ein DBL-Array anschließt so bekommt man nur wirres Zeug raus.
Hat nicht jemand dafür ein sinnvolles Beispiel wofür diese Funktion gut ist?

Also ich benutze dieses VI sehr sehr oft, da ich viel mit binären Übertragungsprotokollen (z.B. Kommunikation mit Geräten über serielle Schnittstelle) arbeite.
Desweteren kann man jede Menge Platz auf der Festplatte sparen, wenn man z.B. Double-Array binär statt ASCII in eine Datei abspeichert, das hat sogar den Vorteil, dass man keine Punkt/Komma Probleme und keine Nachkommastellenprobleme hat.

eg

' schrieb:ABER wenn man nun ein DBL-Array anschließt so bekommt man nur wirres Zeug raus.

Die Funktion macht nichts weiter als quasi ein Datenstream zu erzeugen. Einen Stream kann man wunderbar mit Strings handeln, da diese eine Länge haben, die eben die Länge der Daten angibt - unabhängig vom Typ der Daten und deren Wert. Steams sind aber nicht zum lesen da, sondern (siehe eq) z.B. zum Speichern.

Hier ein Beispiel, das ein 100000 Dbls großes Array binär und als ASCII-Tabelle abspeichert.

1. die binäre Datei ist etwa 1/2 der Tabellendatei
2. wenn man die Auflösung der Tabellendatei ändert, ändert sich auch die Größe, bei binären Datei hat man immer die volle Dbl-Auflösung.

eg

(VI LV 8.0)

' schrieb:Weiß jemand genau wie diese Funktion "Typenformung" arbeitet und wozu diese eigentlich da ist? Muss doch nen bestimmten Grund haben?
Z.b. ist es einleuchtend das wenn vor der Funktion ein U8-Integer angeschlossen wir und den Eingang "Typ" offen lässt, man die Zahl in ASCII-Code in einem String zurückbekommt. Ist ja auch klar, denn ein String ist ja nichts anderes als ein Array von Zahlen welche dann in ASCII umgesetzt werden. So ist doch z.b. ein string welcher folgerdermaßen aussieht
|abcde| nichts anderes als ein Array von Zahlen |97|98|99|100|101| in ASCII-Darstellung. Und deshalb erhält man den ASCII Code in einem String wenn man vor der Funktion ein Array of U8-Integer anschließt. ABER wenn man nun ein DBL-Array anschließt so bekommt man nur wirres Zeug raus.
Hat nicht jemand dafür ein sinnvolles Beispiel wofür diese Funktion gut ist?

Ich würde es so erklären:
Ein "Typ" (Also z.B ein Integer I16) besteht immer aus 2 Abschnitten: "Typbeschreibung" und "Daten". Die "Daten" sind letztlich immmer eine zusammenhängende Folge von Bytes. Mit der "Typenformung" ist es möglich, den Daten eines gegebenen Typs eine andere Typbeschreibung unterzuschieben, ohne die Daten selbst zu verändern.
Beispiel: Gegeben: Array of Bytes U8. Länge 12. Typgewandelt nach Array of U32 ergibt sich ein Array of U32 der Länge 3.
Da die Daten überhaupt nicht angerührt werden, ist die Typformung eine sehr schnelle Methode, schneller als die "offiziellen" Werkzeuge, die man in jedem Falle auch benutzen könnte. Die Typenwandlung sollten nur genügend erfahrene Anwender mit der gebotenen Vorsicht benutzen, da es leicht zu unerwarteten Ergebnissen kommen kann.
Wir beispielsweise ein einzelnes Byte U8 in eine Gleitkommenzahl gewandelt, dann ist das Nonsens, da die erforderlichen Anzahl von Bytes, aus denen sich die Zahl zusammensetzt, gar nicht vorhanden ist

Das Beispiel von Eugen ist schon so etwas wie die höhere Schule und bedarf vielleicht noch einer Erklärung.
Aufgabe: Es soll ein Array von 1000 Gleitkommazahlen (double) in eine Datei im Textformat abgespeichert werden.
Offizielle Methode:
Dei Zahlen werden einzeln mit der Funktion "Zahl nach String" konvertiert und dann als einspaltige Tabelle im Textformat gespeichert.
Methode Eugen:
Der ganze Array wird typgewandelt in String. Es entsteht ein Textsalat mit allen vorkommenden ASCII-Zeichen von 0..255, den zwar kein Mensch mehr interpretieren kann, den man aber im Format Text abspeichern kann. Das Einzige, worauf es letztlich hier ankam, war nicht die Lesbarkeit des Textes für einen menschlichen Betrachter, sondern daß man den Text, wenn er wieder eingelesen wird, wieder in das ursprüngliche Zahlenarray konvertieren kann. Und das geschieht wieder mit der Funktion "Typformung", nur in umgekehrter Richtung, also von Text nach Array of Double.
(Kritisch würde ich hier allerdings anmerken: Wenn es nicht darauf ankommt, das was abgespeichert wird lesen und editieren zu können, warum wird dann nicht einfach im Binärformat abgespeichert?)

Und hier noch das gewünschte "sinnvolle" Beispiel. Aber wie gesagt, die Typformung ist immer irgendwie ersetzbar, so auch hier. Hier geht es um die Konvertierung von 4 bytes nach 2* Integer U16
[attachment=9445]

(VI LV 8.2)