LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Miraz_Automation

Inbuilt functions for converting fraction to byte array

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.

Hi,

 

Today in order to convert the fraction number (Double/Single)to byte array we have to apply following logic, would like to have inbuilt function in numeric pallet for conversion.

 

Fraction to byte array.png

With Regards

Miraz
Kudos is better option to thank somebody on this forum
------------------------------------------------------------------------------
7 Comments
altenbach
Knight of NI

I am happy with the functionality of the typecast function and don't think we need to increase pallete bloat and add a special function for such a rare case. In the typical case, the DBL is cast to a string, in which case we don't need to wire the type.

If you need that special case, you can always make an inlined subVI with a tiny icon and add it to your user palette.

AristosQueue (NI)
NI Employee (retired)

This is so rare a need and the operation is exactly "type cast" so I agree with Altenbach. We'll leave the idea open and see if it gathers more kudos.

crossrulz
Knight of NI

My question would be "What are you doing with the byte array?" Almost always when I run into a situation remotely like this, I use the Flatten To String and then send the string to whereever it is needed.  If necessary, also use the String To Byte Array. I prefer using the Flatten To String because you can specify the endianness.  Type Cast is strictly Big Endian.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
AristosQueue (NI)
NI Employee (retired)

> Type Cast is strictly Big Endian.

 

Unless I've misunderstood something, Type Cast should be "the same endian-ness as the platform".

Darin.K
Trusted Enthusiast

Type Cast should be "the same endian-ness as the platform"

 

Can you imagine the havoc that would ensue if that were actually the case?  I can and I'll I can say is ouch....

 

In the old Mac/Linux world this was the case, a result of the Mac origins of LV.  In the Windows world Type Cast has to create a temporary buffer and flop the endianness of mulitbyte data types.  Most people imagine that TC is just fiddling a few bytes in a type descriptor when it is actually crunching through the data (at least on Windows and most Intel Macs these days that I have used).

AristosQueue (NI)
NI Employee (retired)

Interesting... I did some digging on the primitive. For this particular cast, Darin is right -- the prim does not just reinterpret the bytes.

 

... and that explains a bug that I never solved in one of my programs at home. I never even looked at the Type Cast as possibly the issue, but if it is fixing up Endian-ness... hm.

 

Thanks, Darin.

Darren
Proven Zealot
Status changed to: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.