MOV vs COP vs CPS for Studio5000

Why not use CPS for everything?

When would you actually want to allow the data to change during the copy operation?

My understanding is:

MOV is moving a VALUE and will do data conversion for you.

COP and CPS, straight bitwise copy the bits over. So, if you do copy of a Flat to an INT, the resulting data in the INT would be gibbish.

The difference between a MOV and a COP instruction is that a MOV looks at the bit pattern and the data type and says "OK, the value in N7:0 is 12345, so I'm going to put value 12345 in F8:0." But because the number 12345 is represented one way by an integer (0011 0000 0011 1001) and a different way by a float (0100 0110 0100 0000 1110 0100 0000 0000), the MOV instruction has to do some conversions to make both N7:0 and F8:0 have the same numerical value.

The COP instruction on the other hand, just copies the bit pattern exactly. So your Hart device has a 32 bit floating point value of say 12345 (binary 0100 0110 0100 0000 1110 0100 0000 0000). It breaks it into two 16 bit chunks: 0100 0110 0100 0000 and 1110 0100 0000 0000. It transmits them back to the PLC as 16 bit integers, which if viewed directly will be 17984 and -25600. These are completely meaningless as far as the "12345" value you want to measure, so your PLC has to reassemble the two integers into a floating point data without modifying the bit structure. If you COPy these two integers back into a float, you'll have exactly the same bit structure as the original floating point value in your HART instrument - 12345.

The only other thing to be aware of with how that works is that the COP length parameter is in terms of destination elements. So if it's set to COPy N16:15 to F8:13 with a length of 1, that's a length of one 32-bit float. So it'll grab two 16 bit integers (N16:15 and N16:16 and pack them into F8:13 as described above)

Hope that helps

Regarding COP vs. CPS, the online help explanation is a little vague with the phrase "allow the data to change during the copy operation" in that it only applies to situations where a COP instruction could be interrupted by a task or external operation that changes the data being copied. This would not include processor-local data that is not shared between tasks, thus implying "None of the above" in the selection criteria.

There would be additional overhead with CPS, along with potential impact to scheduling other tasks. As indicated in the help file there are documented guidelines: "To estimate the execution time of the CPS instruction, refer to the ControlLogix System User Manual, publication 1756-UM001."

If you have time-critical aspects to the application, it may be advantageous to use COP instead of CPS when CPS is not required.

The COP an COPS are very powerful functions and can do many things. Check the help menu or techconnect documents.
COP and COPS copy the data from one element to another element of the same type.
They can also convert data from one type to another.
2 Int data type to real data type, 2 int’s to a dint data type. There are other conversions as well.
When a cop instruction is executed on an array of data it will make the copy 1 element at a time until complete. For an array or 100 elements it will copy each element one at a time until it function is complete (100 separate copy commands)
If you are copying data from an input, while the copy is doing its thing the input data may actually change before it completes the copy. To prevent the data from changing use the COPS function.
The COPS locks the data in copy elements (inputs) form changing while the copy completes.
The COPS should only be used to copy data from an input. As it takes more processing time to execute and gains you nothing when copying tag to tag. In a tag to tag copy the ladder execution is held up until the copy is completes.
The COP can only copy a tag to a tag it cannot copy a fixed value (12345) to a tag for that use a MOV
The move I believe is a holdover from the old days when they didn’t have the copy function.
It will move the data value from a single element to another single element of the same type ( Bit for Bit move). Where it is helpful is when you want to move a fixed constant value to a tag. Ect. 0 or to move a preset to counter or timer back to default settings. This data cannot be changed unless you are on line programming .
I rarely use a move value as I like to use move a tag so I can change the value without editing the program. I use it to clear a tag or set the value to 0

CPS is much more processor intensive than COP. This technote (techconnect login required) has a word document attached that goes into some detail as to the steps the processor takes for the two different instructions. A quick quote which summarises its main thrust:

When compared to the COP instruction which only performs step 4, you can see there is a tremendous amount of overhead for the CPS instruction. Because of this it should only be used when dealing with I/O and Produce/Consume data.

Click to expand...

The question you have to ask yourself is:

"is the data I'm copying capable of changing during the copy operation?"

With a Logix controller, the I/O scan (both physical I/O and ethernet devices) is asynchronous to the program scan - that is, the I/O image can update at any time, no matter what is happening in the ladder logic. If you've got a bunch of data coming in from a produced/consumed tag, and you want to copy parts of it into an internal UDT, there's a chance that the consumed data may be updated partway through that copy, which could make the data you end up copying nonsensical. So in this case, you would use the CPS, which will lock down the controller and all it's communication activities until it's done with the copy.

But let's say you now want to copy the data from that UDT into an array of DINT's. That UDT is not an I/O device - the only thing that can modify that data is your ladder logic. So there's no possibility that it could change mid-copy, and therefore there is no need to use the CPS to protect it from corruption.

When you have a look at that word document and see all the things that are inhibited while the CPS instruction is going on, you can see why it's not really a good idea to use the CPS "just because". It would be a bit like driving on the freeway with snow chains on, "just in case" you run across some snow. You'd massively reduce the performance of your vehicle for absolutely no gain, and the likelihood of actually running into snow is marginal at best. For sure, keep your snow chains (and your CPS) in the boot (or the trunk, for you people across the pond), because when you need them, you absolutely need them - but it would be just plain silly to drive around with them on all the time.

Technically MOV is for transferring numeric data from one register to another; COP/CPS is for transferring a block of data from a set of registers to another.

What other people are describing, how MOV does the data format translation, is a particularly nice feature of the AB world. I don't need a separate INT2DINT, INT2REAL, DINT2REAL, etc., command for each combination of data type transfers like in other PLC brands; MOV handles that under the hood.

COP is needed when dealing with anything bigger than a INT, DINT or REAL. Down under the hood, the PLC can really only still move one data point (either 16 bit or 32 bit, depending on the processor) at a time. The COP instruction manages the transfer essentially by an internal FOR-NEXT loop, with is why it (unlike MOV) asks for a Length. The older PLCs (PLC5/SLC) used to expose that register, S:24, to the user, for better or worse.

It'd be too much (too slow) to ask the COP to also a data conversion, so the raw bit pattern is simply translated to the destination register. This allows for all sorts of "creative" programming, because the COP doesn't error-check the source & destination files to see if they match. Thus, one can do as suggested, and "package" REAL data type data into INT registers, and vice versa.

One can also COP one string to another (as a single string is an array of DINTs, starting with a LEN, and then having two-character DATA[] words. You can also COP UDTs, or even parts of UDTs or dissimilar UDTs -- with all the appropriate caveats and warnings.

Because of the "slowness" of the COP in executing it's FOR-NEXT loop, and because I/O communication is asynchronous to logic scan, the CPS was invented so that, in the off-off chance that a source register array were to change midway through the loop, the resulting destination array does NOT contained some "old" data and some "new", which could, theoretically I suppose (but am hard-pressed to invent an example) cause a problem.

I hate to have to jump back in here but we all need to understand the all data or commands in a computer are bits weather the type is INT or String in the computer it is still just bits "1" or 0" nothing else exists.
the copy copies the value of the tag yes it will be bit's
the MOV move the bits no matter the data type it copies the tag bit for bit that's what a MMOV ( Masked move ) will only move the selected bits not a copy or value of the tag.
a copy cannot copy selected bits from a tag it all or nothing. by moving the bits to a different data type the default would be the same as a convert to a different data type but you are only coping part of the tag ( just the BIT's ) not the value
while the value will be in bit's and the bits will be displayed as a value or even a string if you want. MOV works with the bits and copy works with the value. if you want to convert from one type to another use the COP it will give you better results.

thanks ARDWIZZ it the best explanation I just took it for granted that in a copy you are doing a For Next Loop within the function.
one thing a string data type is SINT type ASCII 8 bit words and len as SINT type.

as for why use the COPS as you said the data in the input table can change wile the copy is running if the data changed while you are using it in the ladder you could have unexpected results so to stabilize the data use the COPS

GaryS said:

The COP an COPS are very powerful functions and can do many things. Check the help menu or techconnect documents.
COP and COPS copy the data from one element to another element of the same type.
They can also convert data from one type to another.
2 Int data type to real data type, 2 int’s to a dint data type. There are other conversions as well.
When a cop instruction is executed on an array of data it will make the copy 1 element at a time until complete. For an array or 100 elements it will copy each element one at a time until it function is complete (100 separate copy commands)
If you are copying data from an input, while the copy is doing its thing the input data may actually change before it completes the copy. To prevent the data from changing use the COPS function.
The COPS locks the data in copy elements (inputs) form changing while the copy completes.
The COPS should only be used to copy data from an input. As it takes more processing time to execute and gains you nothing when copying tag to tag. In a tag to tag copy the ladder execution is held up until the copy is completes.
The COP can only copy a tag to a tag it cannot copy a fixed value (12345) to a tag for that use a MOV
The move I believe is a holdover from the old days when they didn’t have the copy function.
It will move the data value from a single element to another single element of the same type ( Bit for Bit move). Where it is helpful is when you want to move a fixed constant value to a tag. Ect. 0 or to move a preset to counter or timer back to default settings. This data cannot be changed unless you are on line programming .
I rarely use a move value as I like to use move a tag so I can change the value without editing the program. I use it to clear a tag or set the value to 0

Click to expand...

I have highlighted in red where you are incorrect or misleading.

"COP and COPS copy the data from one element to another element of the same type." COP and CPS (not COPS), are simply data byte copiers and care nothing about the source or destination data-types.

They can also convert data from one type to another. No they can't, no conversion is even attempted, they are simply data byte copy instructions, and care nothing about the source or destination data-types. COP or CPS will nearly always cause problems when source and destination data-types are different. Sometimes this can be an advantage... for example you can pass REAL data in an existing DINT array being messaged or produced to another controller. COP (CPS) will maintain the bit pattern, and the receiving controller can COP (CPS) it back to a REAL tag.

2 Int data type to real data type, 2 int’s to a dint data type. Simple nonsense, it doesn't work like that, see the above comment

There are other conversions as well. No conversion is even attempted - byte for byte copiers.

The COPS should only be used to copy data from an input. Nonsense, you use CPS in preference to COP when the source data could be compromised by any external influence, such as asynchronous I/O updates, external message writes, HMI or SCADA data writes, etc.

It will move the data value from a single element to another single element of the same type. "Type" doesn't come into the equation, COP and CPS are just plain and straightforward data byte copiers, and if you want to copy single elements, a MOV would be easier for everyone else to understand. The only thing about that statement that makes sense is that COP may be faster than a MOV, since the processor doesn't have to inspect the data-type of the destination to decide whether conversion is necessary.

I can elaborate on anything you don't understand, just ask

you cane believe that if you want but I had a very extensive conversation with AB techconnect on this subject.
And they recommend we use the cop function over the move function it's a better function to use even with a length of 1 still a better call.
move copies the bit pattern and by default the value. The copy function is much more powerful then the move.

GaryS said:

you cane believe that if you want but I had a very extensive conversation with AB techconnect on this subject.
And they recommend we use the cop function over the move function it's a better function to use even with a length of 1 still a better call.
move copies the bit pattern and by default the value. The copy function is much more powerful then the move.

Click to expand...

The COP instruction executes faster than the MOV instruction (assuming a one-tag-to-one-tag copy) because, as daba says, it literally copies a bit pattern from one tag to another. Nothing else.

A MOV instruction copies a value from one tag to another. If the tags are different data types, the MOV instruction will have to convert the source tag's bit pattern into a different bit pattern to ensure that the destination tag has the same value (but a different bit pattern).

So, you could argue that COP is "better" than MOV in the event that your source and destination are the same data type and processing time is a key concern in your application. Outside of that exact situation, the statement is incorrect. More powerful? Sure, but more powerful only translates to "better" if it's more powerful at doing the thing you need it to do. A drag racer is pretty powerful, but rubbish at manouvering into supermarket carparks.

MOV does not copy the bit pattern. If the source and destination are the same data type, then the end result will be the same bit pattern, but that's not how the MOV instruction operates, and if your source and destination are different data types, that statement is completely incorrect.

Daba is correct in all his statements above.

I've attached a screenshot from RSEmulate showing what happens when you use COP and MOV correctly and incorrectly. On the first rung, I use MOV instructions to transfer DINT>DINT, REAL>DINT, DINT>REAL and REAL>REAL. On the second rung, I perform the same transfers using the COP instruction. The third rung just MOV's each destination value into itself so that we can see the results of the COP instruction above.

All the source tags have the value "123", but as you can see, that's not always what you get in the destination.

Both instructions have different purposes. Some applications you can use either, some applications you can only use COP, some applications you can only use MOV.

GaryS said:

you cane believe that if you want but I had a very extensive conversation with AB techconnect on this subject.
And they recommend we use the cop function over the move function it's a better function to use even with a length of 1 still a better call.
move copies the bit pattern and by default the value. The copy function is much more powerful then the move.

Click to expand...

If you don't believe the man, try it for yourself. Try a MOV myFloat myDINT and compare the results to COP myFloat myDINT.

Every point of Daba's was correct. Your assertion about "more powerful" is debatable. If by power, you mean the ability to move more data at a faster rate, then you are indeed correct. If you mean able to unintentionally overwrite registers adjacent to the destination causing havoc on a machine, then you would also be correct. Or, if by powerful you mean more capable of confusing a technician at 3am, then you could potentially be correct as well.
I understand what your tech connect rep was getting at about speed and efficiency of the COP vs MOV instruction. But on a modern (read 1756-L7X or newer) processor, even in an extremely large program, the total potential scantime savings to be had by obfuscating a working program by rewriting all the MOVs and COPs would be on the order of single-digit milliseconds. What does that buy you on 99.9% of real-world processes?
I'm sorry, but making a blanket statement like "COP is better than MOV" with no supporting evidence to back it up other than "AB said so" is just plain silly.

GaryS said:

you cane believe that if you want but I had a very extensive conversation with AB techconnect on this subject.
And they recommend we use the cop function over the move function it's a better function to use even with a length of 1 still a better call.
move copies the bit pattern and by default the value. The copy function is much more powerful then the move.

Click to expand...

Sorry, you are simply wrong. MOV does NOT copy the bit pattern. Only the COP / CPS instructions do.

As far as a conversation with some techconnect flunky, take that with a grain of salt. They aren't exactly the brightest pins in the drawer.

GaryS said:

you cane believe that if you want but I had a very extensive conversation with AB techconnect on this subject.
And they recommend we use the cop function over the move function it's a better function to use even with a length of 1 still a better call.
move copies the bit pattern and by default the value. The copy function is much more powerful then the move.

Click to expand...

You perhaps don't recall the conversation correctly.

MOV is an instruction that copies the data from the source to the destination. In doing so, it inspects the data-type of the destination and will perform any data conversion necessary to put the source data into the destination tag. Whether data conversion is necessary or not, the MOV does not copy the "bit pattern". It is capable of modifying the "bit pattern" to satisfy the destination data-type.

COP (or CPS), in contrast, does not even look at the data-types of either of the source tag or array, or the destination tag or array. Therefore the COP (or CPS) are much less powerful than MOV.

However, MOV can only copy one tag's element, whereas a COP (or CPS) can copy many. Only in that respect can you say COP (or CPS) is "more powerful". But remember that the COP (or CPS) are simply fast byte copy instructions.

I don't think you can compare the instructions in terms of their "powerful" attribute. They do different things, and you use whichever is correct for your application.

EDIT : I responded to the post without reading the rest of the thread....