Fitting Square Pegs into Round Holes: Advanced Conversions and Typecasting

Remember polymorphism, discussed earlier in this book? It's one of LabVIEW's best features, allowing you to mix data types in most functions without even thinking about it. (Any compiler for a traditional programming language would scream at you if you tried something like adding a constant directly to an arraybut not LabVIEW.) LabVIEW normally takes care of doing conversions internally when it encounters an input of a different but compatible data type at a function.

If you're going to develop an application that incorporates instrument control, interapplication communication, or networking, chances are you'll be using mostly string data. Often you'll need to convert your numeric data, such as an array of floating-point numbers, to a string. We talked about this a little in Chapter 9. It's important to distinguish now between two kinds of data strings: ASCII strings (the sequences people readily understand, such as the characters on this page) and binary strings (the sequences of bytes [each containing 8 bits] in a computer's memory or disk).

ASCII strings use a separate character (a whole byte) to represent each digit in a number. Thus, the number 145, converted to an ASCII string, consists of the characters "1," "4," and "5."^[1] For multiple numbers (as in arrays), a delimiter such as the <space> character is also used. This kind of string representation for numbers is very common in GPIB instrument control, for example (see Figure 14.49).

^[1] Unicode, the increasingly popular alternative to ASCII, uses 4 bytes (32 bits) to represent characters, allowing a much broader range of international characters and symbols. At the time of press, LabVIEW did not have support for Unicode.

Figure 14.49. ASCII representation of 145

Binary strings are a bit more subtlefor one thing, you can't tell what data they represent just by reading them as ASCII characters. The actual bit pattern (binary representation) of a number is used to represent it. Thus, the number 145 in I8 representation is just a single byte in a binary string (which, incidentally, corresponds on my computer's ASCII set to the "ë" characternot that most humans could tell that means 145). Binary strings are common in applications where a minimal overhead is desired, because generally it is much faster to convert data to binary strings and they take up less memory (see Figure 14.50).

Figure 14.50. Binary representation of 145

Ultimately, all data in computers is stored as binary numbers. So how does LabVIEW know if the data is a string, Boolean, double-precision floating-point number, or an array of integers? All data in LabVIEW has two components: the data itself, and the data's type descriptor. The data type descriptor is an array of I16 integers that constitute code that identifies the representation of the data (integer, string, double-precision, Boolean, etc.). This type descriptor contains information about the length (in bytes) of the data, plus additional information about the type and structure of the data. For a list of data type codes, read the Fundamentals>>How LabVIEW Stores Data in Memory section of the LabVIEW Help. In a typical conversion function, such as changing a number to a decimal string, the type descriptor is changed and the data is modified in some way. The common conversion functions you use most of the time convert numbers to ASCII strings, such as in this example (see Figure 14.51).

Figure 14.51. Converting a number to an ASCII string

The topics in the rest of this section can be very confusing to beginners. If you do not have any need to use binary string conversions in your application, you can safely skip the rest of this section.

In some cases, you may want to convert data to a binary string. Binary strings take up less memory, are sometimes faster to work with, and may be required by your system (such as a TCP/IP command, or an instrument command). LabVIEW provides a way to convert data to binary strings using the Flatten To String function. You can access this function from the Programming>>Numeric>>Data Manipulation palette.

The anything input to Flatten To String can be literally any LabVIEW data type, including complex types such as clusters (see Figure 14.52). The function returns a single output: the binary data string representing the data. You can also choose the byte order (big endian or little endian) and whether to prepend array or string size.

Figure 14.52. Flatten To String

When you flatten a string or array, the default behavior of Flatten To String is to prepend the string or array size to the front of the data string (see Figure 14.53). If you do not want the size information, then set the prepend array or string size? input to FALSE.

Figure 14.53. Using the prepend array or string size argument when calling Flatten To String

The key to understanding these confusing binary flattened strings is to realize that most of the time you don't need to manipulate or view the strings directlythey are not intended to be human readable. They are just a convenient, compact, and generic format for passing data to a file, a computer over a network, an instrument, and so on. Later, to read the data, you just need to unflatten the string back into the appropriate LabVIEW data type.

To read back binary strings, use the inverse function, Unflatten From String (see Figure 14.54). The type input is a dummy input for specifying (by wiring to it) the data type that the binary string represents. The value output will contain the data in the binary string, but will be of the same data type as type. An error will be generated (passed out of error out) if the conversion is unsuccessful. Just like the Flatten To String function, you can specify the byte order (big endian or little endian) of the binary string.

Figure 14.54. Unflatten From String

The byte order and prepend settings passed to Unflatten From String must match those passed to Flatten To String when the data was originally flattened. Otherwise, the data will not be unflattened properly.

Here's the example of how to convert back your flattened binary string to a DBL array.

You wire the binary string input, as well as a dummy (empty or not) 1-D array of DBL to specify the data type, and you get back your original array of DBL. Notice how you flattened and unflattened without ever needing to "peek" or "manipulate" the binary strings directly.

For very fast, efficient conversions, let's take a final look at another, very powerful LabVIEW function: Type Cast (see Figure 14.56).

Figure 14.55. Calling Unflatten From String to convert an array stored as a flattened string back into an array

Figure 14.56. Type Cast

This function allows you to change the data type descriptor, without changing the data at all. There is no conversion of the data itself in any way, just of its type descriptor. You can take almost any type of data (strings, Booleans, numbers, clusters, and arrays), and call it anything else. One advantage of using this function is that it saves memory because it doesn't create another copy of the data in memory, like the other conversion functions do. Figure 14.57 shows an illustration of how the Type Cast operation changes the wire's type but leaves the data unchanged.

Figure 14.57. The Type Cast function only changes the wire type, not the data flowing through the wire

A common use of type casting is shown in Figure 14.58, where some instrument returns a series of readings as a binary string, and they need to be manipulated as an array of numbers. We are assuming that we know ahead of time the binary string is representing an array of I16 integers.

Figure 14.58. Type casting a binary string to an array of I16 integers

Type casting from scalars or arrays of scalars to a string works like the Flatten To String function, but it has the distinct feature that it doesn't add or remove any header information, unlike the binary strings created by the Flatten and Unflatten functions. The type input on the Type Cast function is strictly a "dummy" variable used to define the typeany actual data in this variable is ignored.

You need to be very careful with this function, however, because you have to understand exactly how the data is represented so your type casting yields a meaningful result. As mentioned previously, binary strings often contain header information (such as the output from the Flatten To String function). Type Cast does not add or remove any header information in binary strings. If you don't remove headers yourself, they will be interpreted as data and you'll get garbage as a result.

Make sure you understand how data to be type cast is represented. Type casting does not do any kind of conversion or error-checking on the data. Byte ordering (MSB first or last) is platform-dependent, so understand what order your data is in.

You might try experimenting with the Type Cast function to see what kind of results you get. Take a look at Type Casting.vi, found in the EVERYONE\CH14 folder on the CD-ROM. To show you how bizarre you can get with type casting, we took a cluster containing numeric controls (type I16) and cast the data to a string, a numerical array, and a Boolean (see Figure 14.59).

Figure 14.59. Type Casting.vi block diagram showing the Type Cast function converting a cluster to many different data types

The front panel (see Figure 14.60) shows you what results we obtained with two numbers.

Figure 14.60. Type Casting.vi front panel showing the results of type casting a cluster to many different data types

The string returned two characters corresponding to the ASCII values of 104 and 71. The array simply re-organized the numbers into array elements instead of cluster elements. And the Boolean? How would a Boolean variable interpret cluster data? Because we didn't know, we tried this, and found out the Boolean is TRUE if the first byte of the raw data is 255; otherwise, it's FALSE. So in this case, if the first element of the cluster has a value greater than 255, the Boolean is TRUE; otherwise, it's FALSE. Pretty strange, eh?