AB ML1200, Interger to Floating Point

Does anyone have an example of converting two 16bit integers N10:0, N10:1 into a floating point F8:0?
This is very new to me and Im tyring to get a unit out the door, but the logic we have (from AB), is giving a 1.xxxxxxx-10 number...?

I'm assuming that the contents of the two integers contain IEEE floating point format data, perhaps read from some device over Modbus, or DeviceNet, etc. If so then you use the copy (COP) instruction. COP makes an exact bit to bit copy of the data at the new memory destination without regard to data type.

COP #N10:0 F8:0 1


If the data in N10:0 and N10:1 is not IEEE floating point data then get back to us with more information and wel'' be happy to help out. There are quite a few threads on here about handling floating point data represeneted in consecutive 16 bit words.


Can you post what you have so far, what the contents of N10:0 and N10:1 are, and what floating point number you are expecting to see?

The data is IEEE-754 per the manual. It is being read, over Modbus two wire, with a B&B RS232/RS485 convert between. We have done it numerous time with Twido PLC's, but this is one of the first tries with AB.

Im not sure if the example will show up here...
Ill try to explain it:
Rung 0 has an ABS box with Source of N10:0, Dest F8:0
Also in parallel with ABS is XIO bit N10:1/15 and then a SUB box A=32768, B=F8:0
In parallel with the USB box, is an ADD box, A=32768, B=F8:0
Rung 2 is a MOV box with N10:0 as Source and Dest is F8:1
In parallel with the MOV box is MULT box with A=F8:1, B=65536.0 and dest= F8:1
Rung 3 is ADD box with A= F8:1, B=F8:0, Des=F8:0

Does this make sense? Its actually something AB tech support gave us... but ends up with completely wrong numbers., WAY off. They should be, in this case, F8:0=432, F8:1= 528

Hope this makes sense.

NH

Alaric said:

I'm assuming that the contents of the two integers contain IEEE floating point format data, perhaps read from some device over Modbus, or DeviceNet, etc. If so then you use the copy (COP) instruction. COP makes an exact bit to bit copy of the data at the new memory destination without regard to data type.

COP #N10:0 F8:0 1


If the data in N10:0 and N10:1 is not IEEE floating point data then get back to us with more information and wel'' be happy to help out. There are quite a few threads on here about handling floating point data represeneted in consecutive 16 bit words.


Can you post what you have so far, what the contents of N10:0 and N10:1 are, and what floating point number you are expecting to see?

Click to expand...

nhicks, do what Alaric suggested. The example that AB gave you is used to convert a 32-bit integer to a float. You have a case where two consecutive 16-bit integers contain the bit pattern for a 32-bit IEEE single precision float. A COP instruction will take the values in the integers and copy them, byte-for-byte, to the float element, which is what you want.


Keith

Post also the values you see in the two integer data elements, in decimal or in hex.

It'll work. The byte order is likely just not correct.

Ken, if nhicks is correct about the value being an IEEE-754 format value then the code he describes will not work. The code he describes will 'convert' a 32-bit integer to a float.


Keith

Keith is to be commended for his thoroughness. I stopped reading the pseudocode when I saw it had two arguments where I expected three.

"Listen to him. He's pre-Med."

nhicks.

All we need to determine is if N10:0 is low order word and N10:1 is high order word, or if its the other way around, and we can give you a really slick conversion. But what we need to know is what is in N10:0 and N10:1 and what you expect the float to be.
If the format is already IEEE float, then all we need to do is get them words in the right order and then make an exact bit-bit copy

The links for the images you attemped to post are on your computer's hard disk, so naturally we won't be able to see them. If you will scroll down in your browser page on the advanced posting window you will see a button "display pictures." Click this and browse to the screen shot image file you want to uplaod and upload it to the plctalk.net server. You will then get a pop up window that gives you the bbcode to cut and paste into a post that will display the image you just uploaded.

You can also zip a .RSS file and attach it using the attach files button. But what we mainly need to know is the values in the registers and what you are really expecting to see. Then one of us can determine the order.

If you want to attempt to determine the order yourself, see this link: http://babbage.cs.qc.edu/IEEE-754/32bit.html Enter the values of N10:0 and N10:1 in hex form (8 consecutive hex digits) and see if it gives you what you want, if not, swap the first four hex digits with the last four. It will also give you a bit pattern that will exactly match the contents (in the matching order) on N10:0 and N10:1. One you have that order, then put the two words in the right order, and then COP it into F8:0.

For example, if your instrument returns the value PI, then
N10:0 contains 4049
and N10:1 contains 0FDC
then COP #N10:0 F8:0 1 will give you 3.141953, PI, in the address F8:0.

It may be possible, depending on your instrumentation, that you have to swap the values. In that case, for the PI example above
then N10:0 would have 0FDC and N10:1 would have 4049. So you need to to something like this:
MOV N10:0 N10:3
MOV N10:1 N10:2
COP #N10:2 F8:0 1


In the case of the 432 valu you were expecting, then one of the N10 registers should have the hex number 43D8 and the other should have 0000.

clear as mud?

Nhicks, are we back to logging this data again?

http://www.plctalk.net/qanda/showthread.php?t=28776&page=1&pp=15

SNK, not yet, but that is the next project, that this information will surely help out on.
Just finishing up a 16 hour day, we found a work around to get it going, but its not the right way to do it. I will attempt to post more info when I can tomorrow, its bed time here!
If your interested, here is a link to the meter we are using to pull data from, for this application, we only use the Volts per phase, to make sure we are in the window.

http://www.multitek-ltd.com/PDFs/M801MAN.pdf

For the data logging app, we will use the Amps & Volts per phase, KW, and Hz.
In the example from AB, it would write the actual voltage in a whole number, to F8:0. When we did it this time, we got 1.0320320 or so, to the -10 power. The work around, was using N10:0 and N10:1 directly (N10:0 would give a 17xxx number) and we related that directly to certian voltages. N10:0 was relatively stable, but N10:1 would jump heavily, N10:2 and N10:4 were also stable, as well as N10:3/5 jumped heavily.
I appreciate your help so far!

NH

Based on the manual reference you list and the results you are getting I would say the word order is definitely backward and both the byte and word order may be backward. The manual link says the device transfers the highest order byte first. I know for sure you need to swap the words. I'm just not sure if you need to swap the bytes as well. I think you do but I'm not sure.

If you can receive a known value, you can use the link Alaric posted above to play with the byte order until you get the result you want. Just view the data in hexidecimal format and move them around two characters at a time.

Keith

Just swapping never worked for me. You have to do some shifting to get the right data out.

I've been fiddling as (my) PLC did not have native support for floating point (scientific).

First bit contains the sign of the number
bit 2-9 contain the exponent (biased)
Rest 23 bits contain the remainder (mantissa).

Originally posted by M_vanBurgh:

Just swapping never worked for me. You have to do some shifting to get the right data out.

Click to expand...

In your post you just described a IEEE-754 float. Your bit order is completely backward but other than that its a properly formatted float. This wouldn't require any shifting to get a valid number.

Keith

I guess this also depends on your PLC, as I read bits from left to right, resulting that my first bit is the sign.

My PLC does not support floating points, only Reals, so I had to convert it.

Originally posted by M_vanBurgh

My PLC does not support floating points, only Reals, so I had to convert it.

Click to expand...

In most of the liturature I have seen, 'floating point' and 'real' are used interchangeably, although technically I don't think they are exactly same. Do you mean you only have integers?

If your plc reads bits from left to right you must have the same bit shifting issues with integers. I can't think of any system where the least significant bit in the storage location equates to the most significant bit in the value representation. That must be hard to deal with.

Alot of this issue comes down to how each plc manufacturer deals with memory. AB, for example, requires that you specifically typecast a data element. However, they don't require you to specify how to perform functions on that data: that is implicit in the data type. Siemens, on the other hand, has no specific typecasting of data elements. It's all in how you look at the data and the functions you use on the data that determine what the value and result are.

So, in AB you need an instruction like the COP (copy) instruction if you want to change a data representation. In Siemens you just use the instruction type you want and the data is used correctly.

Keith