Controllogix Copy or Move Size

I am trying to Copy 50 DINT to 100 INT. Another engineer said it should be a move.
Will a Move handle DINT to INT? (The DINT numbers are all within INT range.) I believe only a Copy will.
If the data also needs to stay in its original location, it SHOULD be a Copy and not a Move....right?
Or should it be a FAL?

Also can this size of tags be handled on a one shot?

You are correct, 1 copy will solve this problem as long as the 2 tags are arrays.

And both copy and move instructions leave the original data in tact.

dmroeder said:

You are correct, 1 copy will solve this problem as long as the 2 tags are arrays.

And both copy and move instructions leave the original data in tact.

Click to expand...

Not to act too ignorant.....but if a Copy and a Move leave Data intact, then what is the difference between the 2?

Also can this size of a Copy be handled on a 1 shot? How big of a Copy be handled on a 1 shot? I have another Copy that is moving 400 DINT to 800 INT.
And...will a Move take care of DINT to INT?

It wasn't stated if the DINT values are all positive. If so then the COP will leave a value of zero in every other INT. If some of the DINT values are negative then the results may not be what is expected.

Let's say you have DINT values of 1, 2, 3, 4, 5

What would you expect/want in the first 10 INT locations?

COP is a byte-by byte copy, nothing else.

Are you trying to get your 50 DINTs into an INT array so that it can be read by something that doesn't read DINTs. If yes, then COP DINT_Array[0] INT_Array[0] 100 will byte-copy the data.

If you use MOVs or a FAL, the DINT tags will be converted into INTs, and you will only get 50 "results", not 100.

The pic shows how the COP copies the bit patterns.

edit: the length of 100 comes about because COP uses the length of the destination elements (not bytes)

More info on what you are trying to do, and why, would be useful...

Copying DINT to INT so that they can be used by antique FIX32 SCADA (FIX32 cannot read DINT)
Yes I want the DINT range to be copied to a larger INT but want data in first location...on this copy.
No negative numbers...all 0-32000 range
Presently using FAL to copy 50 DINT B63[0] (B63 is DINT[400]) to first 100 INT of N67[100] (N67 is INT[800]) and it looks like the DINT numbers are showing up in the first 50 INTs of N67[100], which is okay and expected as I did not want them to show up in every other location.
There are more B63 tags being copied to N67 range but position is higher.
I assume the position of where the B63 tags get written to in the N67 range is why the FAL is needed for positioning.

What is the difference between COP and MOV?

MOV copies one source tag to one destination. There is no length parameter to a MOV instruction.

So then the COP instruction and copy multiple source elements within an array to multiple destinations within another array (or the same array).

Example: So if you have 50 values you want to take from a source array and place them into 50 destinations within a separate array that could be accomplished with one COP. With a MOV, you would need 50 separate MOV instructions or use some sort of variable tag addressing.

OG

NetNathan said:

Copying DINT to INT so that they can be used by antique FIX32 SCADA (FIX32 cannot read DINT)
Yes I want the DINT range to be copied to a larger INT but want data in first location...on this copy.
No negative numbers...all 0-32000 range
Presently using FAL to copy 50 DINT B63[0] (B63 is DINT[400]) to first 100 INT of N67[100] (N67 is INT[800]) and it looks like the DINT numbers are showing up in the first 50 INTs of N67[100], which is okay and expected as I did not want them to show up in every other location.
There are more B63 tags being copied to N67 range but position is higher.
I assume the position of where the B63 tags get written to in the N67 range is why the FAL is needed for positioning.

Click to expand...

The FAL is just a multiple MOV. And MOV will convert the 32-bit DINT source data into the 16-bit INT destination data.

So there are 50 DINT source values starting at B63[0], and the FAL will sequentially convert and store those 50 values into the INT array. This means there are only 50 destination addresses populated, not 100. Since the FAL does perform data conversion, you will get overflow errors if any of the DINT values > 32,767.

Contrast that to the COP instruction, which cares not about the data-types of the source or destination when doing the copy, no data conversion takes place. It simply takes the length you specify, multiplies that by the number of bytes of the destination data-type, and then copies that number of bytes from the source to the destination.

So if you COP your 50 32-bit DINTs to a 16-bit INT array, you will need 100 INTs to receive the bytes.

50 DINTs = 200 bytes
100 INTs = 200 bytes

I would suggest that FAL, as you are using, is the best instruction for the job you described....

The customer originally used COP to move the bits from INT to INT, but the conversion form PLC5 to Controllogix made all the tags DINT (?). So they went to the FAL command.
The customer is moving the Alarm bits from DINT back to INT to send to FIX32.

Now I see why I am sometimes getting an overflow on the FAL. If there are too many alarms, the 1 bits may total over 32,767.
It probably happened to them before but since the COP was not showing an overflow...they probably just lost some alarm bits?

Another FAL question....why not use an XIO on the FAL.DN bit to reset the FAL....like it is done on a timer? In the instruction manual and in the logic a FAL (RES) is used....without an explanation anywhere of the (RES) extension????

Break this down:
1) you want a bit for bit duplication of the data (alarm bits) to show up in INT locations to be read by Fix32.
2) The Conversion utility turned your INTs into Dints.

Just my opinion, but the root of your problem lies in the conversion process, which cannot be expected to "know" your intended usage and, for reasons of efficiency in the Logix5000 platform, will make DINTs the preferred treatment of this type of code.

Why not clean things up and just change those DINTs for INTs, so that you do not have to add a layer of mapping to the code? You are probably having to use SLC/PLC mapping anyway to make them accessible to the Fix32 system... It may not be any more efficiency from the perspective of the PLC, but often it's better to be concerned with the perspective of the reader than to save a few microseconds of CPU time.

IN discussion with the Engineers here, that is already where we are headed is changing all the DINTs to INTs.
And yes all the FIX32 conversation is based on SLC/PLC mapping. Luckily it is pretty well setup because all the tags are based on arrays of bits under the same register...Like N67 is based on an INT[400].

Another FAL question....why not use an XIO on the FAL ControlWord.DN bit to reset the FAL....like it is done on a timer?
In the instruction manual and in the logic a FAL ControlWord.(RES) is used before the FAL....without an explanation anywhere of the (RES) extension????
I assume it is a reset, but why use a RES and not the done bit??
Can a 1 shot control a FAL? Does it complete its operation, even though the rung is no longer true?

What mode are you planning on use. ALL? INC?

All

Then I think the one shot is fine. Not sure why you would need the Reset if you are using ALL. The Reset is just going to reset the [Control.pos] not the function itself. It runs like any other instruction when it receives power flow.