MOV is usually a slower instruction than COP, even though it only works on one single data element.
MOV takes a copy of the source (noting its data-type), and then looks at the destination data-type to determine if data conversion is needed.
If no conversion needed, then MOV just places a copy of the Source element into the Destination element.
If conversion is needed, then the instruction has to do the maths to convert the source data-type to the data-type of the destination.
COP, on the other hand doesn't look at any data-types, it just copies byte-by-byte from the Source to the Destination tags, for the length specified (which incidentally is the length of the Destination tag).
For a length of 1......
If the Destination is a SINT, COP copies 1 bytes from the Source.
If the Destination is an INT, COP copies 2 bytes from the Source.
If the Destination is a DINT, COP copies 4 bytes from the Source.
If the Destination is a UDT, COP copies the destination UDT size in bytes from the Source.
Of course, if the source and destination data-types are mismatched, then COP (and CPS) will corrupt the data, since neither instruction cares about data-types.
If you specify the length incorrectly, i.e. you put 100 instead of 10 for the length parameter, COP will terminate at the end of the current tag, to guard against memory corruption. But be careful, if you are COPying into an array element of a UDT for example, a COP will destroy following elements of the UDT if you have the length set too long (the safety-net is employed at the end of the tag, not the end of any sub-elements within that tag).
Now, back to the MOV instruction, or indeed
any instruction that stores data into a destination, (ADD, SUB, MUL, DIV, CPT, etc. etc.). Bernie was nearly right, but when storing a REAL (floating point) result into an integer-type (SINT, INT, DINT) destination, the actual operation performed is
Rounding.
Don't leave just yet - it gets interesting.
When we apply rounding to a REAL, we generally think it does
xx.0 to xx.4999999 = round down
xx.5 to xx.9999999 = round up
The problem is what to should be done with the exact xx.5 values. It is exactly halfway between xx and xx+1, so to always round these .5 values up creates a statistical imbalance that is not favoured, especially by the banking fraternity.
So, Logix5000 systems (not PLC5, not SLC, just the Logix5000 family) have adopted a new method of rounding, called the "Round-to-Even" method. Any exact xx.5 values are rounded to the nearest even number (zero is considered an even number, sitting as it does between two odd numbers, 1 and -1).
You can see this easily online by setting up a simple MOV instruction from a REAL tag, to a DINT tag. The picture shows what you will get from the {unusual} rounding method. The third column is just an excel rounding function applied to the source, just to highlight the differences. What this means is that any "conversion" of code from PLC5/SLC platforms has to be audited carefully. The converted code can produce different, and sometimes surprising, results !!
