Fire Repair Problems

You can use dissimilar source and destination data types in a COP in either of those processors. Just remember that the length is in terms of destination data type elements.

Without knowing more about your recipe structure it is a little hard to tell you exactly how to structure that in the SLC. However, in a generic sense, you will be using indirect addressing to access one or more data files containing the recipe data. Whether it can be done in one file or not has alot to do with how many different data types make up the recipe.

Keith
 
You can use dissimilar source and destination data types in a COP in either of those processors. Just remember that the length is in terms of destination data type elements.

Without knowing more about your recipe structure it is a little hard to tell you exactly how to structure that in the SLC. However, in a generic sense, you will be using indirect addressing to access one or more data files containing the recipe data. Whether it can be done in one file or not has alot to do with how many different data types make up the recipe.

Keith

So the COP instruction can work differently depending on what processor you are using such as a micrologix vs a SLC?

On the recipe there are only 4 integers that change from recipe to recipe.
 
In a SLC, you use the COP with the understanding that the destination data type determines the length. If the destination is a Float, the length is hased on the size of a float. A length of 10 wold be 10 floats, or 10 times 32 bits. So if the source is INT, it would be twice as many INTs to get all 320 bits copied. This is not the case with the CPW at least in my experience with a ML1400.

If you try to COP N7:0 to F8:0 in a ML1200, you will get an error stating that the operand sizes do not match. You can do it with the CPW however, but I found that the Length is based on the source element size, not the destination.

Bottom line is to examine the CPW instructions in the old PLC and make sure your new logic does what you intend, then test it to make doubly sure.
 
COP v CPW - What's the Word?

Tim Ganz said:
...Does the COP instruction work the same way the CPW does?...

...the COP instruction can work differently depending on what processor you are using such as a micrologix vs a SLC?...

...What will be the gotcha to look for when converting the CPW logic to COP?...

...using the CPW to copy Integers to floats and floats to integers...

While they are quite similar in what they are designed to do, the Copy Word (CPW) and Copy File (COP) instructions do not work in quite the same way.

All MicroLogix controllers, 1100 and above, support both the COP and CPW instructions.

While the MicroLogix controllers support the COP instruction it can only be used for copying between similar data types. It cannot copy between dissimilar data types. The CPW instruction must be used when copying dissimilar data types.

All SLC controllers, 5/02 or above, support the COP instruction but not the CPW instruction.

In the SLC controllers the COP instruction can copy between dissimilar data types. So there is no real need for the CPW instruction with regard to copying dissimilar data types.

For both platforms the COP instruction Length operand determines the number of elements to be copied using the Destination data type...

Example: SLC (COP using different data types)

COP
Source: #N7:0
Dest: #F8:0
Length: 1

Here the Length is 1 x the Destination data type, which is a Float.

F8:0 = 1 x 32-bit Float

Or, in terms of the Source data type...

F8:0 = 2 x 16-bit Integers

The COP instruction will need to copy 2 x 16-bit Integers deep into the N7 Data File. So both N7:0 and N7:1 will be copied in a raw bit-wise fashion into the 32-bit Float address F8:0 to satisfy the Length of 1 x Float.

When the 2 x 16-bit Integers are copied to the 1 x 32-bit Float the resultant value may not be as intended. Because the Float data type's binary representation is not available in RSLogix 500 it is difficult to diagnose and spot what may have happened here.

When the SLC COP instruction is copying from a smaller data type to a larger data type, such as Integers to a Float, it will copy the first Source address Integer to the High Word of the Float and the second Source address Integer to the Low Word of the Float.

Example: SLC (COP using different data types)

N7:0 = 1
N7:1 = 2
F8:0 = 0.0

COP
Source: #N7:0
Dest: #F8:0
Length: 1

Result: F8:0 = 9.18383e-41

The 32-bit binary representation, which is not viewable in RSLogix 500, is...

F8:0 = bit 31> 00000000000000010000000000000010 <bit 0

Where...

N7:0 = 1 = 0000000000000001 <High Word
N7:1 = 2 = 0000000000000010 <Low Word

So it's important to note that the SLC COP instruction will swap the Word Order when copying between Integers and Floats.

Why is it so important?...

Because the CPW instruction in the MicroLogix controllers does the opposite...

Example: MicroLogix (CPW using different data types)

N7:0 = 1
N7:1 = 2
F8:0 = 0.0

CPW
Source: #N7:0
Dest: #F8:0
Length: 2

NOTE: The Length is equal to 2 here because the CPW instruction Length operand determines the number of elements to be copied using the Source data type.

Result: F8:0 = 1.836724e-40

The 32-bit binary representation is...

F8:0 = bit 31> 00000000000000100000000000000001 <bit 0

Where...

N7:0 = 1 = 0000000000000001 <Low Word
N7:1 = 2 = 0000000000000010 <High Word

So, for your conversion, when going between Integer and Float data types, the MicroLogix CPW instructions would not have been swapping the Word Order whereas the SLC COP instructions will, giving you totally different values than expected.

The difference between the Length operand and the way the Word Order is handled are the two main gotchas to watch out for when converting between these two instructions.

In the SLC, you could swap the order the data is written into the Integers, if possible. But this is not always possible when the data is coming in from an external source in a particular order of which you cannot manipulate. Failing that, you would have to swap the integer values around before using the COP instruction. MOV instructions would suffice here.

Note: With regard to not swapping the Word Order, the COP instruction on the Logix 5000 platform behaves in the same way as the CPW instruction on the MicroLogix platform. So similarly, when converting from SLC COP instructions to Logix 5000 COP instructions, the above also applies.

Regards,
George
 
While they are quite similar in what they are designed to do, the Copy Word (CPW) and Copy File (COP) instructions do not work in quite the same way.

All MicroLogix controllers, 1100 and above, support both the COP and CPW instructions.

While the MicroLogix controllers support the COP instruction it can only be used for copying between similar data types. It cannot copy between dissimilar data types. The CPW instruction must be used when copying dissimilar data types.

All SLC controllers, 5/02 or above, support the COP instruction but not the CPW instruction.

In the SLC controllers the COP instruction can copy between dissimilar data types. So there is no real need for the CPW instruction with regard to copying dissimilar data types.

For both platforms the COP instruction Length operand determines the number of elements to be copied using the Destination data type...

Example: SLC (COP using different data types)

COP
Source: #N7:0
Dest: #F8:0
Length: 1

Here the Length is 1 x the Destination data type, which is a Float.

F8:0 = 1 x 32-bit Float

Or, in terms of the Source data type...

F8:0 = 2 x 16-bit Integers

The COP instruction will need to copy 2 x 16-bit Integers deep into the N7 Data File. So both N7:0 and N7:1 will be copied in a raw bit-wise fashion into the 32-bit Float address F8:0 to satisfy the Length of 1 x Float.

When the 2 x 16-bit Integers are copied to the 1 x 32-bit Float the resultant value may not be as intended. Because the Float data type's binary representation is not available in RSLogix 500 it is difficult to diagnose and spot what may have happened here.

When the SLC COP instruction is copying from a smaller data type to a larger data type, such as Integers to a Float, it will copy the first Source address Integer to the High Word of the Float and the second Source address Integer to the Low Word of the Float.

Example: SLC (COP using different data types)

N7:0 = 1
N7:1 = 2
F8:0 = 0.0

COP
Source: #N7:0
Dest: #F8:0
Length: 1

Result: F8:0 = 9.18383e-41

The 32-bit binary representation, which is not viewable in RSLogix 500, is...

F8:0 = bit 31> 00000000000000010000000000000010 <bit 0

Where...

N7:0 = 1 = 0000000000000001 <High Word
N7:1 = 2 = 0000000000000010 <Low Word

So it's important to note that the SLC COP instruction will swap the Word Order when copying between Integers and Floats.

Why is it so important?...

Because the CPW instruction in the MicroLogix controllers does the opposite...

Example: MicroLogix (CPW using different data types)

N7:0 = 1
N7:1 = 2
F8:0 = 0.0

CPW
Source: #N7:0
Dest: #F8:0
Length: 2

NOTE: The Length is equal to 2 here because the CPW instruction Length operand determines the number of elements to be copied using the Source data type.

Result: F8:0 = 1.836724e-40

The 32-bit binary representation is...

F8:0 = bit 31> 00000000000000100000000000000001 <bit 0

Where...

N7:0 = 1 = 0000000000000001 <Low Word
N7:1 = 2 = 0000000000000010 <High Word

So, for your conversion, when going between Integer and Float data types, the MicroLogix CPW instructions would not have been swapping the Word Order whereas the SLC COP instructions will, giving you totally different values than expected.

The difference between the Length operand and the way the Word Order is handled are the two main gotchas to watch out for when converting between these two instructions.

In the SLC, you could swap the order the data is written into the Integers, if possible. But this is not always possible when the data is coming in from an external source in a particular order of which you cannot manipulate. Failing that, you would have to swap the integer values around before using the COP instruction. MOV instructions would suffice here.

Note: With regard to not swapping the Word Order, the COP instruction on the Logix 5000 platform behaves in the same way as the CPW instruction on the MicroLogix platform. So similarly, when converting from SLC COP instructions to Logix 5000 COP instructions, the above also applies.

Regards,
George

George thanks for the clarity on that. How would be the best way to handle swapping the word order with a MOV instruction before doing the COP?

Do you have an example maybe. I am in advanced waters now as this is my first time on much of this.
 
I'm only on my phone now so I can't throw a nice screenshot up for you but what I'm suggesting is quite simple...

N7:0 = 1
N7:1 = 2

MOV N7:1 > N7:2 (temporary holder)

MOV N7:0 > N7:1

MOV N7:2 > N7:0

N7:0 = 2
N7:1 = 1

You can use three parallel branches on the one rung. I just hope you haven't too many to do?

Perhaps if you threw up a couple of examples of what needs converting we could double-check what I'm saying actually applies to your situation.

Regards,
George
 
I'm only on my phone now so I can't throw a nice screenshot up for you but what I'm suggesting is quite simple...

N7:0 = 1
N7:1 = 2

MOV N7:1 > N7:2 (temporary holder)

MOV N7:0 > N7:1

MOV N7:2 > N7:0

N7:0 = 2
N7:1 = 1

You can use three parallel branches on the one rung. I just hope you haven't too many to do?

Perhaps if you threw up a couple of examples of what needs converting we could double-check what I'm saying actually applies to your situation.

Regards,
George

George

I used MOV instructions to flip the word order as you said but in my floats I am still getting the weird number Vs. my weights Which should be from 0-450.0

Any Idead why I am still getting the long numbers like 9.18383e-41 and it also looks like its changing from positive to negative as the number is changing a lot.
 
Some of the data I am bringig in is 2 bytes but is a UINT and not a SINt ot DINT.

I have never seen UINT before so do I need to handle it differently?
 
We took out a micrologix1500 out of some equipment from another plant and replaced it with a compactlogix as part of a larger project. If it wasn't for the fact that we threw it in the dumpster last week, i would have shipped it to you!
 
If you have a UINT stored in a SLC Int, then you'll want to check the sign bit (15). If it is not set, just MOV it to the float.

If it is set, it gets more complicated, because it really represents an integer greater than 32767. So, you will need to MVM it to another scratch INT with the mask set to not copy the sign bit (0111 1111 1111 1111). Once there, you can MOV it to a scratch float then add 32768.0 to the scratch float and send it to the destination float.

This description is off the top of my head, there may be a simpler way to do this.
 

Similar Topics

New to the ABpoint IO and have some experience with plcs but not that much. Anyway my question is why are these output cards flashing red? I am...
Replies
2
Views
1,146
Hi Can anyone give us the name and part number of programming cable for AM1000 fire and gas panel. Thanks
Replies
0
Views
1,021
I am using studio 5000 for the program. For some reason even when the ladder logic is completely true to fire the output, the output still will...
Replies
26
Views
6,588
We are thing about installing temperature sensors in the area of some of our large hydraulic systems These sensors would monitor the temperatures...
Replies
9
Views
3,521
Hi guys I'm working on this project: There's a Fire Alarm system installed in a plant that we want to communicate with using a CompactLogix L32E...
Replies
8
Views
2,482
Back
Top Bottom