Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Problems with CK3E and Kollmorgen AKD
#1
Hi all, I am experiencing some weird problems trying to use Kollmorgen AKD drives with CK3E (Acontis Ethercat stack)

When I download the PDOs the generated .pmh files have multiple duplicates of the same #defines and, worst of all, I am not able to move the motor.
I mean, I can activate the ethercat network, can even enable the motor (I can see that the drive is being enabled) but any movement results in a corresponding following error. The motor is "still", if I externally apply torque it does not move - like it's being controlled to do so

This is the auto-generated definition file

//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by PowerPMAC IDE.
// Date: 12/03/2019, Time: 12:22
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[0].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[1].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4096].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4097].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4098].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4099].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4100].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4101].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4102].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4103].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4104].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4105].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4106].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4107].Data
#define Slave_0_6063_0_PositionActualInt ECAT[0].IO[4108].Data
#define Slave_0_6041_0_Statusword ECAT[0].IO[4109].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4110].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4111].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4112].Data
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[4113].Data
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[4114].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4115].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4116].Data
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[4117].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4118].Data
#define Slave_0_60C1_1_1stsetpoint ECAT[0].IO[4119].Data
#define Slave_0_6040_0_Controlword ECAT[0].IO[4120].Data


Attached Files Image(s)
   
Reply
#2
I have tried changing many things, including ESI files and IDE version (3 or 4 does not make any difference)
The only different behaviour was obtained using a ESI file from DT Europe. In this case the standard mapping was CST, got no duplicates and with some work I was able to move the motor. Selecting a different PDO set causes the behaviour of all the others (duplicates and no movement).
I also tried defining a "custom" PDO mapping, but in this case the network does not get enabled at all.

In the past I've been using AKDs with Etherlab master with no problems.
Reply
#3
Your addressing looks wrong. Position Actual should be in 6064 and Target Position (assuming you are using CSP mode) should be 607A. Do you see those addresses in the list?

I seem to remember having to set some scaling parameters in the AKD drives to get them working correctly.
Reply
#4
Kollmorgen looks a bit different on this side

I think they use the same "setpoint" address for all the modes and switch it internally.
In some ESI files some mappings are dedicated to a single operating mode so you can find the PDOs you cited

Here is a working mapping I'm using with Etherlab

#define Slave_23_6063_0_PositionActualIn ECAT[0].IO[474].Data
#define Slave_23_2050_0_SecondPositionFe ECAT[0].IO[475].Data
#define Slave_23_606C_0_Velocityactualval ECAT[0].IO[476].Data
#define Slave_23_60FD_0_DigitalInputs ECAT[0].IO[477].Data
#define Slave_23_60F4_0_FollowingErrorAc ECAT[0].IO[478].Data
#define Slave_23_20A0_0_Latch1P ECAT[0].IO[479].Data
#define Slave_23_6041_0_Statusword ECAT[0].IO[480].Data
#define Slave_23_6077_0_TorqueActualValu ECAT[0].IO[481].Data
#define Slave_23_20A5_0_LatchStatus ECAT[0].IO[482].Data
#define Slave_23_3470_4_AINVALUE ECAT[0].IO[483].Data
#define Slave_23_6040_0_Controlword ECAT[0].IO[484].Data
#define Slave_23_60C1_1_1stsetpoint ECAT[0].IO[485].Data
#define Slave_23_20A4_0_LatchControlword ECAT[0].IO[486].Data
#define Slave_23_60B2_0_TorqueFeedForwar ECAT[0].IO[487].Data
#define Slave_23_60FE_1_DigitalOutputs ECAT[0].IO[488].Data
#define Slave_23_6072_0_MaxTorque ECAT[0].IO[489].Data
Reply
#5
The attached image is a screenshot of EC-Engineer for an AKD-N drive. As you can see, it has the standard addresses. I don't have a drive here to test it any further.

Which Kollmorgen drives do you have?


Attached Files Image(s)
   
Reply
#6
Hi,
drive is AKD-P02407-NBCC-I00

With ESI from Brad (AKD-P-17-00-000.xml) the standard mapping is in torque mode.
With this mapping (but only this one) I don't have any duplicates and I can get the motor to move.

However I want CSP.


Attached Files Image(s)
   
Reply
#7
With the ESI file downloaded form Kollmorgen website I get this standard mappings:

AKD Servo Drive Firmware and EtherCAT Device Description and CANopen EDS (AKD-P-NBCC-01-17-00-000)-->AKD EtherCAT Device Description.xml

Using the default mapping I can enable the ethercat network and the drive but I am not able to move it.
Evey movement results in a following error. I can see the setpoint word changing but the actual target does not change in the drive.

Apparent resolution, as you noted, is different from CST mode (much higher in CST). Don't know what this means but might be worth mentioning.


Attached Files Image(s)
   
Reply
#8
In a effort to document my struggles I mapped, with the same ESI file, this configuration.

As sometimes already happened before now I am able to move the motor in CST mode. Still have plenty of duplicates, which is really odd.

I saved the ESI file for safety.

So technically I *should* have a working configuration.
I Issue a "save" and then $$$ and all is gone.

I am really puzzled.


Attached Files Image(s)
   

.zip   EthercatConfig23.zip (Size: 3.85 KB / Downloads: 0)
Reply
#9
Typically when a PDO name shows up repeatedly within the ecat map, that indicates the ESI file had non-unique PDO names. In some cases I've seen ignoring the problem lead to strange behavior, like torque mode motors not being able to end open loop commands.

The fix for this is to add enough to the names of the PDOs you use to make them unique. I am attaching pages from a PDF explaining how to set up a specific elmo drive. Take a look at page 4 where step 6 begins. This shows exactly how to add a "1" to every PDO name in the mappings you are using, after clicking "Edit" on the correct PDO mapping.


Attached Files
.pdf   PDO Unique Names.pdf (Size: 353.66 KB / Downloads: 12)
Reply
#10
HI,
changing the PDO names prevents the PDO entry from being repeated.
It is a bit uncomfortable to do - especially if I have to do it for multiple drives - but works.

After a call with Kollmorgen's technicians it looks like the real problem of not being able to move the motor is that the "default" operation mode for the drive is not CSP.
To get it to work you have to manually set the operation mode writing in the $6060 SDO or modifying the startup sequence as shown in the picture (by default I had "7" here).
With Etherlab I never had to do this, so I needed someone to tell me.


So far so good, but I still have one problem: with Etherlab I could disable and re-enable Ethercat almost at will, but now if I disable Ethercat I can't re-enable it unless I make a reboot. Is this an expected behaviour?

ECAT[0].MasterState stays at 2 but most of the times the Ethercat does not re-enable.


Attached Files Image(s)
   
Reply
#11
(03-19-2019, 07:30 AM)tecnico Wrote: HI,
changing the PDO names prevents the PDO entry from being repeated.
It is a bit uncomfortable to do - especially if I have to do it for multiple drives - but works.
If you have more than a couple identical slaves, it is possible to delete slave 2 and then copy slave 1 to slave 2.


(03-19-2019, 07:30 AM)tecnico Wrote: After a call with Kollmorgen's technicians it looks like the real problem of not being able to move the motor is that the "default" operation mode for the drive is not CSP.
To get it to work you have to manually set the operation mode writing in the $6060 SDO or modifying the startup sequence as shown in the picture (by default I had "7" here).
With Etherlab I never had to do this, so I needed someone to tell me.
This was specified with names of move modes instead of values of $6060 in etherlab. The defaults could be different between modes.

(03-19-2019, 07:30 AM)tecnico Wrote: So far so good, but I still have one problem: with Etherlab I could disable and re-enable Ethercat almost at will, but now if I disable Ethercat I can't re-enable it unless I make a reboot. Is this an expected behaviour?

ECAT[0].MasterState stays at 2 but most of the times the Ethercat does not re-enable.
This is not expected behavior. How are you checking if EtherCAT re-enables? If you are checking ECAT[0].MasterState, then you may need to have ECAT[0].RTStateCheck=1, depending on firmware version. When it fails to change, what is the response to "ecat slaves"?
Reply
#12
Hi,
I look at MasterState (8 when ECAT is enabled, 2 when not) and at the update of motor position.
ECAT[0].Enable does not go to 1 when it refuses to enable
I have CK3E Fw. 2.3.2.5

This is what I get form terminal
SSH communication to PowerPMAC at 192.168.0.200 successful
ecat slaves
0 VID=$0000006A PC=$00414B44 0:0 PREOP + Slave_001 *first boot*
ecat[0].enable = 1
ecat slaves
0 VID=$0000006A PC=$00414B44 0:0 OP + Slave_1001 [AKD] *ecat enabled (Masterstate = 2)*
ecat[0].enable = 0
ecat[0].enable = 1 *this time 1st time re-enable worked*
ecat[0].enable = 0
ecat[0].enable = 1 *not working this time*
ecat slaves
0 VID=$0000006A PC=$00414B44 0:0 PREOP + Slave_1001 [AKD]
ECAT[0].RTStateCheck
ECAT[0].RTStateCheck=0
ECAT[0].RTStateCheck=1 *tried suggestion*
ecat[0].enable = 1
ecat slaves
0 VID=$0000006A PC=$00414B44 0:0 PREOP + Slave_1001 [AKD]
Reply
#13
(03-19-2019, 11:55 PM)tecnico Wrote: 0 VID=$0000006A PC=$00414B44 0:0 OP + Slave_1001 [AKD] *ecat enabled (Masterstate = 2)*

Can you confirm--does Masterstate ever go to 8 at this point if you let the system sit long enough? I've seen it go to 2 at first, but then goes to 8, which is the correct status when the system is in OP mode.


Additionally, can you try to issue an "ecat reset" after it gets in the state where it doesn't work to see if that changes anything?
Reply
#14
I found the problem to be related to the DC Sync mode.

Previously I was in Bus Shift mode; moving to Master Shift mode seems to solve the problem
Reply
#15
This makes sense. Some ethercat slaves do no support bus shift.
Reply
#16
Any idea about when the "duplicates" issue will be fixed ?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)