I have a spec that defines message data as an array of bytes, and each byte has specific bits that represent different things. So, I just build up an array of booleans representing the message bits, then type cast to a u8 array with convert 4.x selected. But, the type cast function documentation states "National Instruments recommends reworking any application that uses the Convert 4.x Data mode as a long term solution." Is there a performance reason for this? I can think of other methods to eliminate the 4.x cast, but if I go another route I'd like to be able to justify the reason. Thanks.
已解决! 转到解答。
I'm guessing it's not about performance, but rather about compatibility. Relying on something that was replaced almost 13 years ago does not seem too wise. I would suggest the Boolean Array to Number primitive.
@tst wrote:
I'm guessing it's not about performance, but rather about compatibility. Relying on something that was replaced almost 13 years ago does not seem too wise. I would suggest the Boolean Array to Number primitive.
That's fine, is the best way then to build multiple, 8-boolean arrays, convert each one to u8 numbers then build the u8 array out of those?
Something like this is likely what you are trying to do.

yesuh, it is.
I am trying to console Type Cast man at the moment as he sees the length you go to avoid him.
If more people use 4.x mode then it will not go away anytime soon. It is built for this exact purpose, converting human readable (MSB first) boolean arrays to byte arrays. And if it does go away, then no doubt a replacement primitive for this operation will be provided. Many VIs in vi.lib use it.
Assuming your array is fixed size, then why not simply set the output representation of the BA to Number primitive to the suitable size (U8-U64) and simply type cast the result to a byte array (no need for 4.x mode). If you have an odd number of bytes simply delete the final element. If you have a user punching in more than 64 bits using a boolean array, I think the 65th thing being punched is your face.
@Darin.K wrote:
If you have a user punching in more than 64 bits using a boolean array, I think the 65th thing being punched is your face.
This is what I'm worried about. I'd like things to be consistent across all functions that will be building message data. And I may get a definition for a message with more than 8 bytes of data. This is not data a user is entering, it's data being sent across the network. Doubles are being converted to a specified fixed-point number with x number of fractional bits and y number of word bits. It's good to know 4.x does msb first. I was just trying to type cast a bit array to a u8 array, but because booleans are stored as bytes and not bits, it wasn't working properly. I noticed casting using 4.x treated the boolean array as bits. It sounds like I may need to be sure to properly reverse my array.
Kudos, also Darin. I didn't know you could configure the boolean array to number output!
@for(imstuck) wrote:
Kudos, also Darin. I didn't know you could configure the boolean array to number output!
You didn't noticed I did that in my snippet (configured to output a U8)?
@crossrulz wrote:
@for(imstuck) wrote:
Kudos, also Darin. I didn't know you could configure the boolean array to number output!
You didn't noticed I did that in my snippet (configured to output a U8)?
I glanced at your snippet, but didn't study in detail or drag it to my bd because it was easy enough to understand visually. I would have run into it once I implement it in code