Convert IEEE-754 32-bit Hexadecimal to decimal floating-point

Would this be very difficult?? I'm trying to find info, but maybe I need some help, anyone? Thank you for your answers... =D

Hi! Thank you for answering me. You're right, It has been asked before, and typecast is perfect... But I have another problem..
I found in other thread a VI (attached) that works just fine, but I can't put an input to it, it just works when you type the hex number in the front panel.
Why? I'm trying to create a subVI with this, but it doesn't work like that and I want to know what I'm doing wrong.. =( Thank you!
Attachments:
TypeCast_SGL[1].vi ‏17 KB

Similar Messages

Convertion Hex String to 32bits Decimal floating point??

Hi,
I would like to know how to convert hexa like: 416b0ac3 in decimal 32bits floating-point. The result of this string is suppose to be 14.690127.
So i must be able to do:
From 32-bit Hexadecimal Representation To Decimal Floating-Point
Thanks for your support
RiderMerlin

RiderMerlin
You can use the typecast function to do this.
David
Message Edited by David Crawford on 09-06-2006 03:31 PM
Attachments:
Typecast to Single.jpg ‏6 KB

How to read register storaged in IEEE 754

Hi!
I need to build an application to read registers from my gauge. Application is almost finished but values i get on from holding register are different than values on my gauge (ex. i have voltage 230V on gauge, and values about 20k in application). Gauge stores values in IEEE 754 32-bit format and I have no idea how to read it to get correct value. I saw it's possible with using "Type cast", but i don't know how to configure it, I am totally newbie in LabVIEW. I will be much grateful if someone could show me a VI with reading from IEEE 754 option, or just tell me how to do it in detail (what to click, what to write, etc )
Sorry for my english, I hope I didn't make many mistakes
Greets
Solved!
Go to Solution.

Notice your red dots, they indicate a data type mismatch. Remove the byte array to string, because it truncates your U16 array elements to U8. Typecast and unflatten accepts U16 arrays directly. (corrected, see answer below)
Also change your "holding registers" to a diagram constant (righ-click terminal...change to constant). Only the type matters, the data is irrelevant here. (Shouldn't it be a scalar SGL instead?)
Sorry, I don't have the toolkit so I am missing your subVI.
LabVIEW Champion . Do more with less code and in less time .

Conversion of a float to IEEE 754 hexa (and vice versa)

Hello everyone,
I need to convert a float into an hexadecimal value to transmit it on a communication bus (I also have to decode the hexa into a float). I need this hexadecimal to respect the IEEE 754 technical standart. I'm trying to do it with the basic functions of Labview but I'm facing some problems. You'll find attached my VI.
If someone has already done such a function or know an easier way to do it, I'll be very grateful.
Attachments:
IEEE 754 conv.png ‏38 KB

If your communication bus in only using singles, then avoid doubles in your code.
How are you converting to a Single from the Doubles? In my quick experiment, I got the right answer.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Attachments:
double to single hex.png ‏8 KB

Convert Floating Point Decimal to Hex

In my application I make some calculations using floating point format DBL,and need to write these values to a file in IEEE 754 Floating Point Hex format. Is there any way to do this using LabVIEW?

Mike,
Good news. LabVIEW has a function that does exactly what you want. It is well hidden though...
In the Advanced/Data manipulation palette there is a function called Flatten to String. If you feed this funtion with your DBL precision digital value you get the IEEE-754 hexadecimal floating point representation (64 bit) at the data string terminal (as a text string).
I attached a simple example that shows how it works.
Hope this helps. /Mikael Garcia
Attachments:
ieee754converter.vi ‏10 KB

Conversion of serial output (IEEE 754) to single

Hi,
I'm trying to read out the actual values of a MKS PR4000B pressure sensor. I managed to get a connection and read/write data to the device (using serial read/write), but I'm having trouble to convert the read output to a single.
The manual tells me the floating number is conform to IEEE 754, the response I get are 8 bytes: @head, actual value.byte3, actual value.byte2, 0x00, @head, actual value.byte1, actual value.byte0, 0x00
I would like to do a cast type to convert it (like in: http://forums.ni.com/ni/board/message?board.id=170&thread.id=195115&view=by_date_ascending&page=1), but never seem to get the right results.
HO\@ps@ should translate to something like 01.903
any ideas?

Here is a VI that converts your string into a Single .
Message Edited by VADave on 03-05-2009 11:50 AM
Visualize the Solution
CLA
LabVIEW, LabVIEW FPGA
Attachments:
Convert.JPG ‏35 KB
Convert Serial.vi ‏11 KB

Convert the money datatype to a 2 decimal point format.

Whats the best way to convert the money datatype to a 2 decimal point format in ms sql 2005 for use in my applications.
this?
CAST(tr.depositReceivedAmount AS decimal(10 , 2))

I respectfully disagree with the notion that you should change the SQL column from a 'money' data-type to something else.
In most database servers, 'money' is a data type that is designed to provide very consistent behavior with regard to arithmetic accuracy. In Microsoft Access, the representation is a scaled-integer. In MS SQL Server, it is obviously similar. Ditto Oracle and all the others.
You want the money data-type in the database to have this accuracy, because "hell hath no fury like an accountant in search of one lousy penny." The database column storage-formats are designed to satisfy accountants, and that is a Good Thing.
Meanwhile, you also want to take care as to exactly how you deal with the values. There are several points where rounding could take place. You do not have at your disposal the strongest possible handling of floating data-types in ColdFusion. You are also somewhat at the mercy of whatever interface software may lie between you and whatever SQL server you may use. "It's okay to round values once, but not multiple times."
I suggest rounding the value right before display, and stipulating that the user's input must be two decimal places.
Then, you might have to do some things at the SQL server's end. For instance, when you update a value in the table, you may need to use server-side logic to explicitly truncate the value to two decimal-points, so that an update of "$34.56" explicitly updates the column to "$34.5600." (This sort of thing has to happen within the SQL server context.) You know that the user's input has exactly two significant digits, but maybe (maybe not...!) the SQL server might not know this. You want to ensure that the server's internally-stored value represents exactly two significant digits, when the value originates from a user-input.
Don't err on the side of "your convenience" or "what looks good on-screen." (If you do, get ready to get phone-calls from the accountants, always at inopportune hours of the night.)

IEEE-754-Standard floating point confusion

Hi there,
I am really confused. The datatype double should be in C++ and Java the same standard acc. to IEEE-754.
But when I try to investigate the several bytearrays created from a double value e.g. 1.1d, it is different in C and Java.
below are the results:
Value 1.1 in C++
intCsigned
     bit0     bit1     bit2     bit3     bit4     bit5     bit6     bit7
byte0     1     1     0     0     1     1     0     1     -51
byte1     1     1     0     0     1     1     1     0     -52
byte2     1     0     0     0     1     1     0     0     -116
byte3     0     0     1     1     1     1     1     1     63
byte4     1     1     0     0     1     1     0     0     -52
byte5     1     1     0     0     1     1     0     0     -52
byte6     1     1     0     0     1     1     0     0     -52
byte7     1     1     0     0     1     1     0     0     -52
Value 1.1 in Java
intJava(signed)
byte0     0     0     1     1     1     1     1     1     63
byte1     1     1     1     1     0     0     0     1     -15
byte2     1     0     0     1     1     0     0     1     -103
byte3     1     0     0     1     1     0     0     1     -103
byte4     1     0     0     1     1     0     0     1     -103
byte5     1     0     0     1     1     0     0     1     -103
byte6     1     0     0     1     1     0     0     1     -103
byte7     1     0     0     1     1     0     1     0     -102
Can please somebody bring light into that?????
Does somebody know the exact specification of a double datatype in c++ and java?
with the best regards,
stonee

OK,
It seems my C-program created a bad array. I finally
found out, that the Java and C Array of each double is
exactly turned.
C[0] == J[7]
C[1] == J[6]
C[2] == J[5]
its probably big endian vs little endian issues plus on top of that nibble swapping.
I happen to be working on this very problem at this instant. I'll see what I can dig up.

I want to convert pictures to 1 bit image

dir sir;
i want to make a programe by it i want to upload image real image and then it converted it for 1 bit image ;
can i use java to do that?
and if soo what method and package and function helps me to do that .
if you can provide me with simple code i will be thankfull.
beast regards.

Hi,
if you have vision, you could use the functin IMAQ Image to Array to have a 2D array of the pixel values.
You can then compare pixel by pixel; if your images come from a camera, I would recommend to set a treshold of acceptance.
This is a time consuming solution anyway.
Alternative methods:
1) Make a subtraction of the two images, the resulting image will be the difference of them
2 ) Use IMAQ LogDiff function (operators palette)
3) Calculate the histogram of both image and compare the histogram reports
Good luck,
Alberto

Converting BACK to 64 bit in CS5

I know I went to a folder whose name I cannot remember in finder and selected "get info" and then somehow converted to 32 bit but now I wish to convert back to 64 bit,
Can anyone help me with this?

OK I just found the right info box. I unchecked open in 32 bit. Thank you both very much.

Batch utility to convert 24 to 16 bit

any recommend a batch utility to convert 24 to 16 bit for a sound library? thx Alan

Thanks Rohan & Rockbottom.
Library conversion was smooth. Logic performed(seemingly)flawlessly.Samples sound great.Used #3 dither. I converted the Giovani Edition by Bela D. Most of what i do is fine to my ears at 16 bit & my rig never ever even flinches. Many of the new great sound librarys out there are 24 bit & now i can choose which bit world to be in depending on the project.
Rohan, i poked around your site.Really great music.But it was late that night & i was kind of chilling & was digging the "Peter Pan" cue & then the Coo Coo clock scareded me out of my seat.
Cheers,
Alan

Fichier au format ieee 754

Bonjour,
Est-ce-qu'il est possible de traiter directement un fichier au format IEEE-754 sous Diadem??
Sachant que ce fichier est généré par labview sous une extension qu'on a défini *.rap (comme acquisition rapide).
Je joins un exemple de mon fichier.
Merci d'avance.

Hi M. Brad Turpin,
Yes, I have a LabVIEW program which is streaming binary (IEEE-754) data to disk to a file with the extension *.rap, and I would like to know if it is possible to read this file into DIAdem directly?
I attach in the folder *.zip the VI and several *.rap file. The VI ("PXI31.vi") write these *.rap files in the NI PXI 8186. I have too a VI ("concatenar_archivos.vi") that transfer and concatenate these *.rap files in a PC. In the folder "NI.zip", you have several *.rap file and one *.txt file that the conversion in float of file "5_11-43-05_11-10-2007_NI.Rap". Like this, you can to compare.
In the *.rap file acquisition, from the "5_11-..rap" you have 48 channels and 120 sample. And in other *.rap file acquisition, I have 32 channels and 500000 sample but I can't send this file because it's big file.
Thanks you for help.
Attachments:
NI.zip ‏1038 KB

IEEE 754 standards for representing floating point numbers

HI All..
Most of us are not awared how the actually Floating point numbers are represented . IEEE have set standards as how should we represent floating point numbers.
I am giving u the link with which u can know how actually these are represented.
http://en.wikipedia.org/wiki/IEEE_754
If u have any doubts u can always reach me.
Bye
Happy learning
[email protected]

A noble but misguided attempt at dispelling the recurring problems the programmers have over and over again. There have been repeated posts to links about the IEEE standard, to little or no avail. The newbies who run into the problems will continue to do so, without regard to yet another post about it here.

BUG: Large floating point numbers convert to the wrong integer

Hi,
When using the conversion "bullets" to convert SGL, DBL and EXT to integers there are some values which convert wrong. One example is the integer 9223370937343148030, which can be represented exactly as a SGL (and thus exactly as DBL and EXT as well). If you convert this to I64 you get 9223370937343148032 instead, even though the correct integer is within the range of an I64. There are many similar cases, all (I've noticed) within the large end of the ranges.
This has nothing to do with which integers can be represented exactly as a floating point value or not. This is a genuine conversion bug mind you.
Cheers,
Steen
CLA, CTA, CLED & LabVIEW Champion
Solved!
Go to Solution.

Yes, I understand the implications involved, and there definetely is a limit to how many significant digits that can be displayed in the numeric controls and constants today. I think that either this limit should be lifted or a cap should be put onto the configuration page when setting the display format.
I ran into this problem as I'm developing a new toolset that lets you convert all the numeric formats into any other numeric format, just like the current "conversion bullets". My conversion bullets have outputs for overflow and exact conversion as well, since I need that functionality myself for a Math toolset (GPMath) I'm also developing. Eventually I'll maybe include underflow as well, but for now just those two outputs are available. Example:
I do of course pay close attention to the binary representation of the numbers to calculate the Exact conversion? output correctly for each conversion variation (there are hundreds of VIs in polymorphic wrappers), but I relied in some cases on the ability of the numeric indicator to show a true number when configured appropriately - that was when I discovered this bug, which I at first mistook for a conversion error in LabVIEW.
Is there a compliancy issue with EXT?
While doing this work I've discovered that the EXT format is somewhat misleadingly labelled as "80-bit IEEE compliant" (it says so here), but that statement should be read with some suspicion IMO. The LabVIEW EXT is not simply IEEE 754-1985 compliant anyways, as that format would imply the x87 80-bit extended format. An x87 IEEE 754 extended precision float only has 63-bit fraction and a 1-bit integer part. That 1-bit integer part is implicit in single and double precision IEEE 754 numbers, but it is explicit in x87 extended precision numbers. LabVIEW EXT seems to have an implicit integer part and 64-bit fraction, thus not straight IEEE 754 compliant. Instead I'd say that the LabVIEW EXT is an IEEE 754r extended format, but still a proprietary one that should deserve a bit more detail in the available documentation. Since it's mentioned several places in the LabVIEW documentation that the EXT is platform independent, your suspicion should already be high though. It didn't take me many minutes to verify the apparent format of the EXT in any case, so no real problem here.
Is there a genuine conversion error from EXT to U64?
The integer 18446744073709549568 can be represented exactly as EXT using this binary representation (mind you that the numeric indicators won't display the value correctly, but instead show 18446744073709549600):
EXT-exponent: 0x100000000111110b
EXT-fraction: 0x1111111111111111111111111111111111111111111111111111000000000000b
--> Decimal: 18446744073709549568
The above EXT value converts exactly to U64 using the To Unsigned Quad Integer "bullet". But then let's try to flip the blue bit from 0 to 1 in the fraction part of the EXT, making this value:
EXT-exponent: 0x100000000111110b
EXT-fraction: 0x1111111111111111111111111111111111111111111111111111100000000000b
--> Decimal: 18446744073709550592
The above EXT value is still within U64 range, but the To Unsigned Quad Integer "bullet" converts it to U64_max which is 18446744073709551615. Unless I've missed something this must be a genuine conversion error from EXT to U64?
/Steen
CLA, CTA, CLED & LabVIEW Champion

Floating Point Representations on SPARC (64-bit architecture)

Hi Reader,
I got hold of "Numerical Computation Guide -2005" by Sun while looking for Floating Point representations on 64 bit Architectures. It gives me nice illustrations of Single and Double formats and the solution for endianness with
two 32-bit words. But it doesn't tell me how it is for 64-bit SPARC or 64-bit x86.
I might be wrong here, but having all integers and pointers of 64-bit length, do we still need to break the floating point numbers and store them in lower / higher order addresses ??
or is it as simple as having a Double Format consistent in the bit-pattern across all the architectures (Intel, SPARC, IBMpowerPC, AMD) with 1 + 11 + 52 bit pattern.
I have tried hard to get hold of a documentation that explains a 64-bit architecture representation of a Floating Point Number. Any suggestion should be very helpful.
Thanks for reading. Hope you have something useful to write back.
Regards,
Regmee

The representation of floating-point numbers is specified by IEEE standard 754. This standard contains the specifications for single-precision (32-bit), and double-precision (64-bit) floating-point numbers (There is also a quad-precision (128-bit) format as well). OpenSPARC T1 supports both single and double precision numbers, and can support quad-precision numbers through emulation (not in hardware). The fact that this is a 64-bit machine does not affect how the numbers are stored in memory.
The only thing that affects how the numbers are stored in memory is endianness. SPARC architecture is big-endian, while x86 is little-endian. But a double-precision floating-point numer in a SPARC register looks the same as a double-precision floating-point number in an x86 register.
formalGuy

Convert IEEE-754 32-bit Hexadecimal to decimal floating-point

Similar Messages

Maybe you are looking for