LabVIEW
Cluster of fixed-point values typecast to string byte ordering
I have a cluster of 32-bit fixed-point values (FXP18.14) that I am converting to a byte array via typecast to string then string to byte array. LabVIEW uses 64-bits to store FXP values, so in this case half the bits are unused. When converting from a cluster like this, the ordering of the bytes for each FXP value gets swapped - the first 4 bytes are the unused values while the final 4 bytes are the actual FXP value. However, if I do this typecast on a single FXP value (not in a cluster) the byte ordering is as expected where the first 4 bytes holds the actual FXP value.
See attached test VI demonstrating this behavior, as well as screenshots below. I'm using LabVIEW 2019 SP1.
Is this a bug, or expected behavior? Does anyone know why the byte ordering is different when typecasting clusters vs single values? This only occurs with the FXP datatype as far as I can tell.
Your fixed point numbers are not what you think they are:
Not sure why LabVIEW is typecasting to 64 bits; tried with other FXP configurations.
@cjs7 wrote:Not sure what you mean by "your fixed-point numbers are not what you think they are"?
This may be because of your non-standard notation for fixed-points. Usually when we say "FXP 18,14" it means 18 bits in total of which 14 are in the integer part. So the sentence "I have a cluster of 32-bit fixed-point values (FXP18.14)" is a bit confusing. Actually your alternate notation could be more practical arithmetically if we are worried about precision, but less if we are thinking in terms of size taken by the data.
Anyway, I don't know why exactly the "Type Cast" function is behaving like this with FXP, but you can use "Flatten to String" and "Unflatten from String" instead. This way, the additional zeros are always put before the actual data:
