LabVIEW
Type cast
Solved!
I have two (sort of) related question:
What is 'type cast' / when would I use it?
What does 'flattening' or 'unflattening' data mean?
I am not using these for any VI's I am writing right now, I have just seen the terms come up on the forums a lot, and was curious what they were. From what I have seen so far, I think type-cast is some type of data converting function, but I'm not sure.
If you want to answer these questions, its good practice if you become a CPI 
One thing to be careful of with Type Casting is that LabVIEW does not do ANY conversion of the data. This means that if you try to cast data from one type to another that has a different internal representation in memory, you will almost certainly not get the answer you though of. Here's an example were someone might think they can use a type cast to convert a I-32 with a value of 123 to a U-16. What happens here is that LabVIEW looks at the first 16 bits of the I-32 (which are all zeros) and then uses that in the U-16... hence instead getting 123 out, you end up with zero.
Shew,
If you embed an image in your message, you can't do it while you are in preview mode. You must first actually submit the message otherwise the URL to the attachment is to a temporary webserver location.
One the message is posted, the message gets its permanent ID and the attachment gets its permanent URL location. Then you can Edit the message and embed the image based on that location.
That is why your message now shows up with a Red X box where your image should be.
Here is your image.
On the most basic level, everything in computing is just a series of bits, what it actually means, depends on the context.
For example, if you have the number -123 in I32, the bits are: 11111111111111111111111110000101
OTOH, if you have the same number -123 in SGL, the bits are: 11000010111101100000000000000000
This means, if you only have the bit pattern on the right, you cannot know what the value is unless you also know the datatype. Many communication protocols only transmit generic binary strings (such as the 4 bytes of the bit pattern on the right), so typecasting to a string makes the data compatible with the function. To convert it back on the receiving end, you need to tell LabVIEW what the actual type was, so typecasting it back to I32 or SGL will do that for you.
If the type is incorrect, you most likely get garbage.
11111111111111111111111110000101 could be -123 (I32), 4294967173 (U32), or NaN (SGL)
11000010111101100000000000000000 could be -1024065536 (I32) 3270901760 (U32) or -123 (SGL)
In a simplistic way, you can say that data conversion (e.g. to_SGL, to_I32) tries to keep the value intact while changing the bit pattern, while typecasting tries to keep the bit pattern the same, thus typically changing the value in the new representation. (I said simplistic, because there are possible complication such as byte order).
Similarly, all this works for more complicated datatypes. If you have a string with 256 characters (2048 bits), it could be a plain, readable string, such as a poem, it could be an I8 array with 256 elements, a DBL array with 32 elements, a CDB (complex) array with 16 elements, an array of clusters with 64 elements, where each element is a cluster of two U8 and one I16, or whatever. Once you tell LabVIEW the type, it can be cast to the correct data type.
Typecasting has no error check, so you better know what you are doing and that the number of bytes match. If you try to cast a I16 to DBL, you probably don't get what you might expect.
Typecasting casts from any datatype to any other datatype and is thus most universal.
"Flatten to string" and "unflatten from string" are in many ways similar, except that one side is always a string and the primitives contain a lot more extra functionality. For example they have error handling, can change the byte order, and optionally deal with prepended size information.
See also:
Cory K wrote:Couldn't you use the "num > string" function for the same purpose?
The numeric to string functions take the binary value and translate it into text, consisting of readable characters. It uses only a small subset of the ASCII character set and is thus wasteful.
Going back to the -123 example above, it would create a string consisting of the minus sign "-" and the characters "1", "2", and "3". A readable string!
This is often a lossy function because for fractional values, it is often no possible to give an exact decimal representation of the underlying binary data. It is also expensive and wasteful. For example to ~accurately display a DBL value, you need to show 16 decimal digits. So with the decimal point, sign, exponent and delimiters, you might waste 20 bytes to approximately store or transmit a value that could be accurately stored or transmitted in exactly 8 bytes of a binary data string. Formatting from string and the reverse operation is computationally complicated and expensive. Reading binary data and typecasting is computationally trivial and thus much faster.
Formatting is most useful to present the data to the user in a readable form (the numeric FP indicators do the same). For internal and hidden operations, sticking to binary data is more efficient. 🙂
