Copy Servo Axis Attributes to New Tag

[mjp123gp]

This PLC is ControlLogix L73 v21.12. Servo axis is a Kinetix 7000.

Is there a simple way for me to copy all attributes of a servo axis to a new tag? I have created a UDT that contains all the same members in the same order as the AXIS_SERVO_DRIVE datatype. When I try to copy axis data to it there is a lot of data missing and other data that is incorrect. I have also tried using the CPS instruction but it does the same thing.

What i'm trying to do is store all attributes of the axis into an FIFO array when an event is triggered to help troubleshoot some issues we're having with the axis. Is there a better way to do this?

 

[daba]

Errr.... why did you create a UDT ??

You already have a data-type called AXIS_SERVO_DRIVE that you can create your own tags from ....

 

[mjp123gp]

I checked that and they are being displayed in the correct order. The problem though is for example, I need to know actual velocity but that value always shows zero in the copied destination. Another value is TorqueFeedback. Its showing 1800 in the destination but 13 in the actual axis attributes.

 

[daba]

I checked that and they are being displayed in the correct order. The problem though is for example, I need to know actual velocity but that value always shows zero in the copied destination. Another value is TorqueFeedback. Its showing 1800 in the destination but 13 in the actual axis attributes.

just 1 small mistake in your UDT will throw a lot of errors....

 

[mjp123gp]

Errr.... why did you create a UDT ??

You already have a data-type called AXIS_SERVO_DRIVE that you can create your own tags from ....

I used a UDT so I could create an array. When an event is detected I want to copy the axis data into the array once every few seconds. I also have a few other data points that I'm tracking so I didn't want to have multiple FIFO arrays to search through to review my data.

 

[daba]

I used a UDT so I could create an array. When an event is detected I want to copy the axis data into the array once every few seconds. I also have a few other data points that I'm tracking so I didn't want to have multiple FIFO arrays to search through to review my data.

Yes, I'm looking at this now - it seems that you cannot create an array of AXIS_.... data types - nor can you create a UDT with embedded AXIS_.... data types !!

Seems very odd that you can't at least create an array for storing "sets" parameters or, as in your case, logging them.

I'm sure you don't need all 604 bytes of the data, couldn't you just use the brute force method to snapshot the parameters you are interested in ? You could make it an AOI to make it easier to use....

For your FIFO I would use this code that I developed for another thread... (the data shifts "backwards", i.e. stored in the array as oldest [0], to newest [9], but that usually presents few problems, it's just another way of looking at it...

 

[daba]

I now see why you are having problems....

I created a UDT called Axis_Servo_Drive_UDT by copy/pasting ALL the elements of the AXIS_SERVO_DRIVE pre-defined data-type.

Everthing is there, all embedded data-types are correct, BUT

Size of AXIS_SERVO_DRIVE is 604 bytes
Size of Axis-Servo_Drive_UDT is 292 bytes !!!!

It looks as though the pre-defined type hasn't followed the "rules" for data-packing that occurs when you create your own UDTs !!

Looks to me like you need that AOI to capture the important data piece by piece.....

 

[daba]

Having checked the byte allocation of the AXIS_SERVO_DRIVE predefined data type, I cannot see any way in which it could be aligned to 604 bytes (151 32-bit words) - it just doesn't seem to solve !!!

 

[mjp123gp]

I noticed the size difference as well. The Axis_Consumed I made had the same size mismatch issue as well. I thought maybe something wasn't getting copied correctly so I hand typed everything for the Axis_Consumed and it still had the issue.

I'm in the process now of making an AOI to convert the data to my new UDT. Once I get it transferred I'm hoping it will let me copy from there into my array.

Thnaks for the help!

 

[daba]

I noticed the size difference as well. The Axis_Consumed I made had the same size mismatch issue as well. I thought maybe something wasn't getting copied correctly so I hand typed everything for the Axis_Consumed and it still had the issue.

I'm in the process now of making an AOI to convert the data to my new UDT. Once I get it transferred I'm hoping it will let me copy from there into my array.

Thnaks for the help!

Why not use the AOI to do everything - shift the array and then populate the "newest" data into it from the AXIS_SERVO_DRIVE tag. Trigger the AOI whenever you need a new "record"

You might need to bracket your "capture" code between UID and UIE so that the data source cannot change while picking the various elements, or simply CPS the actual axis tag to a buffer tag of the same data-type inside the AOI.

 

[daba]

Having checked the byte allocation of the AXIS_SERVO_DRIVE predefined data type, I cannot see any way in which it could be aligned to 604 bytes (151 32-bit words) - it just doesn't seem to solve !!!

I don't like that I'm not understanding some of the pre-defined types - a lot of them are declared as many bytes more than they need to be for the element collection...

 

[mjp123gp]

I don't like that I'm not understanding some of the pre-defined types - a lot of them are declared as many bytes more than they need to be for the element collection...

I found some other strange size issues when I was playing with UDTs earlier. I can create a single DINT member and the size is 4 bytes as I would expect. However, if I create a single INT or a BOOL they are also 4 bytes each. If you add a BOOL and an INT to the UDT, the total size is still 4 bytes.

 

[daba]

I found some other strange size issues when I was playing with UDTs earlier. I can create a single DINT member and the size is 4 bytes as I would expect. However, if I create a single INT or a BOOL they are also 4 bytes each. If you add a BOOL and an INT to the UDT, the total size is still 4 bytes.

The allocation of bytes is done to save memory...

Any new 32-bit element (DINT or REAL) will start at a new word, but smaller types will be "slotted-in", at byte boundaries, wherever possible.

Look at the following example to explain this concept....

Suppose we want a UDT that contains 3 BOOLs, An INT, and a DINT.

We can create this UDT with the elements in any order we like...

Bool_1
Bool_2
Dint_1
Int_1
Bool_3

That would create a UDT with a byte-count of 12 - the first two BOOLs occupy the first 2 bits of the first 32-bit word. The DINT occupies all of the bits of the second word, and the INT and final BOOL are packed together into the third word, so the data-type size is 3 x 32.bit words, or 12 bytes.

If we "group" like-minded types together, AND put them in "size" order, we can reduce the memory allocation....

Bool_1
Bool_2
Bool_2
Int_1
Dint_1

will result in a data-type size of 8 bytes - all of the first 4 elements are packed into the first 32-bit word, and the DINT takes the second 32-bit word. 2 x 32-bit words = 8 bytes.

We can reduce our memory allocation drastically by adopting the "group" and "order" rules - in this simple example we saved 33% of memory usage, imagine if we had created an array tag from the UDT of size 10,000 - dramatic savings....

The interesting thing about the "order" rule is that it doesn't matter whether we go smallest->largest, or vice-versa, the effect is the same.