Copy a Integer to a floating point PLC5

Join Date
Dec 2010
Location
Burlington, NC
Posts
402
I have noticed in one of our PLC5 programs there is a copy instruction that copies a integer into a floating file. The integer value being copied is 18147 (N39:78). after the copy takes place the value displayed is 29163 (F92:95). my question is what happens to make this number change. I understand an integer is a 16 bit format and a floating word is a 32 bit but I don't understand the conversion. Can some explain in detail what goes on behind the scene.
 
The COP Instruction does a Bit for Bit copy, and no Data Format Conversion. The MOV Instruction will change the Data Format during the move. So, for the Copy, the number you get will appear to be random, because the Bits represent entirely different things.

Google IEEE-754 Floating Point, or you can look at this article in the AB/RA Tech Article 7765. It is tagged for everyone.

Stu....
 
Last edited:
COP performs a bit for bit exact copy of the binary pattern stored at the address, it does not convert and copy the numeric value as MOV does. For more information on the IEEE-754 floating point number format and how floats are represented in all computers see the following.

Wikipedia article on IEEE754 format.

A set of tools that lets you play with various values to actually see the bit pattern of floating point numbers.
 
COP #N39:78 #F92:95 1 , the copy is the only instruction on the rung. if i copy an integer into an integer the value remains unchanged only when I copy an integer to a floating word is the value changed.
 
Mark, the COP length is the destination length. Since the destination size is 32 bit then two words are copied. So COP #N39:78 #F92:95 1 will copy the contiguous bit pattern in the two registers N39:78 and N39:79 and place all 32 bits without any transposition or change in F92:95.

My guess is N39:78 and N39:79 are words that are coming from some device that sends a float over a comm link as two integers. This is common in Modbus devices as well as many others.

As an example, lest say that N39:78 has the value 16457 and N39:79 has the value 4059.
The respective binary values are 0100000001001001 AND 0000111111011011.
When copied to F92:95 then F92:95 will have the binary value of 01000000010010010000111111011011, which happens to be the binary pattern for pi. You will see 3.141593 if you look at F92:95 in decimal radix.
 
Last edited:
The COP istruction applied betwen an INT Source (16 bit) and a REAL (Float- 32-bit) Destination will copy bit-per-bit the Source's binary data within the first 16 bits (0-15) of the 32-bit Float Destination's address, leaving the rest of them (16-31) unchanged.
Within your particular example:

SOURCE N39:78 = 18147 (decimal) = 0100 0110 1110 0011
(binary)

DESTINATION F92:95 = 29163 (decimal) = 0000 0000 0000 0000 0100 0110 1110 0011 (binary)

The conclusion is that the decimal value of data is determined by the size of the allocated memory; in your case, the "original" 18147 (using a 16-bits "chunk" of memory) becomes
29163 when COPed within a 32-bit memory location.
 
I tried to send our forum colleague dmargineau a private message but the forum indicated that he is unable to receive PMs right now, so in the interest of accuracy for others I have to clarify a few things.

The COP istruction applied betwen an INT Source (16 bit) and a REAL (Float- 32-bit) Destination will copy bit-per-bit the Source's binary data within the first 16 bits (0-15) of the 32-bit Float Destination's address, leaving the rest of them (16-31) unchanged.

From the manual:

attachment.php


The length of data copied is dictated by the destination size. Since the destination is 32 bits long in this case then 32 bits are copied from the source, which becomes the two consecutive integers at the source. This incidentally is why the # is required on the address, to indicate that a file operation is in process.


Within your particular example:

SOURCE N39:78 = 18147 (decimal) = 0100 0110 1110 0011
(binary)

DESTINATION F92:95 = 29163 (decimal) = 0000 0000 0000 0000 0100 0110 1110 0011 (binary)
The binary pattern 00000000000000000100011011100011 in IEEE754 float format = .00018147, not 29163

I'm pointing this out because misunderstanding how floating point numbers are stored and used in a computer, especially a PLC, could lead to a costly mistake.


I'm betting that the value stored at the OPs N39:79 is -10752. That is the only way he can be getting the result 29163.

One of the links I posted earlier was to some online tools to help visualize how IEEE floats work. I find the tools to be quite helpful for me, especially when I'm tying to decode whether something is big endian or little endian and when trying to work out the byte order of unknown data.
 
Last edited:
TConnolly, I totally agree with

0000 0000 0000 0000 0100 0110 1110 0011 = 0.00018147 (IEEE754)

However, with Post #1, the OP states that, within his PLC5 application (unknown Series, Firmware revision, age, etc.) the result of his application's COP is 29163 (decimal) after he COP 18147 (decimal) into it.

My trustworthy Win7-64 bit Calculator utility, set in Programmer Mode reads:

0100 0110 1110 0011 as 18147 (decimal) in Word Mode

and

0000 0000 0000 0000 0100 0110 1110 0011 as 29163 (decimal) in DWord Mode

fact which denotes that the Destination of the COP instruction is a non-IEEE754 32-bit memory location hence the results the OP is experiencing.
I am personally trying to avoid deploying COP instructions between different data types, especially in Legacy systems, however, at times this type of implementation is necessary due to data mapping differences between various manufacturers' integrated systems/devices.
 
Last edited:
In order to explain the OPs results we have to recognize that N39:79 is also part of the result. Two 16 bit integers are copied into a single 32 bit float.

Our OP has the following:
N39:78 = 18147 which is 0100 0110 1110 0011
N39:79 = -10752 which is 1101 0110 0000 0000

COP #N39:78 #F92:95 1 copies both integers and places

0100 0110 1110 0011 1101 0110 0000 0000 in F92:95.


If we go to the tools link I mentioned earlier to examine the IEEE 754 floating point bit pattern for 29163 we get,

0100 0110 1110 0011 1101 0110 0000 0000

which matches the pattern above.
 
Based on one of Mr. Connolly reply I would have to say that is the correct explanation. This base on the fact that he did not know what value was in N39:79, which is in fact -10752. This was interesting. thank for the help in understanding this.
 
Perhaps an excerpt from the PLC5 Instruction Reference will help.
I concur with Mr. Connolly's opinion on the matter.

Stu....
 
There are some technotes in the AB KB that provides a very good explanation of IEEE-754 floats as used in all AB PLCs. Look for TN 18209, 18912, 7765, and 24472. Hope this helps everyone. 🍺
 
There have been many responses to this thread indicating the erroneous result is due to the length of either the source or destination data type.

Length is not the issue here, you cannot use COP between different data types. It is nothing to do with the size of the data, but the way the data is structured, i.e. how the bits are interpreted.

It's been said before in the thread, but I will state it again for emphasis, COP is a byte-for-byte memory location copier, and does not take into account the encoding of the data structure of either the source or destination data.

If you need to transfer the value of an INT to a FLOAT, or vice-versa, you absolutely MUST use the MOV instruction, which performs the necessary conversion between the different data-types and how they are stored in the memory locations.

Bottom line - COP was introduced as a fast way to copy data around, and is intended to be used to make copies of the same data-type.

It's not restricted in any way, and you can use COP between different data-types, with potentially erroneous results.

However it must be stated that experienced programmers can and do use COP between different data-types in a variety of ways, but it involves a much deeper understanding of the PLCs internal data storage. Only use COP for data transfers between different data-types when you fully understand the way the PLC interprets the bit patterns in the different data-type storage locations.
 
Last edited:
o_O
I disagree daba.

If the original data is a IEEE 754 floating point number, passed as a bit for bit copy into two consecutive integers "from somewhere else in controller land", and you use a MOV, you will destroy the data. You need the byte for byte, bit for bit, "image" of that float back, and the destination of the COP provides this handy dandy feature.
 

Similar Topics

Productivity3000. I have a 32 bit integer, 1d array that i need converted to a string. The string to array seems to work with the same time type...
Replies
0
Views
2,158
I have a micrologix 1100 and I need to extract characters from a string data type and store the ascii values for each character in an integer type...
Replies
7
Views
13,203
Hello Inside a FB, I´m trying to transfer a string from a DB to a IN_OUT var that was define as a UDT. The problem is that i can´t determine the...
Replies
4
Views
72
Hi everyone I'm in a bit of a conundrum, I've been trying to get this HMI on our machine and I am unable to retrieve it. Device Delta Model...
Replies
10
Views
732
Hi I have a Melsec FX1S-20MR, which has been programmed. I would like to copy the program to a new FX1S-20MR? What are the possible ways to do...
Replies
4
Views
565
Back
Top Bottom