Flatten to String vi adds extra bytes to fixed point numbers

[Syr]

I wrote a simple test vi that uses the Flatten to String vi to send a cluster of numbers that includes fixed point numbers. The function seems to work fine for integer types but adds four extra bytes for each fixed point number (0x0000 0000). Note the extra two sets of four bytes in the 'Data string to send' box. Is this intentional by Labview or a bug? I want to send a flattened string in little endian order to an STM32 microcontroller without additional bytes. Is this possible to do cleanly any other way if the Flatten to String does not operate as I need?

My real application has a rather complex type def cluster of various data types. The intent is to fill out all the fields in the cluster, flatten to a string in little endian format, and send them to the microcontroller. I would also use the same type def cluster to read the data back using the Unflatten from String function. This would result in clean and easy to modify and maintain code. The workaround is to convert all the fixed point numbers to U32 and is messy and difficult to maintain.

Any suggestions and comments are welcome.

Thanks

[GerdW]

Hi Syr,

when you would read the LabVIEW help you would know that FXP datatypes occupy 64bits (or even 72bits) in memory…

[Syr]

Everything in the help section that i came across says that it supports 'up to a maximum of 64 bits'. Could you point me specifically to where it says that it is 'stored' as 64 bits.

Assuming it is stored as 64 bits then is there another way to cleanly send my 32 bit fixed point numbers as 32 bits?

[RavensFan]

The column in the link Gerd posted says "Bits of Storage on Disk".

[Syr]

OK, sometimes the obvious details escape me... 

I think the best way to handle it is to cast all the fixed point numbers to U32's before sending it to the Flatten to String vi. In any case, I think I have it down now.

Thanks for the help. 

[crossrulz]

---

@Syr wrote:

OK, sometimes the obvious details escape me... 

I think the best way to handle it is to cast all the fixed point numbers to U32's before sending it to the Flatten to String vi. In any case, I think I have it down now.

Thanks for the help. 

---

Be careful with just Type Casting to U32.  You don't know which part of the number you will get (upper 32 bits with all 0 or the lower 32 bits with the actual data) unless you know then endianess.  I would recommend flattening to the string and then using String Subset to parse down your data to the 32 bits.  When you unflatten, just add the extra 0s using Concatinate String.