Problem With COP, INTS and REALS

done this a hundred times
Maybe I just went stupid

got an INT array called TESTINT[2]
got a real called TESTREAL
I do a COP of SOURCE: TESTINT[0]
DEST: TESTREAL
LENGTH: 2
and all I get is weird engineering numbers like 1.xxxxxx-e02
no matter what values I put in TESTINT[0] and or TESTINT[1]
I am perplexed

so I converted the TESTREAL to a DINT and the conversion is correct So what is causing the Exponential display instead of the normal Real

COP does not care about data types, it just moves the bit patterns found in the source locations to the destinations. If the destinations data type is different, you can get weird results. Sometimes this is useful, other times it can be a problem.

MOV does a data type conversion for you.

So, you can MOV TESTINT[0] TESTREAL[0], MOV TESTINT[01] TESTREAL[01]

If you have more than a hand full of items to "copy" this could be cumbersome and there is probably another instruction which may work out better for you.

Where are you seeeing the 'wierd engineering numbers'? It may just be a display setting.

Please give a precise example of the values in the two INTs and the resulting REAL display. What were you expecting to see?

I am going to give this a try, I checked on the AB web site and this is what I found
the data is stored in a completely different formant between INT and Real Types in the Logix Processors
while when using the SLC, Micrologix or the PLC5 processors you could just copy the data from one type to the other with the copy command. In the Logix Processors the data type is stored differently so it's not that simple anymore.

attached are 2 documents I printed out in PDF format from the AB KB site I think will help explain it. they didn't print out as well as I hoped but I think you will get the idea
if not then maybe somebody else can find a better document

DINT's and REALS are different formats on ANY platform.

A typical reason to COPY 2 INTs into a REAL is that the 2 INTs were received from a communication channel which is actually sending a REAL but could only send it in the format of 2 INTs.

The COPY takes the exact bit pattern of the 2 INTs and places that 32 bit chunk into a REAL. Then the REAL value is shown as a readable number.

As RDAST pointed out, the method of storing a value using bits is very different between INT/DINT and a REAL. Note the documents linked by GaryS. If you don't understand the storage of values in a REAL/float then the whole process will probably continue to confuse you.

Hi Guys
Thanks for all your support, data manipulation is something I come across most days but I think this is my lack of understanding with the Micro820.

In my case the Modbus data is visible but the COP does not seem to work.

In the attached picture you will see data in FB_1.Localaddress_Read[1] 16365
FB_1.Localaddress_Read[2] 15607

However my COP complains about "Destination size is too small for the copy".

The destination is Level_pt1 which is data type DWORD, i've tried LWORD too.

Many Thanks guys
Mark

I haven't worked with the Micro820 yet (thankfully) but, assuming that the instruction operates similar to other AB platforms, the error is correct. in the COP instruction the length is based on the destination data type. It is not a fixed number of bytes/words. Since your destination is a single tag, you can't have a length greater than 1.

This is a change from the Logix platform. In Logix there is no specific check to make sure the data you are copying from the source will fit in the destination. the plc will happily corrupt your tag memory if you ask it to. It looks like the development environment for the Micro820 it trying to protect you from yourself.

Keith