Hi All,

I am reading from 4 registers in RSLogix5000 which correspond to a volume reading on a flow computer.

The 1st register contains the integer value 16548 = 40A4 Hex
The 2nd register contains the integer value -10041 = D8C7 Hex
The 3rd register contains the integer value -20972 = AE14 Hex
The 4th register contains the integer value 31457 = 7AE1 Hex

Now, when I combine the Hex values: 40A4D8C7AE147AE1
and place them in this form

http://www.markworld.com/showfloat.html

where it says "double-precision IEEE number as 16 hex digits"
and hit convert out pops the decimal equivalent 2668.388 which
is what is on my flow computer and the exact number I want.

Now my problem is how do you get RSLogix5000 to perform this calculation?

I cant seem to figure how to do it!

Thanks in advance
David

I use this site:
http://babbage.cs.qc.edu/courses/cs341/IEEE-754.html

Where did these numbers come from? The SLC500 didn't generate these.
Can't what ever generated the 64 bit float generate a 32 bit float instead? That would be the easiest.
Otherwise You need to read the IEEE 754 specification to find out the difference in the exponent and mantisa fields between the 32 bit and 64 bit floats. This conversion will be messy but not hard.

probably received through fieldbus or serial connection from flowmeter...

http://en.wikipedia.org/wiki/IEEE_754

i would check if this range is needed and if not, can transmitter can be configured for
different output type (is this maybe also a totalizer?)
if this is not possible but the range allows i would first try to simply fit it into a single precission float
using simple bit manipulation and masks:
highest bit is sign -> just copy it...
transfer used parts of exponent (8-bit) and mantisa (23-bit), them copy (COP) whole 32-bit result into an F8 register. if that doesn't produce desired result, write whole thing from scratch (sample code available in C)

Hi,

Im reading the values over Modbus communications and Im afraid I dont have the option to reconfigure
the transmitter to change the output so Im gonna have to invistigate the IEEE 754 standard a lot more.
I find all this number manipulation a bit daunting,pardon the pun, so any help would be great in
performing the tasks in RSLogix5000.

Like for example how do you create a F8 register in RSlogix as suggested?

Thanks
David

Check Out this Link for IEE 754 Info

If I can translate it to Logix 5000 later I will.

Will have a look at that link.Cheers.

It would be unreal if you could do it in Logix5000, not that im being lazy.
Its just that all this bit manipulation I feel could be beyond me.Im just used to creating valve blocks
etc in PLC code.Fairly basic

David

seam simple, it should be just three places bitshift and restore sign (xic ote) then copy DINT to REAL.

or... do it backwards, type the floating point RESULT into a REAL and copy this to DINT, then
compare bit positions with your 64-bit value comming from flowmeter.

Here is solution:

[attachmentid=3092]

I'll put comments tomorrow.
One thing is missing:
It is necessary to analyze if exponent is within 8 bit limits or conversion is impossible.

Good show! Those bit distribute instructions are handy. I would have used shifts, masks and 'or'ed the results together.

Beat Out Again -- Almost had it. See if this Looks Like what you are talking about Conn.

[attachmentid=3093]

Hi Again,

Just one more thing.Any chance BobLfoot you could post your code
as code done on version 13 RSLogix because I dont have the newer version
and im curious as to your method and cant open it.Thats if it isnt too much
trouble to do so

Cheers
David

BobLfoot's code does about the same as mine and plus checks for exponent value.

Few things to smplify in Bob's code:
Because mantissa in Float-32 is much shorter, only 3 bits used from Integer3 and integer 4 is not used at all.So rung2 BTDs can me simplified.

or 6 BTDs (Rung 2 and 3) can be replaced with one COP and 2 BTDs

You don't have to separate mantissa at all, you can dumpt it to directly to the result as no changes required.
Only exponent needs to be re-calculated

IT was a small program and not bad to do. Might Check and make sure it works. I don't have a test plaform right now.
[attachmentid=3094]

Thanks very much for that Bob.
Opened fine for me.

Cheers

GRT>255 is not enough, must check negative end as well (just in case!)

I would do 2 steps:
E1=E-1023
LIM -127 E1 127
E1=E1+127

Thanks Conn This type math was always a little weak even though I have a B.S. in math

Hi,

Ive managed to get the numbers out using Conns method which is much appreciated
but when I run Bobs it seems to give me a Not Convertable output and the real value
doesnt come out.Attached is my running code.Ideally i would like to provide this checking
that ye are suggesting.Also in my code MCMReadData[142] is the first integer and MCMReadData[143]
is second etc etc by the way.

Thanks

MCMReadData[142] has large negative number that rases flags right away.
Are you sure you not swapping integers (first-last)
I see it has D8C7 that is second INT!
MCMReadData[142 ] should be 40A4 if Bob's calculation used.

Brilliant,i got the program reproducing what i want.

It was a silly mistake on my part.I owe ye Conn and Bob a few pints of Guinness if
ye ever visit ireland!

Just one more attachment so could ye make sure that im performing the check adequately as suggested
in Conns code and im good to go.

Cheers

In the CLX the BTD is a nice slick way to do it.

Here is a link to a conversion I did in a thread on another forum for doing the same thing in a SLC500. It may help in understanding what is going on, for what its worth.

http://www.plctalk.net/qanda/showthread.php?t=20575

[attachmentid=3102]
I don't know how you got it working, but these highlited instructions are completely wrong!

Simplified based on Alaric's feedback
[attachmentid=3103]

The only thing to watch out for with the simplified version is that there is no range checking on the exponent. If the exponent is greater than 38 or less than -38 then the simplified conversion will be bogus. However I think that the times when a measured process value needs an exponent greater than 38 would be very rare so for most applicaitons we don't need to care about it, but the thing to watch out for is very small near zero numbers which have an exponent less than -38. You may want to trap for those and just write a zero to the result.

I think I need to explain why we are talking about exponent <=38 while testing exponent field for < 128

Exponent field in FLOAT-32 is 7 bits plus sign, so highest number that fits there is +/- 127

2^127 is about 10^38 and this is used to display floats

So if we are checking exponental binary portion of the FLOAT-64 (bits 52-62), we should check for value +/-127 in these bits.
Technically we need bits 59-61 of FLOAT-64 to be zero to perform valid conversion and this can be done with 3 XIC instructructions only.

[attachmentid=3105]
This explains conversion
It is time for a technote ;)

Thanks for covering me on that exponent ContrConn.

I just ASSumed that eveyone would understand that I was speaking decimal (10**38) and not binary (2**127) - but its always better to make those things precisely clear. Its easy to see how someone could come along and find this thread and misunderstand.

The bit DINTTAG[1].30 is the sign bit for the exponent. If it is set then the exponent is negative, making our 64 bit floating point number less than 1. For converting very very small numbers, numbers that would have more than 38 leading zeros between the decimal point and the first non zero digit if we were to write it in base 10 decimal, we could run into conversion problems. This is very possible with 64 bit numbers from instruments because the instrumentation very rarely measures exactly zero.
This rung will trap for out of range exponents at near zero values (negative exponents that are less than -127 binary) and just make the converted value zero.
XIC DINTTAG[1].30 BST XIC DINTTAG[1].29 NXB DINTTAG[1].28 NXB XIC DINTTAG[1].27 BND CLR REAL_TAG


As I said earlier though, the need to trap for expnents larger than 38 (decimal) is probably rare, but if you do need it the following will do the trick:
BST XIC DINTTAG[1].29 NXB DINTTAG[1].28 NXB XIC DINTTAG[1].27 BND BST XIO DINTTAG[1].30 MOV 1065353216 BUFF NXB XIC DINTTAG[1].30 MOV 2139095040 BUFF NXB COP BUFF REAL_TAG 1 BND. This will set the result real tag to + or - infinity.

Ok it looks like this thread is on its way to being resolve so I just got to ask, what type of applications would require 64 bit floating numbers?

I dont think it is the application so much as it is the instrument. Some instruments just return double precision floats rather than single precision floats. You may have an instrument that speaks Modbus and so you get back 4 16 bit words that you need to convert to a single precison float.

Maybe the instrument was designed by an ANALytical engineer who did it just because he could.

Oh ok, that makes sense. I was just trying to find a practical application that requires this. I am sure there are some but they are just not in any industries that I have worked in I guess

Thanks
TW

This as been very well resolved for me and I now have a working model.
Thanks for the help and detailed explanations

David

Motion control. We use 64 bit floating point in some cases where accuracy is necessary. Our newest motion controller uses a PowerPC. However we can't use the 64 bit floats when talking to the outside world because of PLC don't understand 64 bit floats.

Functions that motion controllers use like exp(), ln(), cos(), sin(), asin() etc are computed using approximations that are caluclated using Taylor series. There is a lot of adding and subtracting in these routines and floating point results lose accuracy when small numbers are added or subtracted from large numbers. Round of errors will always occurs but single precision floats provide about 6-7 digits of accuracy and doulbe precision float provide about 15-16 digits. So if you make a series of short moves all day and the error build up, what precision floating point do you want to use?

Believe me, just because you have a floating point processor doesn't mean you can ignore round off and other precision errors. We often see problems when people try to accumuate milliseconds. A millisecond or .001 seconds can't be truely represent by a floating point number. If you add 0.001 1000 times it will not add up to 1. We have to tell people to accumulate millisecond as integer milliseconds and then mulitply by 0.001.

Yes, good point Peter.

Guess that's why I couldn't see it, mine are much simpler. Run, cut, on to the next part, run, cut, on to the next part, run.......

Congratulations everyone. MRPLC got its first Rockwell Technote recognition

http://domino.automation.rockwell.com/appl...B4?OpenDocument

Look right above the download

Congratulations.

Im glad to have been a part of it and im sure it will help many more people in times to come.

Regards
David

I just want to know how TW finds these so easily. You need to write a technote search primer.

TW was out for a week, so I guess he had too much time for these searches... Or maybe he has some good friends

Yes Bob, I must admit I can't take the credit. I might would have gotten away with it but I am still catching up on my emails which contains my technote readings from being out for a week.

I learned about it in the same manner you have. I good friend informed me of it. Well let me clarify this, I learned about it from a good friend, don't know what you would consider your source to be

I do read all technote titles which I subscribe to through email, but I don't always read everyone though I do try to.

Have you subscribed to the technote notification system?

http://support.rockwellautomation.com/Pref...Information.asp

Here is a search hint:
Go to knowledgebase, and select technotes published within last 30 days.
Select Programmable controllers

This technote will be on the top.

[attachmentid=3220]