RS 5000: COP (Length of 1) vs MOV

I have found several places in an old program where COP of length 1 is used on strings, but other places where MOV is used. Is there an different in efficiency?

I don't see the exact numbers for string tags, but with INT/DINT type tags the MOV executes significantly faster than a COP. But, the COP is still pretty fast so I don't know that I would go and start replacing them. It's unfortunate that the programmer(s) wasn't consistent.

OG

In all cases the COP copied from one string to another? Or are there cases where the COP is from a string to a DINT array or vice versa?

I don't do much string manipulation but I wonder if there was a time when you couldn't use a MOV with the sting data type in the Logix world. This might be a case where you are seeing a mix of legacy methods with methods that became valid later.

The execution time difference really surprises me. It is a HUGE difference. I would have thought a COP would be faster than an equivalent MOV since the COP is a simply byte for byte memory copy and the MOV provides type conversion. Maybe it's the fact that a COP can operate at the byte level, requiring masking at every operation. Also, there must be a little hanky-panky going on under the hood with MOVs between similar data types so the interpreter doesn't perform type checking and conversion. If it needed to perform those two functions (MOV a DINT to a REAL) I would think things would get slower.

Keith

Not that I have found, they are all STRING to STRING.

MOV with numeric data behaves as expected with same type tags. With different type tags it interprets the source to fit the destination type. COP does not do any interpretation and copies the bit patterns literally. One such usage is to COPy two adjacent integers into a float. This is usually done with information received depending on communication protocols. COPy can also transfer UDT tags as complete units. One example is a string to string transfer.

It is the extra "feature" of the MOV (type-checking and conversion) that I would expect to cause longer execution time. But it doesn't...by a significant multiple. Seems odd.

Keith

bernie_carlton said:

MOV with numeric data behaves as expected with same type tags. With different type tags it interprets the source to fit the destination type. COP does not do any interpretation and copies the bit patterns literally. One such usage is to COPy two adjacent integers into a float. This is usually done with information received depending on communication protocols. COPy can also transfer UDT tags as complete units. One example is a string to string transfer.

Click to expand...

kamenges said:

It is the extra "feature" of the MOV (type-checking and conversion) that I would expect to cause longer execution time. But it doesn't...by a significant multiple. Seems odd.

Keith

Click to expand...

Yes there has to be some kind of underlying optimization going on there. It is truly counter intuitive.

My understanding is that the source data (contents) can change during the MOV, instruction.
A COP ensures the source data is frozen in time, until all of the "data" has been copied over.

Once in a blue moon, the timing of the data being received, can cause issues.

Super Koop said:

My understanding is that the source data (contents) can change during the MOV, instruction.
A COP ensures the source data is frozen in time, until all of the "data" has been copied over.

Once in a blue moon, the timing of the data being received, can cause issues.

Click to expand...

I’m unsure and just looking for clarification, but isn’t that the CPS instruction?

It’s my understanding that a MOV will convert data types and copies strictly are bit level transfers.

Super Koop said:

My understanding is that the source data (contents) can change during the MOV, instruction.
A COP ensures the source data is frozen in time, until all of the "data" has been copied over.

Once in a blue moon, the timing of the data being received, can cause issues.

Click to expand...

hmmmm that is possible that a mov is not atomic. COP placing a lock on the source would indeed add to execution time. Do you have a source that explains it further?


EIA: Well maybe it is CPS
http://www.plctalk.net/qanda/showthread.php?t=113436

It’s my understanding is the MOV moves the source tag bit pattern to the destination tag leaving the source tag unchanged. Which makes sense if you look at the MMOV (Masked Move). The MMOV moves only the bits selected by the mask are copied from the source tag to the destination tag. While leaving the source tag unchanged.
You could move an INT tag to a DINT tag but only the lower 16 bit will be moved
Both work with only 1 word per function and they sould be the same data type

The COPY copies the value of the source tag to the destination tag. Leaving the source tag unchanged The value is defined by the IEEE standard not necessarily the bits. The value is not always the bit pttern.
But it has even greater power.
It can copy multiple words in an array set by the length property
It can also copy a Real or Float data type to 2 consecutive words in an INT or DINT array tag. (Length = 2)
Or it can also copy 2 consecutive words in an INT or DINT array tag to a Real tag. (Length = 1)
Be careful here because it will grab the next consecutive INT word of the array tag and copy it to the Real tag as the value to the right of the decimal point and end up giving you some strange data values.
The length always refers to the length or number of consecutive words of the destination tag.
So it gives you a lot of flexibility for simple data type conversions.
It can also copy an array tag or part of an array tag to another array tag of the same type or a different data type. An array of Real data types to an array of INT’s of 10 Real’s from an array to an INT array tag the length would be 20. The one drawback it has is it always starts with an index of 0 and copies the number of destination words up to the length.
It can also be used to copy UDT s or arrays of UDT’s in the program.

The SCOPY ( Synchronous Copy ) works the same as the copy but it prevents the source tag from changing while the SCOPY function is copying the data. While there is no benefit to using it to copy from one tag to another within the normal program ( The data in the memory can’t change while the copy is working ) is should be use to copy Input data from the IO to a tag. Because in the Logix processors the IO is updated Asynchronously to program sans so it is possible for an Input module to update and change the data while the copy function is working, so after the copy is complete the data in tag will not have the correct data unless the source (Input) is locked during the copy process.
The SCOPY will take a little longer to execute then the COPY.
I hope this helps to understand it.

Or used while copying data between tasks right? Can't tasks interrupt each other mid execution?

I think I remember in older software COP was not allowed for some Radix's.
But it was allowed on other releases.