12-04-2012 01:53 PM - edited 12-04-2012 01:54 PM
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.
Solved! Go to Solution.
12-04-2012 02:01 PM
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.
12-04-2012 02:06 PM
@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?
12-04-2012 02:12 PM - edited 12-04-2012 02:13 PM
Something like this is likely what you are trying to do.
12-04-2012 02:17 PM
yesuh, it is.
12-04-2012 03:22 PM
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.
12-04-2012 03:44 PM
@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.
12-04-2012 04:48 PM
Kudos, also Darin. I didn't know you could configure the boolean array to number output!
12-05-2012 06:53 AM
@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)?
12-05-2012 09:54 AM - edited 12-05-2012 09:54 AM
@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