LabVIEW Real-Time Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Manzolli

Fixed-Point With Variable Memory Allocation

Status: New

Every Fixed-Point number allocates 64 bits (8 bytes) or 72 bits (9 bytes) if you include an overflow status. Working on a cRIO project that I need to acquire and save a large amount of data to process later when the RT CPU has free time to do it (is not acquiring more data nor transmitting data). Since the data is acquired in 12 channels, 51.2 kS/s, with 24 bit each point, the fixed-point allocates 64 bits but uses only 24, wasting 5 bytes (62,5%) for every single data point acquired.

 

As a workaround, I developed two VIs one to compact the data removing the 5 unused bytes of every Fixed-Point, number keeping the 3 bytes with the data. The second VI does the reverse job. With this I reduced the information to 37,5% of the original, saving space and time to save the information in non volatile memory. Maybe there's a way to do it directly, but I didn't figure it out.

 

My idea is to add, in some way, the possibility to use the minimum amount of bytes needed by the data, at least for storage purposes. It would be nice if NI add an option to have fixed point in two memory allocation modes:

 

  • Standard: the current way with 64 or 72 bits (probably faster)
  • Packed: the number of bytes allocated will be the minimum to hold all information. For a 16 bits data the each data will use only 2 bytes.
André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
3 Comments
AndreOliveira
Member
It is a good suggestion, it sounds like there should be a way for the  user to define how many bytes to have in the fixed-point data type, specially for embedded applications where the amount of data can sometimes be a limiting factor.
muks
Proven Zealot
I will say a nice suggestion and kudos!!!
QFang
Active Participant

You already can configure fixed point data sizes in LV.. I never realized that this configuration had no impact on the total memory overhead for the fixed point variable that I manually configured.. I need to try this out with TDMS to see if the same is true there. I've been playing with casting my data to a fixed point variable defined by me to be pretty narrow to save space in the tdms files, but this may not work then.. humm.

QFang
-------------
CLD LabVIEW 7.1 to 2016