What is the purpose/advantage of Type Cast

[Brzhou]

Hi Sir,

I have a question for the Type Cast, it will change the data type automatically, and make it be compatible ?

For below case, whether we can just use the funtion string to number instead of Type Cast ?

What is the difference ?

Thanks.

[santo_13]

It tells LabVIEW to interpret the underlying binary data as a different data type.

For example, a string is an array of characters, where each character is represented by a U8 integer.

[Brzhou]

But if we just use "Decimal String To Number" function, any risk or compatible issue ?

Thanks.

[rolfk]

---

@Brzhou wrote:

Hi Sir,

I have a question for the Type Cast, it will change the data type automatically, and make it be compatible ?

For below case, whether we can just use the funtion string to number instead of Type Cast ?

---

No you can't!!! They are completely different operations!

String to Number looks at the string and parses a decimal number in string form into a real number.

Typecast simply uses the 4 bytes in the string and interprets them directly as a 32-bit integer (and specifically formatted in big endian order).

Just connect that string you get from the first TCP Read to a string control and look at it. You will see gibberish. That is because the bytes in that string do usually not form valid ASCII codes.

[raphschru]

Try for yourself and you will see the difference:

Here for example the Type Cast flattens the values to 24 bytes because I have 3 values, and each value is an 8-byte floating point number (double). Type Cast is often used for flattening/unflattening communication frames because this is compact and efficient.

On the other hand, the Number to String function turns the numbers into human-readable ASCII representations. This is often used for displaying values in user interfaces or producing human-readable configuration files.

Regards,

Raphaël.

[Brzhou]

Yes, Just now, I give a try, not sure why the "Type Cast" transfer string "5" to 889192448, thanks.

[raphschru · Accepted solution]

Because Type Cast reinterprets the raw bytes.

If you change the Display Style of the string constant to "Hex Display" and the radix of the numeric indicator to "Hex", you will see this:

Your string "5" is actually stored in memory as a byte of value 0x35 (here expressed in hexadecimal). Why 0x35 ? Because this is the value associated to the character "5" in the ASCII table.

So the value 0x35 is directly copied to the raw representation of the I32. Since an I32 has 4 bytes, LabVIEW completes with 3 zeros to make the final value: 0x35, 0x00, 0x00, 0x00.

[Brzhou]

Thanks.

I see, sounds like the same as yours now.

So in this way, the Type Cast convert the string to ASCll char by char, and fill the bit on the right side with "0" to match the length, at most 4 bytes,  thanks.

[raphschru]

Type Cast takes the raw bytes in memory of your input and reinterprets them in the target type, but has nothing to do with ASCII.

The ASCII table is only used when displaying a string to the user, as in a string constant or string control/indicator.

[GerdW]

Hi Brzhou,

---

@Brzhou wrote:

So in this way, the Type Cast convert the string to ASCll char by char, and fill the bit on the right side with "0" to match the length, at most 4 bytes,  thanks.

---

A TypeCast does NOT change the underlying data/bytes (the memory content), but just interprets those data/bytes differently: the 4 bytes of a SGL value can also be interpreted as the 4 bytes of an U32 or I32 value, but all three represent different values.

Any other conversion function (like ScanFromString, Convert FromFractionalString, or ToI32) will re-interprete the value of that item and will change the underlying data in memory. A SGL value of "1.0" consists of the 4 bytes 0x3F 0x80 0x00 0x00, while the I32 value of "1" consists of 0x00 0x00 0x00 0x01.