RSLogix MOV and COP

You typically can only COP elements of the same type (i.e. INT to INT or FLOAT to FLOAT). What you will need to do is round your decimal int to the size you want and use a DIV command and MOV the decimal part to the Float register. Then ADD the whole integer to the new FLOAT to get your combined Float number. There's no real easy way around it. Do a search on the forums because I know this topic has come up before.
 
jkozey said:
I have been trying to do the same thing as this topic discuss. I have 1 floating point from a modbus device that through a redlion data station I am able to get into a PLC5. The floating point is stored in 2 integer files. I need to convert these 2-16 bit int into 1 float. I know I need to copy these into F8:0 but I don't know how to get it to copy 2 int to 1 float. I can only copy it into two seperate floats which then requires a lot of code to offset and convert. Any ideas or examples?

thanks

PS I've also tried to enter what your example discuss

COP (N7:1, F8:0,1) This format doesn't make sense. How do I enter it. Are you trying to say use a
copy statement from N7:1->F8:0 length 1?

That won't work if so & I assume therefore that I am reading it wrong.
thanks again

Greetings Kozey and welcome to the forum.

Yes, COP #N7:1 #F8:0 1 will work to move the bit pattern (more on this in a minute) of a floating point number stored in two integers into F8:0.

Refer to AB technote 18912 in the AB knowldegebase at http://www.rockwellautomation.com/knowledgebase/ for a full treatment of using COP to move between different data types.

First two things. Note the # in front of the addresses. This # tells the processor that a file operation is being performed. The processor will use indexed addressing during the execution of the instruction, even though ultimately its moving just one float.

Next, lets talk about the actual data you are trying to move. Notice that I said "bit pattern" earlier. Floating point numbers are stored in a special data format called IEEE-754. It requires 32 bits to store. Half of the bit pattern can be stored in one 16 bit integer, and the other half in another 16 bit integer. But if you view them as integers then the numbers won't look like you expect them to look. For example, the floating point number 1.05 would be stored as 16262 in one integer and 26214 in the other. The next important thing is the order of those numbers. Because 16262 and 26214 might translate to 1.02, but 2614 and 16262 represents a very different number, 2.7183 x 1023.

Modbuss devices trasmit floats as two integers, but you will have to experiment to get the order of the two intgers right before you perform the COP instruction.
 
Last edited:
I didn't think the PLC5 could do that with the COP command. I thought it was only available in CLGX. Thanks Alaric. Learn something new every day.
 
Here you have an example on how to convert integer into float.
rslogix 500.


int_float_1.JPG

int_float_2.JPG



int_float_3.JPG
 
2 ints to 1 float

From both of your examples I see copy some ints to float with a length. When I do this I move each integer into the corresponding float. What I mean is my original value of N7:0 and N7:1 with a copy length of 2 gives me N7:0 into F8:0 and N7:1 into F8:1

The SLC example appears to demonstrate this with a length of 10.

When I follow the example above I seem to only be copying 1 word into the F8 address not two. This doesn't yeild the proper float.

In CLX this can be done easily by using BTD and shifting both 16 bit words into a DINT and the copying the DINT to a float.

So... in summary I still don't understand you're notes if they are correct. To clarify what I'm after...

N7:0 is the lower 16 bits (0-15)
N7:1 is the upper 16 bits (16-32)

Store them in F8:0

{COP #N7:1 F8:0 1} seems to put N7:1 into F8:0 ignoring N7:0

thanks again.
 
Get a # in front of F8:0, and you may have to swap the values in N7:0 and N7:1 if the value doesn't look right. COP #N7:0 #F8:0 1

Even in the CLX the COP instruction will do this.
 
Last edited:
Also, as a rule, the destination address type determines the length of the copy instruction, so with a destination of a float, the length will be 32 bits times the length (10 in the above example) so 20 integers are being copied into 10 floats.

So, reversing the data types: If you were trying to copy the source bit pattern from 10 floats into a destination of twenty integers, you would set the length to 20, and only ten floats would be copied, since that is enough to satisfy the number of bits required to obtain the length specified in the destination for the COPy instruction.

Hope this helps...
 
Sorry this thread might be all finished up as no one has posted since August but I have recently joined and stumbled across this interesting topic.



Keith your explanation of the 2 instructions is right on the money and is explained extremely well.



I would just like to add a note regarding the transfer of 2 integers into a single floating point with a Micrologix as you stated that the 2 instructions are the same for all AB platforms (SLC, MLogix, CLogix, etc.) but as we all know each platform has their own quirky differences.



In this case the Micrologix (both 1100's and series C 1200 & 1500 anyways as these are the only 2 MLgx processors that can handle actual floating point data) is odd one out in your example of floating point transfer over DeviceNet. As everyone has pointed out the COP instruction moves data bit by bit to the destination but COP in Mlgx does not have the full functionality of the other platforms (SLC & ControlLogix anyways as I'm not sure about PLC5).



The COP instruction in Micrologix will only verify if the length of the source and destination are of the same length. RSL pointed out moving a DINT to SINT using COP instruction for Logix platform (RSLogix5000) and SLC & MLgx's (RSLogix500) equivalent of these data types would be Long (L#:) and Integer and (N#:) respectively.



CPW instruction is required for this functionality in the MLgx platform. This instruction copies blocks of data (bit by bit) from the source to the destination but allows you to select different size source and destination types as it fills the bigger data point before moving to the next. For example, CPW instruction with parameters Source #N7:0, Destination #F8:0, Length 3; will fill N7:0 to the first 16 bits of F8:0, N7:1 to the second 16 and N7:2 to the first 16 of F8:1. This could be rather useless as only half of F8:1 will have relevant data but this shows the functionality of this instruction.



Hope this sheds a little more light onto the differences between MOV and COP instructions and helps out anyone using Micrologix processors requiring a copy with mismatched data type sizes.



Justin.
 
Last edited:
justinvk6 said:
Sorry this thread might be all finished up as no one has posted since August but I have recently joined and stumbled across this interesting topic.



Keith your explanation of the 2 instructions is right on the money and is explained extremely well.



I would just like to add a note regarding the transfer of 2 integers into a single floating point with a Micrologix as you stated that the 2 instructions are the same for all AB platforms (SLC, MLogix, CLogix, etc.) but as we all know each platform has their own quirky differences.



In this case the Micrologix (series C 1200 & 1500 anyways as these are the only 2 MLgx processors that can handle actual floating point data) is odd one out in your example of floating point transfer over DeviceNet. As everyone has pointed out the COP instruction moves data bit by bit to the destination but COP in Mlgx does not have the full functionality of the other platforms (SLC & ControlLogix anyways as I'm not sure about PLC5).



The COP instruction in Micrologix will only verify if the length of the source and destination are of the same length. RSL pointed out moving a DINT to SINT using COP instruction for Logix platform (RSLogix5000) and SLC & MLgx's (RSLogix500) equivalent of these data types would be Long (L#:) and Integer (N#:) respectively.



CPW instruction is required for this functionality in the MLgx platform. This instruction copies blocks of data (bit by bit) from the source to the destination but allows you to select different size source and destination types as it fills the bigger data point before moving to the next. For example, CPW instruction with parameters Source #N7:0, Destination #F8:0, Length 3; will fill N7:0 to the first 16 bits of F8:0, N7:1 to the second 16 and N7:2 to the first 16 of F8:1. This could be rather useless as only half of F8:1 will have relevant data but this shows the functionality of this instruction.



Hope this sheds a little more light onto the differences between MOV and COP instructions and helps out anyone using Micrologix processors requiring a copy with mismatched data type sizes.



Justin.

I might add that ML1100 also supports floating point data.
 
The most handy form of COP I've found is bringing SLC data over into a CL platform. For instance. Each data word from a HSCE card comes across as two SINTs. Then, to make sense of the data coming over, you have to convert it back over to INTs. You do so by using COP as it is moving all 16 (total) bits over. Bit for bit you now have an identical INT as what would have been displayed on the SLC in the first place. Now in this application, there is a total of 42 (or 84, depending on the HSCE firmware version) SINTs. I can do all sorts of fancy indexing logic or I could drudge through one MOV at a time, or I could just COP everything in one rung, one scan. MOV is easily understood as moving one data type. You can move one data type into another data type if its possible. You obviously can't move a DINT into a SINT, but you can move a INT into a Float without any fancy logic to convert an integer to a decimal. COP cannot do this.
 
Clear as mud.

I guess I should have stated RSLOGIX500.

I reckon I have to just use them as I have in the past, nothing that was said made any sense.

I know this is an older thread but I came here with the same confusion between MOV and COP.
I just wanted to say that everyone who answered gave very clear and understandable answers and examples. I would not have had the patience with rsdoran that you guys had.
How rude to ask a question then not even try to understand the answers given and keep saying, "clear as mud. I guess I'll keep using my flawed way of thinking because trying to correct it requires too much effort right now." o_O
 
OK guys along the same line: In a MOV function, how does the data actually get moved? I know this is probably basic but I am still learning. Does it move every scan? Or do I need a system clock bit in the rung? Basically, what I am trying to do is move data from a program tag list to the controller tag list so i can export it to create a tag list for an HMI.
 

Similar Topics

Hi, I would like to move a word to display wind direction. For example: NW, or SE, or ESE in RSLogix 5000, not panelview. I have a wind speed...
Replies
18
Views
5,518
Hi All, This topic it is really interesting indeed. Hi have a doubt that is inside this kind of questions: RSLogix 5k V28, 1756-L73CPU value...
Replies
11
Views
2,582
I've done a few AB projects, but have not seen either of the following in a MOV instruction (I can't figure how to take a "snippet" and insert). I...
Replies
9
Views
3,249
Hello All, New kid on block with AB 5000 platform. Using the MOV ( move ) command. I can't get the logic to shift the value of source to...
Replies
11
Views
7,802
Attached is an image of rung 43 on LAD10 of our digester program. In the MOV instruction at the end of the rung, the source address is something...
Replies
13
Views
3,099
Back
Top Bottom