Confirmation of COP Instruction in RSLogix 5000

Hey everyone,

I'm reverse engineering a client's program and I've run across something that I need a sanity check on, involving a COP instruction.

Source Tag (UDDT):
Member 1 = BOOL
Member 2 = BOOL
Member 3 = BOOL
Member 4 = BOOL
Member 5 = BOOL
Member 6 = BOOL
Member 7 = DINT
Member 8 = DINT
Member 9 = BOOL[32]
Member 10 = DINT[8]

Destination Tag:
INT[24]

They have implemented a COP instruction to copy the Source UDDT into all 24 elements of the destination tag.

Here is what I believe is happening:

The COP instruction is copying the source UDDT, bit-by-bit, into the destination tag in this fashion:

Source [BOOL] -> Destination INT[0].0
Source [BOOL] -> Destination INT[0].1
Source [BOOL] -> Destination INT[0].2
Source [BOOL] -> Destination INT[0].3
Source [BOOL] -> Destination INT[0].4
Source [BOOL] -> Destination INT[0].5
Source [DINT] -> Destination INT[0].6 thru INT[2].5
Source [DINT] -> Destination INT[2].6 thru INT[4].5
Source [BOOL[32]] -> Destination INT[4].6 thru INT[6].5
Source [DINT[8]] -> Destination INT[6].6 thru INT[22].5

Do you all agree that this is what is happening?

Thanks for any help you can provide.

can you please post a screen shot of your COP rung? ...

When in doubt, build a sample program and test it out in SoftLogix.

Ron, to answer your query:

COP(Source,Destination[0],24);

Here's how it actually works:

Source [BOOL] -> Destination INT[0].0
Source [BOOL] -> Destination INT[0].1
Source [BOOL] -> Destination INT[0].2
Source [BOOL] -> Destination INT[0].3
Source [BOOL] -> Destination INT[0].4
Source [BOOL] -> Destination INT[0].5
Padded 0's -> Destination INT[0].6 thru INT[1].15
Total: 32 bits

Source [DINT] -> Destination INT[2].0 thru INT[3].15
Total: 32 bits

Source [DINT] -> Destination INT[4].0 thru INT[5].15
Total: 32 bits

Source [BOOL[32]] -> Destination INT[6].0 thru INT[7].15
Total: 32 bits

Source [DINT[8]] -> Destination INT[8].0 thru INT[23].15
Total: 8 groups of 32 bits

This makes sense since RSLogix 5000 works with 32-bits at a time. Those first six booleans in the UDDT may only occupy six bits, but Logix still allocates 32 bits, total. So, you have the 6 booleans, followed by 26 unused bits.

One thing to be wary of when using the COP instructions with UDTs. Once, I upgraded firmware from v13 to v15, and the function of the COP instruction changed from moving 4 SINTs into a DINT UDT element to moving as many SINTs as needed to fill the next 4 UDT elements. My guess was that the "length" of the instruction went from meaning the length of the source to the length of the destination. Or, it could be that the meaning of "length" was changed to include individual UDT elements.

Logix5K will always start a 32-bit UDT element on a byte boundary divisible by 4. That is why you got the bit padding you did. If the first element after the BOOLs was an INT you would have only had bits padded to the end of the intial INT. In addition Logix5K makes sure that a complete UDT has a byte count divisible by 4. So you may have bytes padded at the end of the UDT that you are unaware of.


Keith

Thanks, Keith.

I did a little experiment after I read your message. Here were my results:

If you had the following UDDT:
Thanks for the replies, guys!