Confused on COP instruction in Logix 5000

Good morning everyone.

I am apparently confused on the COP instruction. What I am trying to do is copy a DINT to a DINT in a User Defined Data Type.

So I want to copy this DINT to Zone[1].DINT, Zone[2].DINT, Zone[3].DINT, all the way up to Zone[20].DINT
I thought if you made a COP instruction like the following, it would work, but I was wrong.
Source: DINT_Variable
Destination: Zone[1].DINT_Variable
Length: 20

Can someone help me out with my apparent ignorance on this?

TIA,
David

If I understand you want to copy a single DINT to multiple DINT in array
array tag Zone[1] - Zone[20]
if so you are using the wrong function you should be using File Fill i don't have the software up on i would give you label
the copy assumes that you want to copy a DINT array of 20 elements to another Array of 20 elements
the copy can also copy to a different data types DINT to 2 INT
or 2 INT to 1 DINT Real to 2 INT
I hope that helps

The FLL is the label for the instruction Gary mentions. It will copy one value to multiple contiguous destinations (ie..single DINT to DINT array)

However, in re-reading your post, I'm not sure that will work either. It will want to fill contiguous memory locations. But that isn't really what you are after. You want to plug your value into a specific element within an array of UDTs. My first thought is to try the FAL, but I'm not sure that will work either. I think you might need to use indirect addressing and replace the zone number part of your tag name with a pointer.

OG

FAL will do it ...

Thank you to everyone for taking the time to respond. I'll try the FAL instruction and see how it goes.

I want to pose another question along the same lines while I am bugging everyone. What if I wanted to move Zone[1].Dint to Zone[1].Dint1, Zone[2].Dint to Zone[2].Dint1, and so on all the way up to Zone[20].Dint to Zone[20].Dint1.
Can that be approached the same way or would I need to do individual MOV instructions for each one or could I do something like in the attached screenshot?

wilkerson29847 said:

Thank you to everyone for taking the time to respond. I'll try the FAL instruction and see how it goes.

Click to expand...

It will work, as you can see from the picture I posted.

In my example I was copying from a like-minded UDT tag, but it'll work with a single DINT in the expression.

Just make sure your FAL control tag is unique, not used anywhere else, and that you need to make the rung go false-to-true to execute it again.

The FAL will also work for your added problem ....

Here I am moving the stucture's REAL member to the DINT member.

wilkerson29847 said:

Good morning everyone.

I am apparently confused on the COP instruction.

Click to expand...

Please let me attempt to remove your confusions....

What I will describe about COP applies equally well to CPS and FLL.

The in-built instructions like MOV, and the file instructions like FAL, all have the natural ability to automatically change data-types between the source data-type, and the destination data-type. This means that every single element of an array in a FAL instruction will have to be parsed and converted if necessary. All very time-consuming ...

COP, on the other hand, was designed and implemented in the instruction set as a "fast" data copier, and doesn't need the control structure of a FAL. Nor does it do any data-type inspection or conversion.

Instead, the COP instruction calculates the number of bytes it is programmed to copy, by multiplying the number of bytes of the destination data-type, by the length of the copy. So a DINT (4 bytes) array of length 100 would calculate the number of bytes to copy as 400 bytes.

Then the controller would simply byte-copy those 400 bytes from the source, and deposit them in the destination. No data-conversion, no error-checking(*1), just get on with it as fast as you can....

CPS does exactly the same thing, except that it suspends interrupts while it is executing, which might cause the source or destination "data-set" to be changed during the copy. I personally always use CPS, just to be on the safe side.

FLL obviously keeps resetting its source byte-pointer to constrain the bytes being copied to the source size (note there is no FLS like there is a CPS !)

*1 above : The only error-checking that takes place is that COP will stop mid-way if the destination's tag end is reached (EDIT : And there is no way to know this has happened, not even a Minor Fault !). This is protection against overwriting other data memory if the instruction is badly configured. HOWEVER !!!! If the destination is a member of a structured tag (UDT), and it is not at the end of that tag, an incorrectly configured COP, CPS, or FLL can trample over the data areas for following members. They only check for the end of the entire destination tag.

So in your case COP or CPS would have been inappropriate, as you would not be addressing contiguous memory, and as I have shown you have to use FAL

Hope that hasn't confused you more ....

daba said:

*1 above : The only error-checking that takes place is that COP will stop mid-way if the destination's tag end is reached (EDIT : And there is no way to know this has happened, not even a Minor Fault !). This is protection against overwriting other data memory if the instruction is badly configured.

Click to expand...

Correct me if I'm wrong, but wasn't that feature only added in a relatively recent firmware/hardware update? I've got painful memories of sporadically-changing data with no apparent cause until I stumbled upon a completely unrelated, incorrect-length COP instruction. This was back in v20 with an L35E, and I seem to remember reading about this new "save you from yourself" feature in either the firmware release notes for a new version, or the migration guide from 5370/5570 processors to 5380/5580 processors.

ASF said:

Correct me if I'm wrong, but wasn't that feature only added in a relatively recent firmware/hardware update? I've got painful memories of sporadically-changing data with no apparent cause until I stumbled upon a completely unrelated, incorrect-length COP instruction. This was back in v20 with an L35E, and I seem to remember reading about this new "save you from yourself" feature in either the firmware release notes for a new version, or the migration guide from 5370/5570 processors to 5380/5580 processors.

Click to expand...

I don't believe so, I think it was as it is now from day one. Certainly not "relatively recent" anyway.

But what "feature" are you referring to ? The cessation of the instruction at a tag boundary, or the overrun into later members of a structured tag ?

Perhaps they updated them so that the COP would give up at a structure member boundary, rather than the whole tag boundary. Or perhaps the compilation of the rung would fail if what was being programmed wasn't acceptable, in other words is it possible to configure the instruction to misbehave ?

I've got all versions back to 10 installed so I could run tests as I have an aged L1 to run the earlier revisions on. Just got to work out the best way to test for it.

But you'll have to wait for results, it is v.late here, and I will be horizontal in a while ....

If you can find that documentation you mentioned I wouldn't mind a read of that .....

This is from the Help on COP for V13 ....

Rockwell Automation COP Instruction Help said:

The COP and CPS instructions operate on contiguous data memory and perform a straight byte-to-byte memory copy, which requires an understanding of the controller’s memory layout.
The COP and CPS instructions do not write past the end of the array. If the length is greater than the total number of elements in the Destination array, the COP and CPS instructions stop at the end of the array. No major fault is generated.

Click to expand...

And this from V20 ....

Rockwell Automation COP Instruction Help said:

The COP and CPS instructions operate on contiguous memory and perform a straight byte-to-byte memory copy.
In some cases, they write past the array into other members of the tag. This happens if the length is too big and the tag is a user-defined data type.
If the tag is:
Then:
a user-defined data type
If the Length is too big, the instruction writes past the end of the array into other members of the tag. It stops at the end of the tag. No major fault is generated.
NOT a user-defined data type
If the Length is too big, the instruction stops at the end of the array. No major fault is generated.
The length is too big if it is more than the total number of elements in the Destination array.

Click to expand...

It appears that they just updated the Help text to reflect what really happens !!

Found it - had it slightly backward.

The "save you from yourself" was related to copying junk data in to your array by specifying more bytes than the source had available. The new 5580/5380 processors will now stop at the end of the source tag, as well as the end of the destination tag.

Refer page 145 of Replacement Guidelines: Logix 5000 Controllers

Yeah I've just pulled up the Help from V28, and although it has been re-worded and "polished", it still says the same thing ...

Rockwell Automation COP Instruction Help said:

The COP and CPS instruction operates on contiguous memory and performs a straight byte-to-byte memory copy.
Byte count equals the smaller of:

• Requested amount equals Length x (the number of bytes in a destination element)
• The number of bytes in the destination tag
• ForCompactLogix 5380, CompactLogix 5480, and ControlLogix 5580 controllers: the number of bytes in the source tag Tip:
  The end of the destination or source tag is defined as the last byte of the base tag. If the tag is a structure, the end of the tag is the last byte of the last element of the structure. This means the COP and CPS instruction could write past the end of a member array but will never write past the end of the base tag.

Important:
You must test and confirm that the instruction does not change data that you don’t want it to change.

Click to expand...

Doesn't matter how much you polish 5h1t, it is still 5hit !

I'm glad you found it - I was not looking forward to doing all that testing !!!

My post #8 still stands then....

Like I said, the instructions were built for speed, so only rudimentary error checking was employed ....